特意結合數學的程式練習

有些類型的應用程式開發，確實是用不上數學，特別是在程式庫與框架如此豐富的年代，因此「寫程式要不要用到數學」是個永遠有得吵的話題。而就開發者而言，這不過是種要或不要的選擇，既然如此，若本身從事的開發類型從不需要用上數學，何妨特意從事一些須結合數學的程式設計呢？

數學不好的程式高手？

「寫程式要不要用到數學」有許多類似的題目可以替代，像是「程式設計跟數學有什麼關係」、「數學不好適合走程式設計嗎」，甚至是「有沒有數學不好的程式高手」，曾經看過類似題目的開發者，大概也都知道接下來的討論會發展成什麼態勢了，各自的擁護派或反對派，或許剛開始還會熱血地進去戰一戰，然而看過幾次後，多半就對這類時不時浮上來的題目無感了。

只談「數學」兩個字，範圍過於籠統，而提出這類題目時，發問者應該多半想像的是自身不熟悉的那塊數學，通常會是微積分、線性代數之類的吧！

在此暫且將發問者分為兩類，一類是誠心想知道數學在程式設計上的比重，以便為未來做準備（對這類人可報以敬意），另一類是意識到自身數學能力並不好，想確定在不涉及數學的情況下，能否在程式設計這領域有穩定或不錯的發展，甚至想特意尋找「數學不好的程式高手」來加強「信心」？

在我剛開始轉換跑道的那段期間，有很長一段時間在寫程式時，確實沒用過微積分、線性代數之類的數學，也就是靠「所謂的邏輯能力」就可以撰寫程式。不過「邏輯」本身也是門數學，只是開發者多半沒意識到罷了，大聲嚷嚷著「程式設計更重要的是邏輯能力」的開發者，或許接觸一下Prolog，像是我先前專欄〈用「邏輯」寫程式〉提及的內容，測試一下自身邏輯能力是否真行得通。

因為就我的經驗，確實有段時間沒用上數學，對於數學重不重要這件事，無論是擁護派或反對派意見，或者臺灣多數程式工作場合用不上數學的現實派說詞，是可以理解與接受的，畢竟那是種選擇。

不過，我無法理解的是，真有自認為「數學不好的程式高手」跳出來說「我的數學GGYY（數學確實很爛的一些事實），現在程式還不是寫得OOXX（好棒棒的事實）」語氣間感覺頗為沾沾自喜？

從Three.js到WebGL

由於我對於3D繪圖的東西一直很有興趣，就算是在剛轉換跑道的那段期間用不上數學，卻因為對3D圖像的展現有興趣，而特意收集了不少相關的文件與書籍，像是《Java 2D/3D繪圖》、《Game Programming Gems》等，並在〈電腦圖學入門〉中記錄了一些心得。

前陣子，我因為發現了瀏覽器版本的雕塑軟體〈SculptGL〉，而知道WebGL這項技術，然而聽說WebGL入門不易，一開始我選擇封裝WebGL的Three.js來做為入門，目的是希望從中理解到更多3D繪圖相關的元素。不過，使用Three.js需知道的東西，感覺與OpenSCAD相比並沒有多出太多。或許是Three.js封裝地太好，想要寫些什麼時，就活像數學重不重要的討論，聲稱用不上數學的程式設計者那樣，只要找出對應的API，然後組合起來就可以，就算是物理模擬，也能這樣兩三下就解決掉需求。

一開始選擇Three.js，其實是想藉由接觸它，特意多認識3D繪圖時必要的數學。大概是因為找不到那種獲得新知的滿足感，我開始找幾篇WebGL的文件閱讀，然後不小心認知到著色器的運作模式後，就決定「來深入點玩WebGL順便多學點數學好了」！

然後，思考就來到頂點與像素的世界，因為玩耍過OpenSCAD，對於頂點與索引陣列算是熟悉的，然而，在像素操作的部份，就比較新鮮。在我玩到立方體映射（Cube mapping），使用向量從立方體貼圖上樣顏色的方式時，那種終於知道鏡面反射貼圖，以及環境全景圖怎麼做的成就感，特別強烈。

最近接觸的矩陣處理，也帶來了一些樂趣。例如，知道OpenGL曾經有不少開發者，他們不清楚矩陣標示法與線性結構編寫矩陣之間，其實是兩回事，因而經常發生運算錯誤的問題，OpenGL在以線性結構編寫矩陣時，是以「行」為主（column-major），WebGL是從OpenGL衍生而來，慣例上以線性結構編寫矩陣時也是以行為主，為了輔助WebGL進行矩陣運算的glMatrix程式庫，官方網站首頁也直接標示出以行為主的這件事實。

因為向量與矩陣在3D程式特別重要，所以，著色器程式在向量與矩陣運算，提供友善支援。雖說如此，還是要懂數學上要如何處理，而且，自行實現平移、縮放、旋轉、投影矩陣時，也是有趣的過程。在這當中，還可以順便看看glMatrix的原始碼，認識更多數學與程式設計間實現時相關的議題。

程式如何特意結合數學

寫程式需要用上數學的擁護派，近來講話應該可以大聲一些。經典說法之一是「過去說寫程式用不到數學的人，看到機器學習都後悔了」，不過，我也曾經特意去接觸機器學習，裡面也用了不少的向量、矩陣，只不過或許是因為沒有愛，我對NumPy、SciPy始終熱不起來，從圖學中運用向量與矩陣，總覺得比從機器學習中運用有趣多了，同樣的道理，對我來說，從圖學中運用多項式與微積分，總覺得比資料科學中運用它們來得有滿足感。

這也就是說，數學是個籠統的名詞，想在程式設計上結合數學，有許多的選擇。如果開發者是誠心想知道數學在程式設計的比重，以便為未來做準備，那麼，可以多接觸幾種需要用到數學的開發類型。還在熱頭上的機器學習、資料科學等，當然是個選擇，對我來說，密碼學也不錯，偶而虐一下腦袋，幸運的話可以獲得打怪成功的感覺。其實哪一個都好，選個有感的領域就是了。

開發者也可以找些與程式設計較緊密結合的書來看，我在〈程式人的數學書〉提到一些。其中《Good Math》提到lambda演算與圖靈機，有興趣的話，可以進一步看看《深入理解運算原理》，裡面還談到了，如何用lambda演算與圖靈機打造出自己的程式語言。

這又如何？有些開發類型依舊用不上數學啊？然而哪天需要用上時，就已經有所準備了，不是嗎？

而且這是一種特意練習。我的經驗是，無論練習的是哪一塊數學，練習過程所得到的思考方式，對於掌握程式設計本身的幫助是潛移默化。在特意結合某數學的某程式設計主題下，所訓練出來的思考方式，在面對另一主題需要的另一塊數學時，就不會畏懼且易於找到切入的思考點，因為開發者會知道，無論是程式設計或是數學，終有其思考的順序與方式。

不用特地迴避數學

發問者在提出「寫程式要不要用到數學」之類的問題時，可以想想自身是否特意在迴避，然後選擇性地過濾掉「程式會用上數學」這方面的意見，甚至在發現「數學不好的程式高手」而感到安心呢？

與其特地迴避，不如刻意去找些可以結合數學的程式設計來練習。別忘了也常有人說「數學好的人程式也不見得會寫啊」，這表示兩邊都是公平的，都是需要特意練習的（將數學公式化為程式碼並非許多人想像那麼簡單，有「數值方法」這類課程在專門探討），確實地，有些程式設計不需要用上數學，然而，我們可以選擇當個會數學也會寫程式的開發者！