演算法自己干

A. 做為一個初學者，如何才能學好演算法呢，感覺自己很菜

凡事都講究動機，你學習演算法的目的是什麼呢？目的不同，學法不同側重不同。
如果你是准備跳槽，以面試為目的，可以先從cracking the coding interview入手，題目是按照鏈表，樹圖，遞歸這種章節安排的，每章都有題目，難度適中，第一遍自己寫不出來很正常，畫圖分析，然後再做第二遍，第二遍就快很多，理解也深刻了，實在理解不了的演算法，沒辦法，背吧，說不定到後面不知什麼時候就理解了，所謂讀書百遍，其意自現，演算法也一樣。
如果你是半路出家的程序員，看書覺得看不下去，可以試著看看視頻，現在網路這么發達，網上有很多免費的精品視頻，比如潭州教育老師的數據結構以及清華鄧俊輝老師的數據結構都是特別好的課程。
最後一種就是你對演算法理論和精髓確實感興趣，且有一定的數學功底，你可以嘗試研究下《演算法導論》，甚至《計算機程序設計藝術》(反正我是看不下去）。
其實，無論出於哪種目學習演算法，其實最重要的一點就是：多編程實踐，多思考，這是廢話，但這也是真理。

B. 演算法對以後工作到底有何幫助

。。。。。。我是做信息學競賽的，學演算法，也沒想過將來目標專業就定計算機了；
我覺得演算法有益身心，雖然某方面很難理解，但是很鍛煉思維，
同樣的例子：學化學的人又不是以後一定做化學研究，學生物的人也一樣，那他們學那些跟他們往後職業基本無關的東西幹嘛呢？
學計算機的人未來不一定要做程序員，但是卻一定要有相關的思維，它是一門應用科學，博大精深，與現代科技直接掛鉤。其實現實中的搜索引擎、雲計算、操作系統它們都是一代一代正在更新的演算法，作為一個學計算機專業的人，就算以後是做系統分析與設計不做專門的程序，或者說做程序而不想做一個特別優秀的程序員。。。這個想法是錯誤的，沒有什麼學科或者說專業知識是避的了的，這是一門技術，一門幾乎是想在1個小時內知道你思維如何、計算機語言功底如何的唯一方法，因為剛工作根本就沒經驗，拿什麼證明自己?當然是響當當的技術！
演算法是程序的靈魂，學進去以後其樂無窮啊。。。就算不做acm,你也會發現它大大地開拓了你的視野，與思維。如果你身邊有做acm競賽或者中學做信息奧林匹克noip競賽的人，問問他們，他們肯定會給你更為貼切的答復。

總之。。。演算法很有用，當然，功利一點，如果你不參加競賽、只要求相關科目低空飛過也非常容易，因為在不是那麼重視計算機專業的大學中，老師事實上對演算法可能也是一知半解，這題出難了估計沒接觸過的人幾乎都掛科。。所以只要聽課。。不用擔心演算法掛科。。。但是很多事情都是這樣，我們走每一步都是在為下一步埋伏筆，種瓜得瓜種豆得豆，很多事情根據興趣來吧。。。實在學不來也不熱愛憋著學也沒意思，但是不要那麼功利。

C. 演算法如何刷題

1、原題
我自己感覺原題的概率還是挺大的，特別是劍指offer的66題更是如此。千萬別小看這66題，這幾十道題裡面基本所有的演算法類型都有包括在內，常用的數據結構，操作方式，常用演算法思路都有不少的題。

如果真的能夠充分理解這幾十道題的最優解，我感覺其實已經形成基本的演算法思維了。

另外，leetcode的原題也很常見，因為LC本身題量大，在裡面出原題不是為了考倒你，而是檢驗你的刷題質量。

畢竟那些大公司面試官也不是傻子，知道你在面試前肯定會大規模刷題的。所以把刷過的題完全搞懂才是最重要的。

2、改編題
改編題就很顯而易見了。改編題大多需要從基本的演算法原理中找到處理的思維，然後結合實際題干進行性能優化，就能夠搞定。

這里要記得一點的是，正常的演算法考察不會故意刁難你（正常情況），也不會給過多的時間讓你思考和敲代碼。

所以遇到改編題不要想得太復雜，盡量要找到它的演算法思維是什麼。怎麼說呢，透過現象看本質。我總結的改編題有以下幾種思路：

1）新的數據結構，換湯不換葯。比如最常見的排序演算法的改編，原來是對數字進行排序，現在對鏈表排序等等。比較難一點的可能會遇到自定義的數據結構。但是演算法本質不會變。

2）演算法類型改編。

這里要說的就是一個比較大的范圍，比如動態規劃、貪心演算法、遞歸、回溯和分治等等。這種是從演算法大的類型上進行改編，很難用相同的套路去解題。

遇到這類題的關鍵就是要先弄明白演算法核心。比如動態規劃的狀態方程，貪心演算法的局部最優情況，遞歸回溯的邊界判斷，分治的子問題劃分等等。這種類型的確比較難把握，怎麼碩呢，每種類型的都來搞幾道感覺感覺吧。

3）添加應用題背景。

這種題目看起來不難，但是難就難在對應用題背景的理解，需要去理解題意，然後考慮合適的數據結構和處理演算法。這裡面有數學建模的思維在裡面，需要把一堆無用的信息剔除，篩選出有效的信息，然後才能選擇正確的演算法。

3、創新題
這類題考察的是你的擴展思維，如果說上面的題考查的是你的思維深度，這種題就是考察演算法的廣度。可能一看題目，完全沒見過這種類型。但是演算法本身其實不就是讓計算機代替人腦進行高重復性的計算嘛。

首先你需要想到你應該去怎麼算這個題，然後再換到計算機上，會發生什麼問題（空間時間問題，運行效率，代碼冗餘等等），之後再想通過經典的演算法原理來解決這些

1、題型分類
按照個人的習慣，喜歡按照一種類型狂刷，然後再刷另外一種類型。一般常見的演算法類型可分為：

數組、鏈表

包含基本排序演算法、二分查找、鏈表的一系列操作。

棧、隊列、堆

利用棧、隊列互相實現，堆的使用

二叉樹與圖

主要是遍歷演算法和節點的計算：
二叉樹四種遍歷方式、廣度優先遍歷（BFS）和廣度優先遍歷（DFS），節點到節點距離等等。

哈希表

使用標准庫自帶的模板或者函數就很簡單了，一般會與其它數據結構相結合來提升時間復雜度。

字元串操作

字元串的操作也很多，本質上可以看作是數組的操作。另外字元串的一些匹配和尋求字串的演算法還是非常具有思考價值的。KMP，馬拉車等等。

遞歸

重點掌握邊界判斷條件。

回溯

重點掌握邊界判斷條件。

分治

重點掌握如何劃分子問題。

動態規劃

題太多了，可從一階dp到二階dp理解不同的狀態方程。

貪心及其它

這個就很容易理解了，遇到貪心題應該要偷笑了。

2、高頻熱點多刷
這不多說了吧，Leetcode熱題HOT 100。你值得擁有。

在不知道怎麼刷的情況下，不如先刷起來。刷個題沒那麼多捷徑，只有堅持刷起來了，才會形成自己的思維方式和學習習慣。

我建議是先按照類型刷，每個類型刷十幾二十道。然後打混按照演算法熱度排序重新查漏補缺。

3、思路回顧
許多同學在一股腦刷了很多題之後，再看做過的題會發現忘了不少。可能大家都是這樣的吧。我覺得是因為在刷題的時候過於心急，理解了大概就過了，或者類型做的太雜，沒有留下印象。

我比較喜歡的方式是偶爾會重新看看曾經做過的題，就看題目然後想思路，再畫一畫步驟演進，沒時間就不細敲了。這樣可以增強一下思維記憶，之前理解過的東西，再回憶起來還是非常快的。

D. 關於動態規劃演算法，哪位可以講一下自己心得體會

動態規劃的特點及其應用
安徽 張辰
動態規劃 階段

動態規劃是信息學競賽中的常見演算法，本文的主要內容就是分析它的特點。
文章的第一部分首先探究了動態規劃的本質，因為動態規劃的特點是由它的本質所決定的。第二部分從動態規劃的設計和實現這兩個角度分析了動態規劃的多樣性、模式性、技巧性這三個特點。第三部分將動態規劃和遞推、搜索、網路流這三個相關演算法作了比較，從中探尋動態規劃的一些更深層次的特點。
文章在分析動態規劃的特點的同時，還根據這些特點分析了我們在解題中應該怎樣利用這些特點，怎樣運用動態規劃。這對我們的解題實踐有一定的指導意義。

動態規劃是編程解題的一種重要的手段，在如今的信息學競賽中被應用得越來越普遍。最近幾年的信息學競賽，不分大小，幾乎每次都要考察到這方面的內容。因此，如何更深入地了解動態規劃，從而更為有效地運用這個解題的有力武器，是一個值得深入研究的問題。
要掌握動態規劃的應用技巧，就要了解它的各方面的特點。首要的，是要深入洞悉動態規劃的本質。
§1動態規劃的本質
動態規劃是在本世紀50年代初，為了解決一類多階段決策問題而誕生的。那麼，什麼樣的問題被稱作多階段決策問題呢？
§1.1多階段決策問題
說到多階段決策問題，人們很容易舉出下面這個例子。
[例1] 多段圖中的最短路徑問題：在下圖中找出從A1到D1的最短路徑。
仔細觀察這個圖不難發現，它有一個特點。我們將圖中的點分為四類（圖中的A、B、C、D），那麼圖中所有的邊都處於相鄰的兩類點之間，並且都從前一類點指向後一類點。這樣，圖中的邊就被分成了三類（AàB、BàC、CàD）。我們需要從每一類中選出一條邊來，組成從A1到D1的一條路徑，並且這條路徑是所有這樣的路徑中的最短者。
從上面的這個例子中，我們可以大概地了解到什麼是多階段決策問題。更精確的定義如下：
多階段決策過程，是指這樣的一類特殊的活動過程，問題可以按時間順序分解成若干相互聯系的階段，在每一個階段都要做出決策，全部過程的決策是一個決策序列[1]。要使整個活動的總體效果達到最優的問題，稱為多階段決策問題。
從上述的定義中，我們可以明顯地看出，這類問題有兩個要素。一個是階段，一個是決策。
§1.2階段與狀態
階段：將所給問題的過程，按時間或空間特徵分解成若干相互聯系的階段，以便按次序去求每階段的解。常用字母k表示階段變數。[1]
階段是問題的屬性。多階段決策問題中通常存在著若干個階段，如上面的例子，就有A、B、C、D這四個階段。在一般情況下，階段是和時間有關的；但是在很多問題（我的感覺，特別是信息學問題）中，階段和時間是無關的。從階段的定義中，可以看出階段的兩個特點，一是「相互聯系」，二是「次序」。
階段之間是怎樣相互聯系的？就是通過狀態和狀態轉移。
狀態：各階段開始時的客觀條件叫做狀態。描述各階段狀態的變數稱為狀態變數，常用sk表示第k階段的狀態變數，狀態變數sk的取值集合稱為狀態集合，用Sk表示。[1]
狀態是階段的屬性。每個階段通常包含若干個狀態，用以描述問題發展到這個階段時所處在的一種客觀情況。在上面的例子中，行人從出發點A1走過兩個階段之後，可能出現的情況有三種，即處於C1、C2或C3點。那麼第三個階段就有三個狀態S3=。
每個階段的狀態都是由以前階段的狀態以某種方式「變化」而來，這種「變化」稱為狀態轉移（暫不定義）。上例中C3點可以從B1點過來，也可以從B2點過來，從階段2的B1或B2狀態走到階段3的C3狀態就是狀態轉移。狀態轉移是導出狀態的途徑，也是聯系各階段的途徑。
說到這里，可以提出應用動態規劃的一個重要條件。那就是將各階段按照一定的次序排列好之後，對於某個給定的階段狀態，它以前各階段的狀態無法直接影響它未來的發展，而只能通過當前的這個狀態。換句話說，每個狀態都是「過去歷史的一個完整總結[1]」。這就是無後效性。對這個性質，下文還將會有解釋。
§1.3決策和策略
上面的階段與狀態只是多階段決策問題的一個方面的要素，下面是另一個方面的要素——決策。
決策：當各段的狀態取定以後，就可以做出不同的決定，從而確定下一階段的狀態，這種決定稱為決策。表示決策的變數，稱為決策變數，常用uk(sk)表示第k階段當狀態為sk時的決策變數。在實際問題中，決策變數的取值往往限制在一定范圍內，我們稱此范圍為允許決策集合。常用Dk(sk)表示第k階段從狀態sk出發的允許決策集合。顯然有uk(sk) ?Dk(sk)。[1]
決策是問題的解的屬性。決策的目的就是「確定下一階段的狀態」，還是回到上例，從階段2的B1狀態出發有三條路，也就是三個決策，分別導向階段3的C1、C2、C3三個狀態，即D2(B1)=。
有了決策，我們可以定義狀態轉移：動態規劃中本階段的狀態往往是上一階段和上一階段的決策結果，由第k段的狀態sk和本階段的決策uk確定第k+1段的狀態sk+1的過程叫狀態轉移。狀態轉移規律的形式化表示sk+1=Tk(sk,uk)稱為狀態轉移方程。
這樣看來，似乎決策和狀態轉移有著某種聯系。我的理解，狀態轉移是決策的目的，決策是狀態轉移的途徑。
各段決策確定後，整個問題的決策序列就構成一個策略，用p1,n=表示。對每個實際問題，可供選擇的策略有一定范圍，稱為允許策略集合，記作P1,n，使整個問題達到最有效果的策略就是最優策略。[1]
說到這里，又可以提出運用動態規劃的一個前提。即這個過程的最優策略應具有這樣的性質：無論初始狀態及初始決策如何，對於先前決策所形成的狀態而言，其以後的所有決策應構成最優策略[1]。這就是最優化原理。簡言之，就是「最優策略的子策略也是最優策略」。
§1.4最優化原理與無後效性
這里，我把最優化原理定位在「運用動態規劃的前提」。這是因為，是否符合最優化原理是一個問題的本質特徵。對於不滿足最優化原理的一個多階段決策問題，整體上的最優策略p1,n同任何一個階段k上的決策uk或任何一組階段k1…k2上的子策略pk1,k2都不存在任何關系。如果要對這樣的問題動態規劃的話，我們從一開始所作的劃分階段等努力都將是徒勞的。
而我把無後效性定位在「應用動態規劃的條件」，是因為動態規劃是按次序去求每階段的解，如果一個問題有後效性，那麼這樣的次序便是不合理的。但是，我們可以通過重新劃分階段，重新選定狀態，或者增加狀態變數的個數等手段，來是問題滿足無後效性這個條件。說到底，還是要確定一個「序」。
在信息學的多階段決策問題中，絕大部分都是能夠滿足最優化原理的，但它們往往會在後效性這一點上來設置障礙。所以在解題過程中，我們會特別關心「序」。對於有序的問題，就會考慮到動態規劃；對於無序的問題，也會想方設法來使其有序。
§1.5最優指標函數和規劃方程
最優指標函數：用於衡量所選定策略優劣的數量指標稱為指標函數，最優指標函數記為fk(sk)，它表示從第k段狀態sk採用最優策略p*k,n到過程終止時的最佳效益值[1]。
最優指標函數其實就是我們真正關心的問題的解。在上面的例子中，f2(B1)就表示從B1點到終點D1點的最短路徑長度。我們求解的最終目標就是f1(A1)。
最優指標函數的求法一般是一個從目標狀態出發的遞推公式，稱為規劃方程：

其中sk是第k段的某個狀態，uk是從sk出發的允許決策集合Dk(sk)中的一個決策，Tk(sk,uk)是由sk和uk所導出的第k+1段的某個狀態sk+1，g(x,uk)是定義在數值x和決策uk上的一個函數，而函數opt表示最優化，根據具體問題分別表為max或min。
，稱為邊界條件。
上例中的規劃方程就是：

邊界條件為
這里是一種從目標狀態往回推的逆序求法，適用於目標狀態確定的問題。在我們的信息學問題中，也有很多有著確定的初始狀態。當然，對於初始狀態確定的問題，我們也可以採用從初始狀態出發往前推的順序求法。事實上，這種方法對我們來說要更為直觀、更易設計一些，從而更多地出現在我們的解題過程中。
我們本節所討論的這些理論雖然不是本文的主旨，但是卻對下面要說的動態規劃的特點起著基礎性的作用。
§2動態規劃的設計與實現
上面我們討論了動態規劃的一些理論，本節我們將通過幾個例子中，動態規劃的設計與實現，來了解動態規劃的一些特點。
§2.1動態規劃的多樣性
[例2] 花店櫥窗布置問題（IOI99）試題見附錄
本題雖然是本屆IOI中較為簡單的一題，但其中大有文章可作。說它簡單，是因為它有序，因此我們一眼便可看出這題應該用動態規劃來解決。但是，如何動態規劃呢？如何劃分階段，又如何選擇狀態呢？
<方法1>以花束的數目來劃分階段。在這里，階段變數k表示的就是要布置的花束數目（前k束花），狀態變數sk表示第k束花所在的花瓶。而對於每一個狀態sk，決策就是第k-1束花應該放在哪個花瓶，用uk表示。最優指標函數fk(sk)表示前k束花，其中第k束插在第sk個花瓶中，所能取得的最大美學值。
狀態轉移方程為
規劃方程為
（其中A(i,j)是花束i插在花瓶j中的美學值）
邊界條件 （V是花瓶總數，事實上這是一個虛擬的邊界）
<方法2>以花瓶的數目來劃分階段。在這里階段變數k表示的是要佔用的花瓶數目（前k個花瓶），狀態變數sk表示前k個花瓶中放了多少花。而對於任意一個狀態sk，決策就是第sk束花是否放在第k個花瓶中，用變數uk=1或0來表示。最優指標函數fk(sk)表示前k個花瓶中插了sk束花，所能取得的最大美學值。
狀態轉移方程為
規劃方程為
邊界條件為
兩種劃分階段的方法，引出了兩種狀態表示法，兩種規劃方式，但是卻都成功地解決了問題。只不過因為決策的選擇有多有少，所以演算法的時間復雜度也就不同。[2]
這個例子具有很大的普遍性。有很多的多階段決策問題都有著不止一種的階段劃分方法，因而往往就有不止一種的規劃方法。有時各種方法所產生的效果是差不多的，但更多的時候，就像我們的例子一樣，兩種方法會在某個方面有些區別。
所以，在用動態規劃解題的時候，可以多想一想是否有其它的解法。對於不同的解法，要注意比較，好的演算法好在哪裡，差一點的演算法差在哪裡。從各種不同演算法的比較中，我們可以更深刻地領會動態規劃的構思技巧。
§2.2動態規劃的模式性
這個可能做過動態規劃的人都有體會，從我們上面對動態規劃的分析也可以看出來。動態規劃的設計都有著一定的模式，一般要經歷以下幾個步驟。
劃分階段：按照問題的時間或空間特徵，把問題分為若干個階段。注意這若干個階段一定要是有序的或者是可排序的，否則問題就無法求解。
選擇狀態：將問題發展到各個階段時所處於的各種客觀情況用不同的狀態表示出來。當然，狀態的選擇要滿足無後效性。
確定決策並寫出狀態轉移方程：之所以把這兩步放在一起，是因為決策和狀態轉移有著天然的聯系，狀態轉移就是根據上一階段的狀態和決策來導出本階段的狀態。所以，如果我們確定了決策，狀態轉移方程也就寫出來了。但事實上，我們常常是反過來做，根據相鄰兩段的各狀態之間的關系來確定決策。
寫出規劃方程（包括邊界條件）：在第一部分中，我們已經給出了規劃方程的通用形式化表達式。一般說來，只要階段、狀態、決策和狀態轉移確定了，這一步還是比較簡單的。
動態規劃的主要難點在於理論上的設計，一旦設計完成，實現部分就會非常簡單。大體上的框架如下：
對f1(s1)初始化（邊界條件）
for k?2 to n（這里以順序求解為例）
對每一個sk?Sk
fk(sk)?一個極值（∞或－∞）
對每一個uk(sk)?Dk(sk)
sk-1?Tk(sk,uk)
t?g(fk-1(sk-1),uk)
y t比fk(sk)更優 n
fk(sk)?t
輸出fn(sn)
這個N-S圖雖然不能代表全部，但足可以概括大多數。少數的一些特殊的動態規劃，其實現的原理也是類似，可以類比出來。我們到現在對動態規劃的分析，主要是在理論上、設計上，原因也就在此。
掌握了動態規劃的模式性，我們在用動態規劃解題時就可以把主要的精力放在理論上的設計。一旦設計成熟，問題也就基本上解決了。而且在設計演算法時也可以按部就班地來。
但是「物極必反」，太過拘泥於模式就會限制我們的思維，扼殺優良演算法思想的產生。我們在解題時，不妨發揮一下創造性，去突破動態規劃的實現模式，這樣往往會收到意想不到的效果。[3]
§2.3動態規劃的技巧性
上面我們所說的動態規劃的模式性，主要指的是實現方面。而在設計方面，雖然它較為嚴格的步驟性，但是它的設計思想卻是沒有一定的規律可循的。這就需要我們不斷地在實踐當中去掌握動態規劃的技巧，下面僅就一個例子談一點我自己的體會。
[例3] 街道問題：在下圖中找出從左下角到右上角的最短路徑，每步只能向右方或上方走。
這是一道簡單而又典型的動態規劃題，許多介紹動態規劃的書與文章中都拿它來做例子。通常，書上的解答是這樣的：

按照圖中的虛線來劃分階段，即階段變數k表示走過的步數，而狀態變數sk表示當前處於這一階段上的哪一點（各點所對應的階段和狀態已經用ks在地圖上標明）。這時的模型實際上已經轉化成了一個特殊的多段圖。用決策變數uk=0表示向右走，uk=1表示向上走，則狀態轉移方程如下：

（這里的row是地圖豎直方向的行數）
我們看到，這個狀態轉移方程需要根據k的取值分兩種情況討論，顯得非常麻煩。相應的，把它代入規劃方程而付諸實現時，演算法也很繁。因而我們在實現時，一般是不會這么做的，而代之以下面方法：
將地圖中的點規則地編號如上，得到的規劃方程如下：

（這里Distance表示相鄰兩點間的邊長）
這樣做確實要比上面的方法簡單多了，但是它已經破壞了動態規劃的本來面目，而不存在明確的階段特徵了。如果說這種方法是以地圖中的行（A、B、C、D）來劃分階段的話，那麼它的「狀態轉移」就不全是在兩個階段之間進行的了。
也許這沒什麼大不了的，因為實踐比理論更有說服力。但是，如果我們把題目擴展一下：在地圖中找出從左下角到右上角的兩條路徑，兩條路徑中的任何一條邊都不能重疊，並且要求兩條路徑的總長度最短。這時，再用這種「簡單」的方法就不太好辦了。
如果非得套用這種方法的話，則最優指標函數就需要有四維的下標，並且難以處理兩條路徑「不能重疊」的問題。
而我們回到原先「標准」的動態規劃法，就會發現這個問題很好解決，只需要加一維狀態變數就成了。即用sk=(ak,bk)分別表示兩條路徑走到階段k時所處的位置，相應的，決策變數也增加一維，用uk=(xk,yk)分別表示兩條路徑的行走方向。狀態轉移時將兩條路徑分別考慮：

在寫規劃方程時，只要對兩條路徑走到同一個點的情況稍微處理一下，減少可選的決策個數：

從這個例子中可以總結出設計動態規劃演算法的一個技巧：狀態轉移一般是在相鄰的兩個階段之間（有時也可以在不相鄰的兩個階段間），但是盡量不要在同一個階段內進行。
動態規劃是一種很靈活的解題方法，在動態規劃演算法的設計中，類似的技巧還有很多。要掌握動態規劃的技巧，有兩條途徑：一是要深刻理解動態規劃的本質，這也是我們為什麼一開始就探討它的本質的原因；二是要多實踐，不但要多解題，還要學會從解題中探尋規律，總結技巧。
§3動態規劃與一些演算法的比較
動態規劃作為諸多解題方法中的一種，必然和其他一些演算法有著諸多聯系。從這些聯系中，我們也可以看出動態規劃的一些特點。
§3.1動態規劃與遞推
——動態規劃是最優化演算法
由於動態規劃的「名氣」如此之大，以至於很多人甚至一些資料書上都往往把一種與動態規劃十分相似的演算法，當作是動態規劃。這種演算法就是遞推。實際上，這兩種演算法還是很容易區分的。
按解題的目標來分，信息學試題主要分四類：判定性問題、構造性問題、計數問題和最優化問題。我們在競賽中碰到的大多是最優化問題，而動態規劃正是解決最優化問題的有力武器，因此動態規劃在競賽中的地位日益提高。而遞推法在處理判定性問題和計數問題方面也是一把利器。下面分別就兩個例子，談一下遞推法和動態規劃在這兩個方面的聯系。
[例4] mod 4 最優路徑問題：在下圖中找出從第1點到第4點的一條路徑，要求路徑長度mod 4的余數最小。
這個圖是一個多段圖，而且是一個特殊的多段圖。雖然這個圖的形式比一般的多段圖要簡單，但是這個最優路徑問題卻不能用動態規劃來做。因為一條從第1點到第4點的最優路徑，在它走到第2點、第3點時，路徑長度mod 4的余數不一定是最小，也就是說最優策略的子策略不一定最優——這個問題不滿足最優化原理。
但是我們可以把它轉換成判定性問題，用遞推法來解決。判斷從第1點到第k點的長度mod 4為sk的路徑是否存在，用fk(sk)來表示，則遞推公式如下：
（邊界條件）

（這里lenk,i表示從第k-1點到第k點之間的第i條邊的長度，方括弧表示「或(or)」運算）
最後的結果就是可以使f4(s4)值為真的最小的s4值。
這個遞推法的遞推公式和動態規劃的規劃方程非常相似，我們在這里借用了動態規劃的符號也就是為了更清楚地顯示這一點。其實它們的思想也是非常相像的，可以說是遞推法借用了動態規劃的思想解決了動態規劃不能解決的問題。
有的多階段決策問題（像這一題的階段特徵就很明顯），由於不能滿足最優化原理等使用動態規劃的先決條件，而無法應用動態規劃。在這時可以將最優指標函數的值當作「狀態」放到下標中去，從而變最優化問題為判定性問題，再借用動態規劃的思想，用遞推法來解決問題。
§3.2動態規劃與搜索
——動態規劃是高效率、高消費演算法
同樣是解決最優化問題，有的題目我們採用動態規劃，而有的題目我們則需要用搜索。這其中有沒有什麼規則呢？
我們知道，撇開時空效率的因素不談，在解決最優化問題的演算法中，搜索可以說是「萬能」的。所以動態規劃可以解決的問題，搜索也一定可以解決。
把一個動態規劃演算法改寫成搜索是非常方便的，狀態轉移方程、規劃方程以及邊界條件都可以直接「移植」，所不同的只是求解順序。動態規劃是自底向上的遞推求解，而搜索則是自頂向下的遞歸求解（這里指深度搜索，寬度搜索類似）。
反過來，我們也可以把搜索演算法改寫成動態規劃。狀態空間搜索實際上是對隱式圖中的點進行枚舉，這種枚舉是自頂向下的。如果把枚舉的順序反過來，變成自底向上，那麼就成了動態規劃。（當然這里有個條件，即隱式圖中的點是可排序的，詳見下一節。）
正因為動態規劃和搜索有著求解順序上的不同，這也造成了它們時間效率上的差別。在搜索中，往往會出現下面的情況：
對於上圖(a)這樣幾個狀態構成的一個隱式圖，用搜索演算法就會出現重復，如上圖(b)所示，狀態C2被搜索了兩次。在深度搜索中，這樣的重復會引起以C2為根整個的整個子搜索樹的重復搜索；在寬度搜索中，雖然這樣的重復可以立即被排除，但是其時間代價也是不小的。而動態規劃就沒有這個問題，如上圖(c)所示。
一般說來，動態規劃演算法在時間效率上的優勢是搜索無法比擬的。（當然對於某些題目，根本不會出現狀態的重復，這樣搜索和動態規劃的速度就沒有差別了。）而從理論上講，任何拓撲有序（現實中這個條件常常可以滿足）的隱式圖中的搜索演算法都可以改寫成動態規劃。但事實上，在很多情況下我們仍然不得不採用搜索演算法。那麼，動態規劃演算法在實現上還有什麼障礙嗎？
考慮上圖(a)所示的隱式圖，其中存在兩個從初始狀態無法達到的狀態。在搜索演算法中，這樣的兩個狀態就不被考慮了，如上圖(b)所示。但是動態規劃由於是自底向上求解，所以就無法估計到這一點，因而遍歷了全部的狀態，如上圖(c)所示。
一般說來，動態規劃總要遍歷所有的狀態，而搜索可以排除一些無效狀態。更重要的事搜索還可以剪枝，可能剪去大量不必要的狀態，因此在空間開銷上往往比動態規劃要低很多。
如何協調好動態規劃的高效率與高消費之間的矛盾呢？有一種折衷的辦法就是記憶化演算法。記憶化演算法在求解的時候還是按著自頂向下的順序，但是每求解一個狀態，就將它的解保存下來，以後再次遇到這個狀態的時候，就不必重新求解了。這種方法綜合了搜索和動態規劃兩方面的優點，因而還是很有實用價值的。
§3.3動態規劃與網路流
——動態規劃是易設計易實現演算法
由於圖的關系復雜而無序，一般難以呈現階段特徵（除了特殊的圖如多段圖，或特殊的分段方法如Floyd），因此動態規劃在圖論中的應用不多。但有一類圖，它的點卻是有序的，這就是有向無環圖。
在有向無環圖中，我們可以對點進行拓撲排序，使其體現出有序的特徵，從而據此劃分階段。在有向無還圖中求最短路徑的演算法[4]，已經體現出了簡單的動態規劃思想。但動態規劃在圖論中還有更有價值的應用。下面先看一個例子。
[例6] N個人的街道問題：在街道問題（參見例3）中，若有N個人要從左下角走向右上角，要求他們走過的邊的總長度最大。當然，這里每個人也只能向右或向上走。下面是一個樣例，左圖是從出發地到目的地的三條路徑，右圖是他們所走過的邊，這些邊的總長度為5 + 4 + 3 + 6 + 3 + 3 + 5 + 8 + 8 + 7 + 4 + 5 + 9 + 5 + 3 = 78（不一定是最大）。
這個題目是對街道問題的又一次擴展。仿照街道問題的解題方法，我們仍然可以用動態規劃來解決本題。不過這一次是N個人同時走，狀態變數也就需要用N維來表示，。相應的，決策變數也要變成N維，uk=(uk,1,uk,2,…,uk,N)。狀態轉移方程不需要做什麼改動：

在寫規劃方程時，需要注意在第k階段，N條路徑所走過的邊的總長度的計算，在這里我就用gk(sk,uk)來表示了：

邊界條件為
可見將原來的動態規劃演算法移植到這個問題上來，在理論上還是完全可行的。但是，現在的這個動態規劃演算法的時空復雜度已經是關於N的指數函數，只要N稍微大一點，這個演算法就不可能實現了。
下面我們換一個思路，將N條路徑看成是網路中一個流量為N的流，這樣求解的目標就是使這個流的費用最大。但是本題又不同於一般的費用流問題，在每一條邊e上的流費用並不是流量和邊權的乘積 ，而是用下式計算：

為了使經典的費用流演算法適用於本題，我們需要將模型稍微轉化一下：
如圖，將每條邊拆成兩條。拆開後一條邊上有權，但是容量限制為1；另一條邊沒有容量限制，但是流過這條邊就不能計算費用了。這樣我們就把問題轉化成了一個標準的最大費用固定流問題。
這個演算法可以套用經典的最小費用最大流演算法，在此就不細說了。（參見附錄中的源程序）
這個例題是我仿照IOI97的「障礙物探測器」一題[6]編出來的。「障礙物探測器」比這一題要復雜一些，但是基本思想是相似的。類似的題目還有99年冬令營的「迷宮改造」[7]。從這些題目中都可以看到動態規劃和網路流的聯系。
推廣到一般情況，任何有向無環圖中的費用流問題在理論上說，都可以用動態規劃來解決。對於流量為N（如果流量不固定，這個N需要事先求出來）的費用流問題，用N維的變數sk=(sk,1,sk,2,…,sk,N)來描述狀態，其中sk,i?V(1￡i￡N)。相應的，決策也用N維的變數uk=(uk,1,uk,2,…,uk,N)來表示，其中uk,i?E(sk,i)(1￡i￡N)，E(v)表示指向v的弧集。則狀態轉移方程可以這樣表示：
sk-1,i = uk,i的弧尾結點
規劃方程為
邊界條件為
但是，由於動態規劃演算法是指數級演算法，因而在實現中的局限性很大，僅可用於一些N非常小的題目。然而在競賽解題中，比如上面說到的IOI97以及99冬令營測試時，我們使用動態規劃的傾向性很明顯（「障礙物探測器」中，我們用的是貪心策略，求N=1或N=2時的局部最優解[8]）。這主要有兩個原因：
一． 雖然網路流有著經典的演算法，但是在競賽中不可能出現經典的問題。如果要運用網路流演算法，則需要經過一番模型轉化，有時這個轉化還是相當困難的。因此在演算法的設計上，靈活巧妙的動態規劃演算法反而要更為簡單一些。
二． 網路流演算法實現起來很繁，這是被人們公認的。因而在競賽的緊張環境中，實現起來有一定模式的動態規劃演算法又多了一層優勢。
正由於動態規劃演算法在設計和實現上的簡便性，所以在N不太大時，也就是在動態規劃可行的情況下，我們還是應該盡量運用動態規劃。
§4結語
本文的內容比較雜，是我幾年來對動態規劃的參悟理解、心得體會。雖然主要的篇幅講的都是理論，但是根本的目的還是指導實踐。
動態規劃，據我認為，是當今信息學競賽中最靈活、也最能體現解題者水平的一類解題方法。本文內容雖多，不能涵蓋動態規劃之萬一。「紙上得來終覺淺，絕知此事要躬行。」要想真正領悟、理解動態規劃的思想，掌握動態規劃的解題技巧，還需要在實踐中不斷地挖掘、探索。實踐得多了，也就能體會到漸入佳境之妙了。
動態規劃，
演算法之常，
運用之妙，
存乎一心。

E. 演算法工程師是做什麼的

演算法工程師是一個非常高端的職位；是非常緊缺的專業工程師，兼具前途和錢途！

專業要求：計算機、電子、通信、數學等相關專業；
學歷要求：本科及其以上的學歷，大多數是碩士學歷及其以上；
語言要求：英語要求是熟練，基本上能閱讀國外專業書刊；
必須掌握計算機相關知識，熟練使用模擬工具MATLAB等，必須會一門編程語言。

目前國內從事演算法研究的工程師不少，但是高級演算法工程師卻很少，是一個非常緊缺的專業工程師。演算法工程師根據研究領域來分主要有音頻/視頻演算法處理、圖像技術方面的二維信息演算法處理和通信物理層、雷達信號處理、生物醫學信號處理等領域的一維信息演算法處理。
在計算機音視頻和圖形圖形圖像技術等二維信息演算法處理方面目前比較先進的視頻處理演算法：機器視覺成為此類演算法研究的核心；另外還有2D轉3D演算法(2D-to-3D conversion)，去隔行演算法(de-interlacing)，運動估計運動補償演算法(Motion estimation/Motion Compensation)，去噪演算法(Noise Rection)，縮放演算法(scaling)，銳化處理演算法(Sharpness)，超解析度演算法(Super Resolution),手勢識別(gesture recognition),人臉識別(face recognition)。
在通信物理層等一維信息領域目前常用的演算法：無線領域的RRM、RTT，傳送領域的調制解調、信道均衡、信號檢測、網路優化、信號分解等。
另外數據挖掘、互聯網搜索演算法也成為當今的熱門方向。
演算法工程師逐漸往人工智慧方向發展。

F. 都快2021年了，演算法崗位應該怎樣准備面試

說到演算法崗位，現在網上的第一反應可能就是內卷，演算法崗位也號稱是內卷最嚴重的崗位。針對這個問題，其實之前我也有寫過相關的文章。這個崗位競爭激烈不假，但我個人覺得稱作內卷有些過了。就我個人的感覺，這幾年的一個大趨勢是從迷茫走向清晰。

早在2015年我在阿里媽媽實習的時候，那個時候我覺得其實對於演算法工程師這個崗位的招聘要求甚至包括工作內容其實業內是沒有一個統一的標準的。可以認為包括各大公司其實對這個崗位具體的工作內容以及需要的候選人的能力要求都不太一致，不同的面試官有不同的風格，也有不同的標准。

我舉幾個例子，第一個例子是我當初實習面試的時候，因為是本科生，的確對機器學習這個領域了解非常非常少，可以說是幾乎沒有。但是我依然通過了，通過的原因也很簡單，因為有acm的獲獎背景，面試的過程當中主要也都是一些演算法題，都還算是答得不錯。但是在交叉面試的時候，一位另一個部門的總監就問我有沒有這塊的經驗？我很明確地說了，沒有，但是我願意學。

接著他告訴我，演算法工程師的工作內容主要和機器學習相關，因此機器學習是基本的。當時我就覺得我涼了，然而很意外地是還是通過了面試。

核心能力

由於我已經很久沒有接觸校招了，所以也很難說校招面試應該怎麼樣准備，只能說說如果是我來招聘，我會喜歡什麼樣的學生。也可以理解成我理解的一個合格優秀的演算法工程師應該有的能力。

模型理解

演算法工程師和模型打交道，那麼理解模型是必須的。其實不用說每一個模型都精通，這沒有必要，面試的時候問的模型也不一定用得到。但更多地是看重這個人在學習的時候的習慣，他是淺嘗輒止呢，還是會刨根究底，究竟能夠學到怎樣的地步。

在實際的工作當中我們可能會面臨各種各樣的情況，比如說新加了特徵但是沒有效果，比如升級了模型效果反而變差了等等，這些情況都是有可能發生的。當我們遇到這些情況之後，需要我們根據已知的信息來推理和猜測導致的原因從而針對性的採取相應的手段。因此這就需要我們對當前的模型有比較深入地了解，否則推導原因做出改進也就無從談起。

所以面試的時候問起哪個模型都不重要，重要的是你能不能體現出你有過深入的研究和理解。

數據分析

演算法工程師一直和數據打交道，那麼分析數據、清洗數據、做數據的能力也必不可少。說起來簡單的數據分析，這當中其實牽扯很多，簡單來說至少有兩個關鍵點。

第一個關鍵點是處理數據的能力，比如SQL、hive、spark、MapRece這些常用的數據處理的工具會不會，會多少？是一個都不會呢，還是至少會一點。由於各個公司的技術棧不同，一般不會抱著候選人必須剛好會和我們一樣的期待去招人，但是候選人如果一無所知肯定也是不行的。由於學生時代其實很少接觸這種實踐的內容，很多人對這些都一無所知，如果你會一兩個，其實就是加分項。

第二個關鍵點是對數據的理解力，舉個簡單的例子，比如說現在的樣本訓練了模型之後效果不好，我們要分析它的原因，你該怎麼下手？這個問題日常當中經常遇到，也非常考驗演算法工程師對數據的分析能力以及他的經驗。數據是水，模型是船，我們要把船駛向遠方，只懂船隻構造是不行的，還需要對水文、天象也有了解。這樣才能從數據當中捕捉到trick，對一些現象有更深入的看法和理解。

工程能力

雖然是演算法工程師，但是並不代表工程能力不重要，相反工程能力也很重要。當然這往往不會成為招聘的硬性指標， 比如考察你之前做過什麼工程項目之類的。但是會在你的代碼測試環節有所體現，你的代碼風格，你的編碼能力都是你面試的考察點之一。

並不只是在面試當中如此，在實際工作當中，工程能力也很關鍵。往小了說可以開發一些工具、腳本方便自己或者是團隊當中其他人的日常工作，往大了說，你也可以成為團隊當中的開發擔當，負責其團隊當中最工程的工作。比如說復現一篇paper，或者是從頭擼一個模型。這其實也是一種差異化競爭的手段，你合理地負擔起別人負擔不了的工作，那麼自然就會成為你的業績。

時代在變化，行業在發展，如今的校招會問些什麼早已經和當年不同了。但不管怎麼說，這個崗位以及面試官對於人才的核心訴求幾乎是沒有變過的，我們從核心出發去構建簡歷、准備面試，相信一定可以有所收獲。