如何實現科技論文里面的算法

這是一篇關于如何實現科研論文中算法的簡要指南。作者曾實現過很多書本上和科研論文中的復雜算法，在這篇文章中作者總結他在研究，閱讀，編碼和調試時積累的大量經驗。很顯然，這篇文章主要集中在和計算機科學相關的研究領域中。 然而，你也可以在其他任何領域的論文中使用下面提及的準則。

1.?– 開始之前

在你開始閱讀一篇論文和實現它之前，有幾個你需要注意的地方。并請確保每次你要開始類似的項目之前，都仔細的注意過這幾個方面。

1.1 – 看看是不是已經有開源軟件實現過

除非你是為了純粹的學習目的而去實現一篇文論中的算法， 否則你不必一定要實現它。實際上，你所需要的不是自己去實現它的過程，而是已經實現了這個算法的代碼。所以在你開始編碼之前，你應該花一些時間去找找網上是不是已經有實現了這個算法的開源軟件。想想你是愿意花兩天時間去找到已經完成的代碼，還是浪費兩個月的時間去實現一個別人已經實現的了算法呢？???

1.2 – 用最簡單的方法達到你的目的

你要先搞清楚你想要達到的目標是什么，以及是不是有簡單的方法已經可以達到你的目標。 或許你可以嘗試使用另外的技術，即使它只能達到你80%的目標，但它不需要你去實現一篇論文。然后你可以再花幾天的時間去嘗試是不是可以用開源軟件運行起來。關于這個更多的詳情，請參考我的另外一篇文章?The 20 / 80 Productivity Rule.

1.3 – 注意軟件的專利

如果你再美國， 你需要注意軟件的專利問題。有一些論文是注冊了專利的，你可能因為在商業軟件中使用了它的算法而惹上麻煩。

1.4 – 關注更多該領域的論文

如果你正在研究一篇關于在計算神經學領域中使用支持向量機(SVM)的論文的話，那你應該再讀一些關于機器學習以及其他可替代支持向量機(SVM)的分類算法的介紹。同時，你還可以讀一些關于計算神經學領域的文章，看看學術界正在研究什么.

1.5 – 保持積極性

如果你還沒有實現過一篇論文或你正在研究一個新領域內的論文，這樣的閱讀研究是很困難的。不管發生什么，不要讓那些復雜的數學公式嚇到你。而且，不要去擔心進度的問題，即使你感覺理解這篇論文要比你預計的要慢很多, 堅持做下去你會發現你慢慢的就理解了這篇論文中所要表述的概念。?

2 – 三種類型的論文

隨便選一篇論文，馬上開始實現絕對不是一個好注意. 世界上有很多很多的論文，這也意味著有很多很多的垃圾論文。所以發表的論文可以分成三類。

2.1 – 創新型論文

這是一些非常有趣的，寫的很好的，原創性的論文。大部分這類論文來自世界頂尖大學或者是已經研究某個領域很久的小學校的研究團隊。后者很好區分，他們往往都在自己論文中引用自己之前的研究成果，已展示他們對這個問題的研究已經很長時間了, 而且他們最新的研究工作都是基于已經證實了的論文之上。 同時，這類型的論文基本都在該領域內最好的期刊雜志上發表。

2.2-模仿型論文

一些研究群體僅僅只是跟隨哪些有突破性創新的團體，他們的目的就是提高已經發表的論文（算法），并且發表他們提高后的結果。很多這樣的論文缺少合適的統計分析和錯誤的結論，這樣的提高其實是破壞了原有的算法。很多時候，他們這樣做并沒有帶來任何東西，除了帶來不必要與而外的復雜性。但也并不是所有的模仿是不好的，有些還是不錯的，但卻很稀少。

2.3-垃圾型論文

一些研究者并不知道他們做的事情是非常不好的。他們僅僅是為了維持他們在自己學術領域中的狀態與特權。所以他們需要資金，并且他們需要出版任何他們需要的東西。比較誠實的研究者會告訴你，在結論中他們失敗了，在結果中只有N%的時間（N是有比較差的值）。但一些心懷不軌的研究員會說謊話，他們會說他們的研究取得了巨大的成功。在閱讀出版物一段時間以后，很容易就能發現那些垃圾型論文，并拋棄他們。

3-如何閱讀科技論文

這個話題已經討論過很多次，因此不打算繼續寫很多關于這個問題的探討。一個好的出發點可以參見這篇文章：How to Read a Paper?，下面的一些觀點是我在閱讀科技論文時候發現的有用的觀點。

3.1-找到正確的論文

原始論文就是你想實現的是什么，描述的是這個領域的開端。有時候也可以選擇相似的論文，前提是你覺得這篇論文是能帶來算法上本質的提升并且有良好的一致性卻不成熟的創新的文章。

那么讓我告訴你以該論文作為出發點。你需要在該論文相關領域做些研究。對此，方法就是尋找相關聯的論文，即是那些在該論文引用部分里面所提到的論文。再去Google Scholar依據論文題目和作者搜索。你找到的論文是否比你現在看的論文所做的效果更好呢？如果是，那么就去研究找到的新論文。Google Scholar還有個優點就是能標注論文的引用。這個非常棒，因為你能從一篇論文的引用鏈接找到另外的論文，這樣可以找到某個研究領域最新的成果。總體來說就是從當前論文的引用中尋找新的論文。通過這樣來回搜索，就會找到適合你的高質量的論文。

重點：在這個搜索論文過程中，你不需要從頭到尾仔細閱讀理解論文。只需要大體瀏覽論文并用你的直覺去判斷論文的價值。

3.2 – 不要在屏幕上閱讀

打印成紙質閱讀，打印時不要降低字體大小，如果你降低了字體大小可能節省了幾頁紙卻使你在閱讀時因為眼睛更易疲勞而浪費了更多的時間，字體大小一般建議在11pt-13pt

3.3 –選擇恰當的閱讀時間和地點

不要在半夜閱讀，最好在大腦清醒時才閱讀.也應該找一個安靜、光線適中的地方。我通常都在臺燈下閱讀。

3.4 – 注意標記和備注

標記重要信息，并在重要信息旁寫下閱讀時腦袋中浮現的各種想法。

3.5 知道所有術語的定義

通常你閱讀大多數文章和小說時，對于生詞你的大腦會象計算機一樣根據上下文自動得出意思。但是科技出版物完全不同，其中最多的錯誤就是單詞意思的錯誤假設。比如說句子“The results of this segmentation approach still suffer from blurring artifacts”中“segmentation”和“artifacts”通常有著“分割”和“手工品”的意思，但是在計算機視覺領域有著特殊的意思。如果你閱讀這篇論文時沒有注意這個，你的大腦用了他們的通常意義去理解，你會漏掉很重要的信息。因此你必須（1）避免假設單詞的意思，任何時候有疑問需查閱專業詞典（2）抄寫一張你不熟悉的專業生詞概念表做參考。如果你遇到概念比如“faducial points”和“piece-wise affine transform”，首先你應該查出他們的準確的專業含義，然后加在你的生詞表里。概念是語言式的大腦快捷鍵可以幫助你更快理解作者的意圖。

3.6 – 關注結論中的統計分析

如果論文作者僅僅用曲線展示他的算法和其他算法的差異，并且說“你看，比原有算法準確了20%”，這種論文就一垃圾論文. 你應該閱讀的是那種在論文中說: “在N個實例的測試集中，我們的算法在兩個樣本測試中檢驗值提升了5%（這句真不好翻譯）” 統計結論更多的證據應該來自數據而不是作者的個人想法?(除非作者撒謊夸大他的結論).

3.7 – 請確定論文所展示的結論是你所需要的

假設你需要一個能夠從圖片中人臉識別的算法.作者在論文結論中說他的模型用80個人不同照片（10x 80 = 800張圖片）進行訓練, 對訓練集進行測試時人臉識別準確率達到98%,但是對測試集（測試的圖片沒有被用于訓練集）進行人臉識別時準確率只有70%。這樣的描述是什么意思呢？它以意味著該算法仍然存在問題（這句真不好翻譯）——該算法當用于對訓練集進行識別時是非常不錯的（但種情況沒有任何實際意義），但是用于對測試集進行識別時就會非常糟糕。你也可以通過這點，來判斷一篇論文是否是你所需的

3.8 注意作者用的輸入數據

如果你想用網絡攝像頭做臉部識別，而作者的輸入數據用的是出自高清相機的相片，那么算法結果可能會完全不同。必須保證你的輸入數據近似與算法測試數據，否則會造成算法完全無用在你的case。

3.9 作者也是人

人都會犯錯，不要認為作者是神。特別是算式真的很難理解，你應該問問你自己是否作者寫錯了。這可能僅僅是論文的抄寫錯誤或一個數學計算錯誤。不管怎么說，最好的方法是自己做做計算去驗證結果。

3.10-理解變量與運算符

實現算法的主要的工作量在于將紙面上的數學算式轉化為代碼以及數據。這意味著在轉化完畢之前，你必須百分百理解那些數學式子到底是在做什么。例如“C=A.B”可能有很多意義。A和B

可以是簡單的數字，而“.”是一個數字運算符號。這種情況下，C的結果可以是A和B的和。但是A和B也有可能是兩個矩陣，這種情況下，“.”又可以作為一個矩陣運算符存在。這種情況下，C是A和B兩個矩陣運算的結果矩陣。唉……其實還有個可能，A，B都是矩陣，然后“.”是一個矩陣加法運算符，這種情況下，每一個C（i,j）都是A（i,j）和B（i,j）的和。變量和符號到底代表什么意思（矩陣、向量、數字、坐標，還是其他？），這值得你好好研究下。（譯者注：其中關于矩陣的運算符號，我不清楚這幾個英文單詞都對應哪些符號……）

3.11-弄清數據處理流程

論文就是一堆方程的大雜燴。在你開始寫代碼之前，你需要了解如何把N根據要求變成N+1

4-模型

一旦讀懂了論文，接下來你應當設計一個模型。這是一個非常重要的步驟，通過這一步你可以避免大量的資源以及時間的浪費。要把一個算法用c，c++或者java寫出來是非常費時間的。即使你認為自己對論文有足夠的了解而且算法肯定會按照你所想的去工作，這里仍然有個問題：如果他完全不動彈呢？所以如果你想盡快將算法轉化為代碼，還是先建立一個模型檢驗一下他能否工作吧。

4.1-模型建立方法

最好的方法當然是使用高級通用語言來建立，比如matlab，R，Octave或者SciPy/NumPy。像c++這樣的工程語言一般不太容易用于描述一個數學方程并輸出結果以進行人工檢查。相反的，在matlab上這就很容易實現。你用c++兩三周才可以干完的事情或許matlab上面只需要兩天。

4.2-用模型進行調試

模型的另外一個應用是進行調試，特別是當你開發出你的c++版本以后，你可以通過你的matlab版本的輸出與c++版本進行對比。對該條的進一步描述請參看“調試”（譯者注：“7-調試”）章節。

4.3-模型可以精實你的程序

你肯定會在模型建立當中遇到一些問題。這是好事情，因為你可以從中發現數據處理的難點在哪里。當你編寫c++代碼的時候你就知道如何更好的構造程序，因而使他更加的可靠簡潔。而如果你沒有經歷過模型構造這一步，你的代碼大概會走向相反方向（這一點可以從Frederick Brooks的《人月神話》中找到）。

4.4-檢驗文章中的試驗結果

請仔細閱讀“試驗”(譯者注：我沒有找到相關章節)這一章節，然后嘗試使用論文中給出的數據重復試驗。這將會使你可能看到作者文章中所描述的結果。如果不能較好的重復文章中的試驗，你將在試驗中看到不一樣的結果，讓你疑心是否是文章有問題。而其實你只要較好的重復試驗并輸入文章中的試驗數據你就可以看到文章所描述的結果。然后你就可以開始測試其他不同的數據了。

5 - 正確地選擇實現語言和庫

在這一階段，你必須已對論文提出的算法和概念有了一個清晰的認識，而且必須能有一個可運行原型程序，以確認算法能夠在你預想的輸入數據下，正常的工作。好的，進入下一步，確定你要使用哪種語言和框架來實現論文的算法。

5.1 - 現有體系

大多數情況，現有體現已經指定了實現語言和庫。實際的例子：你有一套Java實現的計算圖像照度歸一化的算法庫，而你想要將論文的新算法添加進庫。這種情況，很顯然，你要使用Java來實現新算法，而不是C++。

5.2 - 前瞻算法的應用場景

在沒有現有體系限制你選擇語言的情況下，則要基于對該算法在將來的使用場景的前瞻來選擇實現語言。比如，如果你堅信在四到六個月后，你的應用程序將會實現面向iPhone的接口，那你就應該更傾向于選擇C/C++，而不是Java，因為如此可以很簡單的將算法代碼集成的Objective-C的應用中，而不需要重頭來過。

5.3 - 參考能夠解決或部分解決算法問題的現有庫

不同語言實現的現有庫也會影響我們對實現語言的選擇。讓我們來想象一下，你想要實現的算法使用了諸如主成分分析（PCA）以及單值分解（SVD）等經典的代數技巧。那你是重頭編碼實現PCA和SVD算法，遇到bug，可能還要停滯一周來調試自己的代碼？還是使用現有的，已經實現了這些功能的庫，使用他們提供的常規接口和矩陣類來實現自己的編碼？理論上講，你應該將你的實現工作分解為若干個子任務，然后嘗試盡可能多的尋找能夠解決這些子任務問題的現有庫。如果你發現有一套完美解決你的問題的庫，且僅有某一語言版本提供，那么，就使用這種語言。同時也要注意，在選擇庫的時候，需要在代碼的重用及最小依賴之間做出權衡。沒錯，如果有能夠解決你所有子任務問題的代碼是再好不過了，但是如果這需要依賴超過20各不同的庫，那實在是不太實用，甚至危及你的實現代碼將來的穩定性。

6 – 實現

實現算法的一些個人經驗

6.1 – 選擇正確的精度

通常最好用double代替float，雖然使用double內存會占用更多，但卻改善了精度，這是值得的.另外，你需要注意32bit和64bit操作系統之間的不同處.如果可以，自己創建一個封裝（封裝了float或者double，32-bit或64-bit）類型，然后在代碼中使用封裝了的數據類型，在c/c++中可以使用define實現，java中可以使用class來實現.

6.2 – 為代碼做好注釋

雖然文檔維護會顯著降低項目進度，但在實現一個復雜的技術論文時，你最好做好文檔.即使項目只有你一個人，你也應該對你的文件、類、方法進行注釋說明.選擇一種轉換方法如Doxygen或reStructuredText，并堅持使用它.在以后的開發中，你可能會忘記某個class是如何使用的或者某個方法的實現方式，你就會覺得當初的文檔太有用了.

6.3 - 在你的代碼中添加引用

對于來自你所要實現的論文的每一條方程，你需要添加一段注釋引用這篇論文（作者和時間）以及段落號碼或方程號碼。這樣，以后重讀代碼時，你可以直接把代碼和論文中的準確位置聯系起來。這些注釋就像：
// 參見 Cootes et al., 2001, 方程 2.3
// 參見 Matthews and Baker, 2004, 章節 4.1.2

6.4 - 在變量名中避免數學符號

我們假設一些數量在算法中是一個矩陣表示為A。然后，算法要求矩陣在兩個維度上的梯度，表示位 dA = (dA/dx, dA/dy)。那么變量名不應當為"dA_dx"和"dA_dy"，而是"gradient_x"和"gradient_y"。相似地，如果一個方程系統要求收斂判定，那么變量不應為"prev_da_dx"和"dA_dx",而是"error_previous"和"error_current"。把變量永遠命名為它們所表示的物理數量，而不是論文作者使用的任何字母符號（例如"gradient_x"而不是"dA_dx"），并且永遠要把更具體的表示寫在左邊（例如"gradient_x"而不是"x_gradient"）。

6.5-不要一開始就優化

請把優化這種事情往后面放放。否則你絕對不可能確定你的代碼到底是哪里出了問題。而每當你進行優化，你最好添加一些注釋來進行解釋，例如：

//優化：一次計算矩陣一列以減少內存開銷

通過這種方式，不論是什么語言，你都可以很快的從你的代碼中發現到底是哪處優化導致了問題。

6.6-打算創建一個api？

如果你打算把你的代碼構建成一個api，你需要注意的是如何如何創建接口。對于這一點，我建議你使用Joshua Bloch?How to Design a Good API and Why it Matters書中的“面向函數庫編程”（譯者注：原文“coding against the library”真的不知道怎么翻譯……）技術。

7 - 調試

實現一個新算法如同燒一道你之前從未吃過的菜。即使它味道不錯，你也不知道這是不是它原本的味道。和燒菜不同的是，軟件開發有一些有用的訣竅來增添我們在實施中的信心，所以我們還算運氣不錯。

7.1 - 和其他實現比較結果

一個淘出bug的好方法就是把你代碼的結果和同一個算法的已有的實現的結果進行比較。假設你正確完成了上面“著手之前”章節提及的所有任務，你會發現該算法還沒有任何可行的實現（否則你就該直接用它，不必去實現那篇論文）。所以，你眼下的另一種實現只能是你以前編寫的原型。

這個想法就是在算法的每一步比較原型和產品實現的結果。如果結果不同，那么兩者其一出了錯，你得找到哪個出了錯以及出錯的原因。精確度可能變化（原型給出x=1.8966但產品卻給出x=1.8965），比較時也要將此考慮進來。

7.2 - 和讀過論文的人談談

一旦兩個實現（原型和產品）的所有步驟給出相同的結果，你就可以在一定程度上相信你的代碼沒有bug。但是，還存在你對論文理解錯誤的風險。在這種情形下，兩個實現都會在每一步給出相同的結果，你會認為你的實現還不錯，然而這只能證明兩個實現同樣都是錯的。不幸的是，我也不知道該如何察覺到這種錯誤。最好的選擇是找一個讀過這篇論文的人，并問他關于算法中你不確定的部分的問題。你甚至可以設法詢問作者，但你得到回答的幾率非常低。

7.3 - 可視化你的變量

開發時，你應該留意算法中用到的變量的內容。我不是說僅僅打印出你所有矩陣和數據的值就可以了，而是找到適合你實現中的任何變量的可視化訣竅。例如，如果一個矩陣用來表示一張圖片的梯度，那么在編碼和調試過程中，你應當有一個彈出窗口，展示出那張梯度圖，而不只是圖片矩陣中的數值。這樣，你就會把真實的圖片和你要處理的數據聯系起來，并且在變量出現問題時，你可以察覺到，這可能將是一個bug。創造性的可視化訣竅包括圖像、散點圖、曲線圖，但絕不是一張包含1000個數字的愚蠢列表，然后你必須再依靠這張表在腦海中呈現出圖像。

7.4 - 測試數據集

生成數據來試驗你的實現可能非常耗費時間。無論何時，只要你能，就設法去找到數據庫（人臉數據庫、原文摘錄數據庫等等）或者生成這種數據的工具。如果沒有，那么不要把時間犧牲在手動生成1000個樣例數據上。編寫一個20行以內的快速數據生成器，再用它干活。

總結

這篇文章中，我已經展示了如何實現科學出版物的良好實踐。記住，這些僅僅基于我的經驗，不能一字一字地盲目效仿。當你閱讀和編碼時，永遠要小心，并用你的判斷力來決定上面哪條準則適合你的項目。也許有些做法對你項目的傷害會比好處更多，這就靠你去發現了。

現在,去實現一些很酷的算法吧!

出處：http://www.oschina.net/translate/how-to-implement-a-algorithm-from-paper

原文地址：http://codecapsule.com/2012/01/18/how-to-implement-a-paper/

--------------------------------------英文原文--------------------------------------

How to implement an algorithm from a scientific paper

2012 January 18
tags: academic, code, guide, howto, implement, paper, practice, programming, publication, research, scientific, technical, tutorial
by Emmanuel Goossaert

This article is a short guide to implementing an algorithm from a scientific paper. I have implemented many complex algorithms from books and scientific publications, and this article sums up what I have learned while searching, reading, coding and debugging. This is obviously limited to publications in domains related to the field of Computer Science. Nevertheless, you should be able to apply the guidelines and good practices presented below to any kind of paper or implementation.

To receive a notification email every time a new article is posted on Code Capsule, you can subscribe to the newsletter by filling up the form at the top right corner of the blog.
As usual, comments are open at the bottom of this post, and I am always happy to welcome questions, corrections and contributions!
1 – Before you jump in

There are a few points you should review before you jump into reading a technical paper and implementing it. Make sure you cover them carefully each time you are about to start working on such a project.
1.1 – Find an open source implementation to avoid coding it

Unless you want to implement the paper for the purpose of learning more about the field, you have no need to implement it. Indeed, what you want is not coding the paper, but just the code that implements the paper. So before you start anything, you should spend a couple of days trying to find an open source implementation on the internet. Just think about it: would you rather lose two days looking for the code, or waste two months implementing an algorithm that was already available?
1.2 – Find simpler ways to achieve your goal

Ask yourself what you are trying to do, and if simpler solutions would work for what you need. Could you use another technique – even if the result is only 80% of what you want – that does not require to implement the paper, and that you could get running within the next two days or so with available open source libraries? For more regarding this, see my article The 20 / 80 Productivity Rule.
1.3 – Beware of software patents

If you are in the U.S., beware of software patents. Some papers are patented and you could get into trouble for using them in commercial applications.
1.4 – Learn more about the field of the paper

If you are reading a paper about the use of Support Vector Machines (SVM) in the context of Computational Neuroscience, then you should read a short introduction to Machine Learning and the different types of classifiers that could be alternatives to SVM, and you should as well read general articles about Computational Neuroscience to know what is being done in research right now.
1.5 – Stay motivated

If you have never implemented a paper and/or if you are new to the domain of the paper, then the reading can be very difficult. Whatever happens, do not let the amount and the complexity of the mathematical equations discourage you. Moreover, speed is not an issue: even if you feel that you understand the paper slower than you wish you would, just keep on working, and you will see that you will slowly and steadily understand the concepts presented in the paper, and pass all difficulties one after the other.
2 – Three kinds of papers

It is never a good idea to pick a random paper and start implementing in right away. There are a lot of papers out there, which means there is a lot of garbage. All publications can fit into three categories:
2.1 – The groundbreaking paper

Some really interesting, well-written, and original research. Most of these papers are coming out of top-tier universities, or out of research teams in smaller universities that have been tackling the problem for about six to ten years. The later is easy to spot: they reference their own publications in the papers, showing that they have been on the problem for some time now, and that they base their new work on a proven record of publications. Also, the groundbreaking papers are generally published in the best journals in the field.
2.2 – The copycat paper

Some research group that is just following the work of the groundbreaking teams, proposing improvements to it, and publishing their results of the improvements. Many of these papers lack proper statistical analysis and wrongly conclude that the improvements are really beating the original algorithm. Most of the time, they really are not bringing anything except for unnecessary additional complexity. But not all copycats are bad. Some are good, but it’s rare.
2.3 – The garbage paper

Some researchers really don’t know what they are doing and/or are evil. They just try to maintain their status and privileges in the academic institution at which they teach. So they need funding, and for that they need to publish, something, anything. The honest ones will tell you in the conclusion that they failed and that the results are accurate only N% of the time (with N being a bad value). But some evil ones will lie, and say that their research was a great success. After some time reading publications, it becomes easy to spot the garbage paper and ditch them.
3 – How to read a scientific paper

A lot has already been written on the topic, so I am not going to write much about it. A good starting point is: How to Read a Paper by Srinivasan Keshav. Below are a few points that I found useful while I was reading scientific publications.
3.1 – Find the right paper

What you want to implement is an original paper, one that started a whole domain. It is sometimes okay to pick a copycat paper, if you feel that it brings real improvements and consistency to a good but immature groundbreaking paper.

So let’s say you have a paper as your starting point. You need to do some research in its surroundings. For that, the strategy is to look for related publications, and for the publications being listed in the “References” section at the end of the paper. Go on Google Scholar and search for the titles and the authors. Does any of the papers you found do a better job than the paper you had originally? If yes, then just ditch the paper you were looking at in the first place, and keep the new one you found. Another cool feature of Google Scholar is that you can find papers that cite a given paper. This is really great, because all you have to do is to follow the chain of citations from one paper to the next, and you will find the most recent papers in the field. Finding the good paper from a starting point is all about looking for papers being cited by the current paper, and for papers citing the current paper. By moving back and forth in time you should find the paper that is both of high quality and fits your needs.

Important: note that at this stage of simple exploration and reckoning, you should not be reading and fully understand the papers. This search for the right paper should be done just by skimming over the papers and using your instinct to detect the garbage (this comes with experience).
3.2 – Do not read on the screen

Print the publication on hard paper and read the paper version. Also, do not reduce the size in order to print more on each page. Yes, you will save three sheets of paper, but you will lose time as you will get tired faster reading these tiny characters. Good font size for reading is between 11 and 13 points.
3.3 – Good timing and location

Do not read a paper in the middle of the night, do it at a moment of the day when your brain is still fresh. Also, find a quiet area, and use good lighting. When I read, I have a desk lamp pointing directly at the document.
3.4 – Marker and notes

Highlight the important information with a marker, and take notes in the margin of whatever idea that pops in your head as you read.
3.5 – Know the definitions of all the terms

When you are used to read mostly news articles and fiction, your brain is trained to fill-in meaning for words that you do not know, by using context as a deduction device. Reading scientific publications is a different exercise, and one of the biggest mistake is to assume false meaning for a word. For instance in this sentence “The results of this segmentation approach still suffer from blurring artifacts”. Here two words, “segmentation”, and “artifacts”, have a general meaning in English, but also have a particular meaning in the domain of Computer Vision. If you do not know that these words have a particular meaning in this paper, then while reading without paying attention, your brain will fill-in the general meaning, and you might be missing some very important information. Therefore you must (i) avoid assumptions about words, and whenever in doubt look up the word in the context of the domain the publication was written, and (ii) write a glossary on a piece of paper of all the concepts and vocabulary specific to the publication that you did not know before. If you encounter for the first time concepts such as “faducial points” and “piece-wise affine transform”, then you should look-up their precise definitions and write them down in your glossary. Concepts are language-enabled brain shortcuts, and allow you to understand the intent of the authors faster.
3.6 – Look for statistical analysis in the conclusion

If the authors present only one curve from their algorithm and one curve from another algorithm, and say “look, it’s 20% more accurate”, then you know you’re reading garbage. What you want to read is: “Over a testing set of N instances, our algorithm shows significant improvement with a p-value of 5% using a two-sample t-test.” The use of statistical analysis shows a minimum of driving from the author, and is a good proof that the results can be trusted for generalization (unless the authors lied to make their results look more sexy, which can always happen).
3.7 – Make sure the conclusions are demonstrating that the paper is doing what you need

Let’s say you want an algorithm that can find any face in a picture. The authors of the paper say in the conclusion that their model was trained using 10 poses from 80 different people (10 x 80 = 800 pictures), and that the accuracy of face detection with the training set was 98%, but was only 70% with the testing set (picture not used during training). What does this mean? This means that apparently, the algorithm has issues to generalize properly. It performs well when used on the training set (which is useless), and perform worse when used in real-world cases. What you should conclude at this point is that maybe, this paper is not good enough for what you need.
3.8 – Pay attention to the input data used by the authors

If you want to perform face detection with a webcam, and the authors have used pictures taken with a high-definition camera, then there are chances that the algorithm will not perform as well in your case as it did for the authors. Make sure that the algorithm was tested on data similar to yours or you will end up with a great implementation that is completely unusable in your real-world setup.
3.9 – Authors are humans

The authors are humans, and therefore they make mistakes. Do not assume that the authors are absolutely right, and in case an equation is really hard to understand or follow, you should ask yourself whether or not the authors made a mistake there. This could just be a typo in the paper, or an error in the maths. Either case, the best way to find out is to roll out the equations yourself, and try to verify their results.
3.10 – Understand the variables and operators

The main task during the implementation of a publication is the translation of math equations in the paper into code and data. This means that before jumping into the code, you must understand 100% of the equations and processes on these equations. For instance, “C = A . B” could have different meaning. A and B could be simple numbers, and the “.” operator could simply be a product. In that case, C would be the product of two numbers A and B. But maybe that A and B are matrices, and that “.” represents the matrix product operator. In that case, C would be the product matrix of the matrices A and B. Yet another possibility is that A and B are matrices and that “.” is the term-by-term product operator. In that case, each element C(i,j) is the product of A(i,j) and B(i,j). Notations for variables and operators can change from one mathematical convention to another, and from one research group to another. Make sure you know what each variable is (scalar, vector, matrix or something else), and what every operator is doing on these variables.
3.11 – Understand the data flow

A paper is a succession of equations. Before you start coding, you must know how you will plug the output of equation N into the input of equation N+1.
4 – Prototyping

Once you have read and understood the paper, it’s time to create a prototype. This is a very important step and avoiding it can result in wasted time and resources. Implementing a complex algorithm in languages such as C, C++ or Java can be very time consuming. And even if you have some confidence in the paper and think the algorithm will work, there is still a chance that it won’t work at all. So you want to be able to code it as quickly as possible in the dirtiest way, just to check that it’s actually working.
4.1 – Prototyping solutions

The best solution for that is to use a higher level versatile language or environment such as Matlab, R, Octave or SciPy/NumPy. It is not that easy to represent a mathematical equation in C++ and then print the results to manually check them. On the contrary, it is extremely straightforward to write equations in Matlab, and then print them. What would take you two to three weeks in C++ will take take you two days in Matlab.
4.2 – Prototyping helps the debugging process

An advantage of having a prototype is that when you will have your C++ version, you will be able to debug by comparing the results between the Matlab prototype and the C++ implementation. This will be developed further in the “Debugging” section below.
4.3 – Wash-off implementation issues beforehand

You will certainly make software design mistakes in your prototype, and this is a good thing as you will be able to identify where are the difficulties with both the processes or data. When you will code the C++ version, you will know how to better architect the software, and you will produce way cleaner and more stable code than you would have without the prototyping step (this is the “throw-away system” idea presented by Frederick Brooks in The Mythical Man-Month).
4.4 – Verify the results presented in the paper

Read the “Experiment” section of the paper carefully, and try to reproduce the experimental conditions as closely as possible, by using test data as similar as possible to the ones used by the authors. This increases your chances of reproducing the results obtained by the authors. Not using similar conditions can lead you to a behavior of your implementation that you might consider as an error, whereas you are just not feeding it with the correct data. As soon as you can reproduce the results based on similar data, then you can start testing it on different kinds of data.
5 – Choose the right language and libraries

At this stage, you must have a clear understanding of the algorithm and concepts presented in the publication, and you must have a running prototype which convinces that the algorithm is actually working on the input data you wish to use in production. It is now time to go into the next step, which consists in implementing the publication with the language and framework that you wish to use in production.
5.1 – Pre-existing systems

Many times, the production language and libraries are being dictated by pre-existing systems. For instance, you have a set of algorithm for illumination normalization in a picture, in a library coded in Java, and you want to add a new algorithm from a publication. In that case, obviously, you are not going to code this new algorithm in C++, but in Java.
5.2 – Predicted future uses of the implementation

In the case there is no pre-existing system imposing you a language, then the choice of the language should be done based upon the predicted uses of the algorithm. For example, if you believe that within four to six months, a possible port of your application will be done to the iPhone, then you should choose C/C++ over Java as it would be the only way to easily integrate the code into an Objective-C application without having to start everything from scratch.
5.3 – Available libraries that solve fully or partly the algorithm

The available libraries in different languages can also orient the choice of the production language. Let’s imagine that the algorithm you wish to implement makes use of well-known algebra techniques such as principal component analysis (PCA) and singular value decomposition (SVD). Then you could either code PCA and SVD from scratch, and if there is a bug could end up debugging for a week, or you could re-use a library that already implements these techniques and write the code of your implementation using the convention and Matrix class of this library. Ideally, you should be able to decompose your implementation into sub-tasks, and try to find libraries that already implement as many of these sub-tasks as possible. If you find the perfect set of libraries that are only available for a given language, then you should pick that language. Also, note that the choice of libraries should be a trade-off between re-using existing code and minimizing dependencies. Yes, it is good to have code for every sub-task needed for your implementation, but if that requires to create dependencies over 20 different libraries, then it might be not very practical and can even endanger the future stability of your implementation.
6 – Implementation

Here are some tips from my experience in implementing publications
6.1 – Choose the right precision

The type you will use for your computation should be chosen carefully. It is generally way better to use double instead of float. The memory usage can be larger, but the precision in the calculation will greatly improve, and is generally worth it. Also, you should be aware of the differences between 32-bit and 64-bit systems. Whenever you can, create your own type to encapsulate the underlying type (float or double, 32-bit or 64-bit), and use this type in your code. This can be done with a define is C/C++ or a class in Java.
6.2 – Document everything

Although it is true that over-documenting can slow down a project dramatically, in the case of the implementation of a complex technical paper, you want to comment everything. Even if you are the only person working on the project, you should document your files, classes and methods. Pick a convention like Doxygen or reStructuredText, and stick to it. Later in the development, there will be a moment where you will forget how some class works, or how you implemented some method, and you will thank yourself for documenting the code!
6.3 – Add references to the paper in your code

For every equation from the paper that you implement, you need to add a comment citing the paper (authors and year) and either the paragraph number or the equation number. That way, when later re-reading the code, you will be able to connect directly the code to precise locations in the paper. These comments should look like:

// See Cootes et al., 2001, Equation 2.3
// See Matthews and Baker, 2004, Section 4.1.2
6.4 – Avoid mathematical notations in your variable names

Let’s say that some quantity in the algorithm is a matrix denoted A. Later, the algorithm requires the gradient of the matrix over the two dimensions, denoted dA = (dA/dx, dA/dy). Then the name of the the variables should not be “dA_dx” and “dA_dy”, but “gradient_x” and “gradient_y”. Similarly, if an equation system requires a convergence test, then the variables should not be “prev_dA_dx” and “dA_dx”, but “error_previous” and “error_current”. Always name things for what physical quantity they represent, not whatever letter notation the authors of the paper used (e.g. “gradient_x” and not “dA_dx”), and always express the more specific to the less specific from left to right (e.g. “gradient_x” and not “x_gradient”).
6.5 – Do not optimize during the first pass

Leave all the optimization for later. As you can never be absolutely certain which part of your code will require optimization. Every time you see a possible optimization, add a comment and explain in a couple of lines how the optimization should be implemented, such as:

// OPTIMIZE HERE: computing the matrix one column at a time
// and multiplying them directly could save memory

That way, you can later find all the locations in your code at which optimizations are possible, and you get fresh tips on how to optimize. Once your implementation will be done, you will be able to find where to optimize by running a profiler such as Valgrind or whatever is available in the programming language you use.
6.6 – Planning on creating an API?

If you plan on using your current code as a basis for an API that will grow with time, then you should be aware of techniques to create interfaces that are actually usable. For this, I would recommend the “coding against the library” technique, summarized by Joshua Bloch in his presentation How to Design a Good API and Why it Matters.
7 – Debugging

Implementing a new algorithm is like cooking a dish you never ate before. Even if it tastes kind of good, you will never know if this is what it was supposed to taste. Now we are lucky, since unlike for cooking, software development has some helpful trick to increase the confidence we have in an implementation.
7.1 – Compare results with other implementations

A good way to wash out the bugs is to compare the results of your code with the results of an existing implementation of the same algorithm. As I assume that you did correctly all the tasks in the “But before you jump” section presented above, you did not find any available implementation of the algorithm (or else you would have used it instead of implementing the paper!). As a consequence, the only other implementation that you have at this stage is the prototype that you programmed earlier.

The idea is therefore to compare the results of the prototype and the production implementation at every step of the algorithm. If the results are different, then one of the two implementations is doing something wrong, and you must find which and why. Precision can change (the prototype can give you x = 1.8966 and the production code x = 1.8965), and the comparison should of course take this into account.
7.2 – Talk with people who have read the paper

Once all the steps for both implementations (prototype and production) are giving the exact same results, you can gain some confidence that your code is bug free. However, there is still a risk that you made a mistake in your understanding of the paper. In that case, both implementations will give the same results for each step, and you will think that your implementations are good, whereas this just proves that both implementations are equally wrong. Unfortunately, there is no way that I know of to detect this kind of problems. Your best option is to find someone who has read the paper, and ask that person questions regarding the parts of the algorithm you are not sure about. You could even try to ask the authors, but your chances to get an answer are very low.
7.3 – Visualize your variables

While developing, it is always good to keep an eye on the content of the variables used by the algorithm. I am not talking about merely printing all the values in the matrices and data you have, but finding the visualization trick adapted to any variable in your implementation. For instance, if a matrix is suppose to represent the gradient of an image, then during the coding and debugging, you should have a window popping up and showing that gradient image, not just the number values in the image matrix. That way, you will associate actual an image with the data you are handling, and you will be capable of detecting when there is a problem with one of the variables, which in turn will indicate a possible bug. Inventive visualization tricks include images, scatter plots, graphs, or anything that is not just a stupid list of 1,000 numbers and upon which you can associate a mental image.
7.4 – Testing dataset

Generating data to experiment with your implementation can be very time consuming. Whenever you can, try to find databases (face database, text extract databases, etc.) or tools for generating such data. If there are none, then do not lose time generating 1000 samples manually. Code a quick data generator in 20 lines and get done with it.
Conclusion

In this article, I have presented good practices for the implementation of a scientific publication. Remember that these are only based on my personal experience, and that they should not be blindly followed word for word. Always pay attention when you read and code, and use your judgement to determine which of the guidelines presented above fit your project. Maybe some of the practices will hurt your project more than it will help it, and that’s up to you to find out.

Now go implement some cool algorithm!

To receive a notification email every time a new article is posted on Code Capsule, you can subscribe to the newsletter by filling up the form at the top right corner of the blog.
As usual, comments are open at the bottom of this post, and I am always happy to welcome questions, corrections and contributions!
References

How to Read a Paper by Srinivasan Keshav
How to Design a Good API and Why it Matters by Joshua Bloch
The Mythical Man-Month by Frederick Brooks
The 20 / 80 Productivity Rule by Emmanuel Goossaert
Google Scholar

總結

以上是生活随笔為你收集整理的如何实现科技论文里面的算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。