Jserv's blog

清楚思維

昨天 Cheyi 來信問到一個跟 IEEE Standard 754 Floating-Point 有關的問題，內容就不贅述，或許有空再來整理，而回信時，讓我想起之前在 Embedded.com 讀過的短文 [Right-brained programming]，作者 Niall Murphy 在業界耕耘許久，也發表過多篇技術文件，不過這篇短文不談深入的技術，而如標題所言，探討程式設計時該有的 "Right-brained"。

除了圖學，Niall Murphy 對嵌入式系統的 RTOS 有深入的看法與經驗。即使在 32-bit 甚至是 64-bit CPU 風行的今日，還有很多應用採用 8-bit MCP，不乏消費性電子裝置，整體的軟體開發門檻降低了，但是關鍵性的程式設計還是存在許多技術性的議題。首先，Niall Murphy 用 DDJ 上 Robert D. Grappel 發表的文章 [Rotating a Weather Map] 作點題，乍看對圖片作旋轉動作似乎是每個研習過圖學的工程師都該熟悉的操作，何難之有？問題是，今天要處理的對象是低階的硬體 (486/25MHz Embedded PC) 上面的圖形資料庫，這的確是個挑戰，所以，Robert 發展了一個 in-place 的演算法，透過數學的技巧來作最佳化處理，而 Naill 則給了以下的眉批：

That was a perfect example of solving a problem backwards. Ask yourself, "If I had the answer, would I be able to discover the question?" Other mathematical challenges are amenable to this sort of approach. Finding the square root of a number is fiendishly complex. If you already had the answer, however, checking it by squaring it is a simple case of multiplying it by itself. So if we guess at the answer we can check it. If the guess is too large, the result of squaring it is larger than the original value. We can iteratively improve our guesses as we get the result of each trial.

的確，我們不該捨近求遠，妥善使用既有的技術是相當重要的，而這正是「清楚思維」的第一步。

再來，作者以其豐富的 RTOS 經驗，談到 watchdog timer 的設計與 multi-tasking 的考量，在他之前的文章 [Watchdog Timers] 做了很好的闡述，事實上，出發點只是很單純的動機，一個 system-wide 的 monitor 竟然會涉及潛在的致命問題，這讓許多嵌入式系統的開發者，會不自覺膽顫心驚。於是，Naill 用很簡單的話說明這個議題：

Whenever you're trying to establish a design limit, as well as asking what is the smallest that limit can be, remember to look at the other direction, in case the answer at that extreme might be more useful.

這個說法在軟體工程的書籍也多次提過，基本上只是用詞的不同，然而，特別在 Realtime system 的領域，更是不可輕忽，就如之前的 blog [Priority inversion 簡介] 所提，同樣是 watchdog timer 設計的效應，就讓 NASA 的火星探測計畫幾乎徹底失敗，面對這種災難性的錯誤，一個程式設計師怎能不三思「清楚思維」的重要性呢？

接著就以許多人小時候玩過的 ZX Spectrum 遊戲為例，以這個僅有 48 kb 記憶體的硬體裝置來探討電腦遊戲設計上，必須做出的妥協，而事實也告訴我們，在十幾二十年前，當時的程式設計師就可做到的事情，反倒在今日卻常無法達到？不得不讓我們反省，是否具備「清楚思維」。

後半的篇幅中，[Every fault is a fashion] 是最讓我有深刻感觸的地方，也跟 Cheyi 來信指教的問題有些關聯。以下節錄原文的描述：

Consider a voltage that corresponds to a value of 127.2 when converted to a digital value by an ADC. An 8-bit converter is only going to provide the value 127, since the decimal place is not supported by the converter. In a noise-free environment every reading will be 127. But if there's random noise the signal will vary, while still averaging 127.2. Successive readings would be 127 most of the time, but 128 will appear often enough to raise the average above 127. There's no decimal place in a single reading, but the average of multiple readings can have that decimal place. While we want to eliminate most noise, some of it is good for us.

這簡單的文字並沒有高深的術語，何以讓我有深刻體悟呢？身處於電子數位化的時代，當我們使用任何一種消費性電子裝置時，實在會有超出「一日之所需，百工斯為備」的感觸，而數位與類比、連續與離散系統之間，並非存有鴻溝，卻是有巧妙的關聯性，之前的 blog [再探羅塞達碑石 : 連續時間系統與離散系統的橋樑] 提過這之間，工程數學的種種「魔法」。特別在設計 device driver、instrumenting，或者是 signal controlling 時，ADC (類比數位轉換) 牽涉的議題，實在不容小覷，同時，也得考慮到數位系統本身精密度與離散性質，這些，都該是一個工程人員，最基本的「清楚思維」。

[Back to basics] 與 [Keep thinking] 兩小節提到的內容，可說是 [Right-brained programming] 一文的核心概念。一般人覺得再簡單不過的語音信箱與留言系統，也充滿了學問，Niall 舉的例子相當清楚明暸，文中的技術細節原理很簡單，問題是，我們有「清楚思維」去思考嗎？

當然，在高度分化的今日，事實上對於程式設計師的要求也變得多元，或許「清楚思維」的重要性只侷限特定領域，但是，沒有「清楚思維」卻讓我們困於應用的類型與技術的深度，而無法獲得進一步的成長，謹此自勉！
由 jserv 發表於 May 20, 2006 09:42 AM