有些類型的應用程式開發,確實是用不上數學,特別是在程式庫與框架如此豐富的年代,因此「寫程式要不要用到數學」是個永遠有得吵的話題。而就開發者而言,這不過是種要或不要的選擇,既然如此,若本身從事的開發類型從不需要用上數學,何妨特意從事一些須結合數學的程式設計呢?
數學不好的程式高手?
「寫程式要不要用到數學」有許多類似的題目可以替代,像是「程式設計跟數學有什麼關係」、「數學不好適合走程式設計嗎」,甚至是「有沒有數學不好的程式高手」,曾經看過類似題目的開發者,大概也都知道接下來的討論會發展成什麼態勢了,各自的擁護派或反對派,或許剛開始還會熱血地進去戰一戰,然而看過幾次後,多半就對這類時不時浮上來的題目無感了。
只談「數學」兩個字,範圍過於籠統,而提出這類題目時,發問者應該多半想像的是自身不熟悉的那塊數學,通常會是微積分、線性代數之類的吧!
在此暫且將發問者分為兩類,一類是誠心想知道數學在程式設計上的比重,以便為未來做準備(對這類人可報以敬意),另一類是意識到自身數學能力並不好,想確定在不涉及數學的情況下,能否在程式設計這領域有穩定或不錯的發展,甚至想特意尋找「數學不好的程式高手」來加強「信心」?
在我剛開始轉換跑道的那段期間,有很長一段時間在寫程式時,確實沒用過微積分、線性代數之類的數學,也就是靠「所謂的邏輯能力」就可以撰寫程式。不過「邏輯」本身也是門數學,只是開發者多半沒意識到罷了,大聲嚷嚷著「程式設計更重要的是邏輯能力」的開發者,或許接觸一下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演算與圖靈機打造出自己的程式語言。
這又如何?有些開發類型依舊用不上數學啊?然而哪天需要用上時,就已經有所準備了,不是嗎?
而且這是一種特意練習。我的經驗是,無論練習的是哪一塊數學,練習過程所得到的思考方式,對於掌握程式設計本身的幫助是潛移默化。在特意結合某數學的某程式設計主題下,所訓練出來的思考方式,在面對另一主題需要的另一塊數學時,就不會畏懼且易於找到切入的思考點,因為開發者會知道,無論是程式設計或是數學,終有其思考的順序與方式。
不用特地迴避數學
發問者在提出「寫程式要不要用到數學」之類的問題時,可以想想自身是否特意在迴避,然後選擇性地過濾掉「程式會用上數學」這方面的意見,甚至在發現「數學不好的程式高手」而感到安心呢?
與其特地迴避,不如刻意去找些可以結合數學的程式設計來練習。別忘了也常有人說「數學好的人程式也不見得會寫啊」,這表示兩邊都是公平的,都是需要特意練習的(將數學公式化為程式碼並非許多人想像那麼簡單,有「數值方法」這類課程在專門探討),確實地,有些程式設計不需要用上數學,然而,我們可以選擇當個會數學也會寫程式的開發者!
專欄作者
熱門新聞
2024-09-29
2024-10-01
2024-10-01
2024-10-01
2024-10-01
2024-10-03
2024-09-29