Matlab、Julia與Python之間的對比 | Toby Driscoll

banq發表於2019-07-04

我已經使用MATLAB超過25年了,雖然這不是我學習程式設計第一種語言,但憑藉它我得以進入數學方法時代,瞭解MATLAB對我的職業生涯非常有益。
但是另外一方面,Python在科學計算中的崛起已經不可忽視,MathWorks肯定有同樣的感受:它們不僅增加了從MATLAB中直接呼叫Python的能力,而且還採用了一些語言特性,例如對二元運算子的運算元進行更積極的廣播
這已經達到了我一直質疑我在研究和教學中繼續使用MATLAB的程度,雖然大部分對於我來說很容易,我也為此投入了大量的精力,但很難激起真正我學到新東西的動力。
我編寫過基於MATLAB的教科書,這本書有40多個函式和160個計算例項,它涵蓋了我認為使用MATLAB進行數值科學計算的全面基礎,我今年開始將程式碼翻譯成JuliaPython。這種經歷使我對與科學計算相關的三種語言有了特殊的看法,我試圖在下面進行討論。
我將主要討論成本和開放性問題,MATLAB與Python和Julia不同,既不是無啤酒也不是無語音。當你把成本放在一邊時,這些語言之間的許多差異的有用框架在於它們的起源。MATLAB,最古老的,優先考慮數學,特別是數字導向的數學;Python於20世紀80年代末開始,它以電腦科學為中心;Julia從2009年開始在這些方面之間取得更多平衡。

MATLAB
最初,MATLAB中的每個值都是一個雙精度浮點數的陣列。陣列和浮點兩個都是靈感的設計決策。
用於浮點的IEEE 754標準直到1985年才被採用,並且記憶體是用K而不是G測量的。浮點雙精度不是表示字元或整數的最有效方式,但它們是科學家,工程師和越來越多的數學家想要在大多數時間裡使用。此外,不必宣告變數,也不必顯式分配記憶體。讓計算機處理這些任務,並將資料型別放在一邊,釋放你的大腦,思考對資料進行操作的演算法。
陣列非常重要,因為線性代數中的數值演算法以LINPACKEISPACK的形式出現在自己的陣列中。但是,使用科學計算中的標準承載FORTRAN 77訪問它們是一個多步驟過程,涉及宣告變數,呼叫隱式命名例程,編譯程式碼,然後檢查資料和輸出檔案。寫一個矩陣乘法A*B並立即列印出答案是一個改變遊戲規則的人。
MATLAB還使圖形變得簡單且易於訪問。沒有任何特定於機器的低階呼叫庫,只是plot(x,y),還有更多的創新,例如baked-in複雜的數字,稀疏矩陣,構建跨平臺圖形使用者介面的工具,以及前沿的ODE求解器套件,使MATLAB 成為以思維速度進行科學計算的地方。
然而,對於互動式計算而言,理想的設計,即使是冗長的計算,並不總是有助於編寫好的和高效能的軟體
在許多函式之間移動資料需要處理大量變數並經常查閱有關輸入和輸出引數的文件。平面名稱空間中每個磁碟檔案的一個功能對於一個小專案來說非常簡單,但對於大型專案來說卻是一個令人頭痛的問題 如果您想避免速度瓶頸,則必須應用某些程式設計模式(向量化,記憶體預分配)。科學計算現在被應用於更多的域,具有大量不同的本地型別的資料。等等。
MathWorks透過繼續在MATLAB中進行創新來做出回應:行內函數,巢狀函式,變數閉包,眾多資料型別,物件導向的特性,單元測試框架等等。每項創新都可能是解決一個重要問題的方法。但是,40年這些變化的積累產生了影響概念簡單性和統一性的副作用。在2009年,我寫了一本書,在不到100頁的篇幅中,我很好地涵蓋了我認為MATLAB的基本內容。據我所知,所有這些東西仍然可用。但是現在你需要了解更多才能稱自己為精通。

(banq評:MATLAB只靠資料結構和演算法打天下的套路已經不夠用了,需要加入模式等物件導向或函式語言的設計要素)

Python
從某種意義上說,Python的歷史似乎幾乎是MATLAB的映象。兩者都具有互動式命令列,並且不受變數宣告和編譯的影響。但MATLAB是作為數值分析師的遊樂場而建立的,而Python是在考慮駭客的情況下建立的。然後透過修訂和擴充套件,每個人都向其他受眾發展。

在我看來,Python仍然缺乏數學吸引力...

除了小煩惱之外,我發現Python + NumPy + SciPy生態系統變得笨拙且不一致。儘管語言主要用於物件導向,但存在一個矩陣類,但它的使用不鼓勵並且將被棄用。也許MATLAB只是腐蝕了我,但我發現矩陣是一種足夠重要的物件型別,物件導向OOP不是它的主要賣點嗎?

在這些地方,數字生態系統對我來說看起來有點薄弱!...

一些專家認為,Python程式碼難以跟上編譯語言的執行速度...

我想我明白為什麼Python對科學計算領域的許多人來說都是如此令人興奮。它具有一些MATLAB-ish語法和功能。它有很好的工具,可以很好地與其他語言和計算領域配合使用。它提供了免費且具有更好的長期可重複性。很明顯,它適用於許多可能沒有理由改變的人。

但是對於我這樣已經知道如何在科學計算中程式設計的人來說,Python更像是一項學習使用的苦差事(banq注:習慣資料結構演算法的實用主義想改變很難)。我們暫時不會知道它是否會繼續席捲整個社群,或者已經接近頂峰。我沒有特殊的預測能力,但我對它未來看跌。

Julia
Julia有一個後來者的優點和缺點。我讚賞朱莉婭的創作者認為他們可以做得更好

我們想要一種開源的語言,擁有自由許可。我們希望C的速度與Ruby的活力。我們想要一種同色的語言,像Lisp這樣的真正的宏,但是有一些明顯的,熟悉的數學符號,比如Matlab。我們想要一些像Python一樣可用於通用程式設計的東西,像R一樣易於統計,像Perl一樣自然地用於字串處理,像Matlab一樣強大的線性代數,擅長將程式粘合在一起作為shell。一些簡單易學的東西,但卻讓最嚴重的駭客感到高興。我們希望它是互動式的,我們希望它被編譯。

在很大程度上,我相信他們已經取得了成功。在1.0版本的後期,他們似乎略微淡化了REPL,並且有一些幾乎無償的離開MATLAB的教堂。(LinRange和linspace 究竟哪個更好?)但這些都是狡辯。

這是我使用的第一種超越ASCII的語言。使用變數ϕ和運算子之類的我仍然會得到不合理的滿足感≈。它不僅僅是化妝品; 能夠看起來更像我們寫的數學表示式是真正的加號,雖然它確實使教學和文件有點複雜化。

使用Julia工作讓我覺得我選擇了一些程式設計習慣,因為MATLAB的選擇,而非內在的優越性...

多重排程的一大特點使得某些事情比物件導向更容易和更清晰。例如,假設您使用傳統的面嚮物件語言的Wall和Ball類。哪個類應該放入Wall與Ball的碰撞行為呢?或者你需要一個Room類來扮演裁判?這些問題可以讓我分心。使用多個分派時,資料將打包到物件型別中,但對資料進行操作的方法不會繫結到類。

function detect_collision(B::Ball,W::Wall)


瞭解型別,但是它們是獨立定義的。我需要花費大量的程式設計來理解多重排程的概念對於擴充套件語言有多麼有趣和潛在重要。

我還沒有看到Julia承諾的超過MATLAB的速度提升。部分原因是我的相對缺乏經驗和我所做的任務,但部分原因還在於MathWorks在自動最佳化程式碼方面做了不可思議的工作。無論如何,這不是我在大多數時間關注的編碼方面。

我使用了Julia程式設計花一段時間之後才感到舒服(也許我只是變老了)。它讓我對資料型別的思考超出了我的想象,並且總是潛在地懷疑我錯過了正確的方法來做某事。但是對於日常使用,我現在幾乎可以轉向Julia,將其作為MATLAB使用。

底線
MATLAB是企業解決方案,尤其適用於工程。對於基本的數字任務來說,這可能仍然是最容易學習的。細緻的文件和數十年的貢獻學習工具絕對重要。
MATLAB是科學計算世界的寶馬轎車。這是昂貴的,那是在你開始談論配件(工具箱)之前。您需要為堅如磐石的,平穩的效能和服務付出代價。它也吸引了不成比例的仇恨
Python是福特的皮卡。它無處不在,受到許多人的歡迎(在美國)。它可以做你想做的一切,它是為了做一些其他車輛無法做到的事情。你偶爾會想要借一輛。但它並沒有提供很好的純粹駕駛體驗。
Julia是特斯拉。它建立了一個改變未來的大膽目標,它可能會。它也可能只是一個腳註。但與此同時,你會得到你的風格,並有足夠的力量。

相關文章