《挑戰程式設計》的一些筆記

2021-07-13 22:00:39 字數 2075 閱讀 6820

傳送門

求無向圖頂點1到頂點n的次短路徑。同一條邊可以經過多次。

書上的做法是直接將最短路徑的dijkstra演算法進行修改,對於每個頂點鬆弛的時候不僅鬆弛最短路,而且鬆弛次短路。我個人覺得這樣的做法必須得用把路徑存入到priority_queue中,再逐一出隊鬆弛,否則每次尋找要鬆弛的頂點的判斷條件較為繁瑣。

另一種方法是根據從1->n的次短路經一定是頂點1到某個頂點p的最短路+p到頂點q+q到頂點n(相當於多走了一條路,這裡的p可能為1,q可能為n)。所以,我們僅需做頂點1到所有其它點的單源最短路徑和頂點1到所有其它點的單源最短路徑,兩次dijkstra或spfa即可。

另外,無向圖裡面的陣列大小要開邊數的兩倍。以及,有些邊很多的圖中可能會有重複邊但權值不同的情況。

傳送門

徵募女兵n人,男兵m人,每徵募乙個人需要10000$。但這些男女中,存在一些關係。如果在徵募乙個人時,在之前徵募的人中存在和ta有關係的,那麼徵募費用要減去這些關係值的最大值。求最小徵募費用。

把人看做頂點,關係看做邊,最後的答案=10000*(n+m)- 最大生成樹。

在做圖論的題目時要注意頂點究竟是0…n-1,還是1…n,初始化的時候要小心。

傳送門

n*m的方陣,求多少連通的」w」(這裡的連通可以是每個位置的八個方位,即不僅包括上下左右,還有左上、左下、右上、右下)

dfs,從每個」w」開始做dfs,每次找其八個方位的「w」,並把其用「.」代替。每個格仔作為dfs的引數最多被呼叫一次,時間複雜度o(8*n*m)。

傳送門

卡車行駛l單位距離。一開始有p單位汽油,每單位距離需耗費1單位汽油。在路途中有一些加油站,距終點ai的加油站能加bi汽油,要求在這之中選取最少的一些加油站,使得能夠走過全程。

優先佇列,每走過1個加油站,存入乙個從大到小的優先佇列。然後每次走到油量為0時,取出佇列的頭元素。若隊列為空則無法到達終點。

傳送門

類似於合併果子。

優先佇列,o(nlogn)

傳送門

a吃b,b吃c,c吃a,給出k條資訊,求出矛盾的。

種類並查集,喜歡書上的做法。對每只動物建立3個元素i-a,i-b,i-c,其中i-x表示「i屬於種類x」,並查集裡的每乙個組表示組內所有元素代表的情況都同時發生或不發生。

合併前,判斷是否矛盾。否則,對於a和b是同一種類的資訊,合併x-a和y-a,x-b和y-b,x-c和y-c。對於a吃b的資訊,合併x-a和y-b,x-b和y-c,x-c和y-a。

傳送門

簡單快速冪

傳送門

求解乘法逆元,ax同餘1(mod m) 等價於 ax+my=1。

擴充套件歐幾里得的應用,本題裡因為求得是最小的正整數x,所以對於x=0 的特殊情況要特判一下。

poj 3469

兩個處理器執行n個模組,每個模組在處理器a或b上執行都有所需的花費ai或bi。有m個相互之間需要資料交換的模組組合(ai,bi),如果在不同的處理器上會有額外花費wi。求執行所有模組的最小值。

在處理器a上執行的模組集合為s,在b上為t。從起點s向每個模組連一條bi的邊,從每個模組向終點連一條ai的邊,從ai向bi連一條wi的雙向邊。最大流。

poj 3281

共有f種食物,d種飲料。每頭牛都有自己喜愛的食物和飲料,每種食物只能分配給一頭牛,求最多有多少頭牛能同時獲得喜歡的食物和飲料。

建圖,s->食物->牛->牛->飲料->t,即從s到所有的食物連一條邊,從食物向喜愛它的牛連邊,牛本身連一條邊,牛到相應喜愛的飲料連邊,飲料到t連邊。求最大流。

poj3041

n*n網格,k行星。一束光能消滅一整行或整列,求最少需要多少道光能全部消滅。

一共2n個光束選擇(行n個,列n個)。把光束看做圖的頂點,行星看做連線對應光束的邊,最後的要求是求最小的頂點集合,是的每條邊至少有乙個光束中的頂點。

最小頂點覆蓋,轉化為二分圖最大匹配。

poj 3686

n個玩具,由m個工廠加工。a[i,j]表示第i個玩具由第j個工廠加工的時間,每個工廠只能乙個接乙個加工玩具,求完成所有玩具時間的最小值。

若只有1個工廠,按照順序a1,a2…,t=n*a1+(n-1)*a2+…+1*an。把每個機器拆成n個點,1~n分別代表某個玩具在這個機器上倒數第幾個被加工。求最小費用流。

秒殺活動中的一些技術挑戰

假設某 秒殺活動只推銷一件商品,預計會吸引一萬使用者參加活動,也就是說最大併發請求數是10k,此時,秒殺系統面臨的一些技術挑戰有哪些呢?1.對現有 業務造成衝擊 秒殺活動只是 營銷的乙個附加活動,這個活動具有時間短,併發訪問量大的特點。如果和 原有應用部署在一起,必然會對現有業務造成衝擊,稍有不慎,...

程式設計的一些習慣

最近在寫一些框架應用類的程式,其中出現了一些莫名其妙的bug,或者是令人匪夷所思的問題,解決的方案網上沒有,當自己解決了之後,對於解決的辦法也是哭笑不得,例如重新引入工程之類的解決辦法,讓自己覺得讓這些低階的錯誤影響了自己的 推進速度實在是不應該,太多的時間都花在除錯bug上了,而不是了解業務或者是...

程式設計的一些特點

回家路上稍微有點感想,記一下。在比較大的規模的專案裡面程式設計,還是比較費神的,所以狀態的差別真的會很有影響。保持心無旁焉的狀態是很重要的,同時避免掉周圍的不利影響。在走下去可能就是涉及到對工作的信仰上了。太遠了 然後就是長時間的集中,也可能是我的記憶力不夠好,總之我覺得最強的生產力就是在長時間的連...