前陣子到 Study Area 閒逛時，發現了之前為公司弄的一些 PDA 軟體，同事把它 Screen Shot 起來，在那展示著：
第一幅圖是主畫面九宮格，為啥要設計成 3 by 3 的九宮格？只知道是客戶聯想集團的要求。
第二幅是 Email ；第三幅是 Browser 。
Showing posts with label software. Show all posts
Showing posts with label software. Show all posts
Friday, January 07, 2005
Saturday, July 10, 2004
The Neuron Farm
基於興趣，碩士論文我是作 Bio-machine modeling 方面的題目，在歸類上屬於人造生命（Artificial Life, ALife）的範疇，選擇的 target 是神經細胞的生長、發育。以下就先簡述一下整個概念：
這裡並不是要詳盡地模擬腦部的發育和功能執行，而是提出經過大幅簡化的模型，以利電腦模擬，及供我們驗證假設之用。經過長期考量過各種可能方案後，我決定以 Cellular Automata 來模擬神經細胞生長的環境。
考慮在一個由 CA 舖成的空間中，我們在一些選定的位置，滴上特定的化學物質，於是這些化學物質就會由滴定的點，向四周擴散。再考慮到真正的腦，對個別神經細胞而言，並非完全開放的空間，所以我們也在 CA 舖成的空間中設置各種障礙，來對空間作某種區隔。於是我們的神經細胞除了有化學的土壤外，現在也有了障礙的地形。整個生長環境豐富了許多。
有了生長環境之後，該是時候讓細胞在環境中過活了，於是我們就隨手一灑，這些神經幹細胞就被灑到 CA 構成的空間中了。既然有了前面土壤的比喻，就讓我們稱這個“灑”的動作為“播種”吧！ ^__^
神經幹細胞的生長也遵循 automata 的模式。完全因應環境中的化學梯度而長出軸突（axon）和樹突（dendrite）……環境中的化學物質有其自然的損耗率、神經細胞的成長也會消耗掉 大量的化學物質……我們可以在其中模擬神經細胞的成長、競爭與凋亡。並觀察最後長成的神經網路拓僕。
~~
為了完成這個模擬，我當然要先 survey 一下現成的東西，決定一下要以哪些工具來達成想要的效果。雖然在大規模的模擬時，在效率的考量下，比較傾向於使用 C++ ；最後我還是決定用 Java 來實作，因為要縮短開發時程下，執行效率的考量就顯得比較次要了。
在決定用 Java 實作後，我 survey 了許多 Java 下的 agent software toolkits 。在它們當中， Swarm 雖是該領域的元老，它的接繼者 Repast 卻比較合我胃口。但由於 Repast 的架構還是顯得龐雜，且我要的許多效果它也沒提供，索性就 參考一下 Repast 的作法後，自己重新開發一套合用的 toolkit 。
為了確認每一步都沒出錯，也為了好玩，在開發過程中我同時利用自己的 toolkit 撰寫了許多測試用的小程式：
左邊那個是用來 Demo 在物理上有名的布朗運動（Brownian Movement）。程式一開始會把固定數量的化學分子置於中央，分子們很快就會以 Random Walk 的方式擴散開來，其中的色溫提示我們每個位置的分子數量的多寡。
右邊那個我管它叫做 Diffusion Sun 。化學分子一開始也是置於中央，隨著每個 time tick 的推進，這個 Demo 程式會繼續滴上給定數量的分子作為補充。在給定的自然分子損耗（lose）及不斷地添加分子間會有個動態平衡，造成一個形狀像抖動的太陽般的圖像，故稱之。
接下來，我們就繼續觀摩一下這個 toolkit 還提供了甚麼：
很明顯地，右邊那兩個綠底、裡面畫有 sine 波的東東，就是示波器（socillograph）的 scope 。比較特別的是這裡的示波器原則上是無限量供應的，只要點選 toolbar 上面代表探針（probe）的 icon 即可。值得一提的還有，這裡的探針量測的不是單純的點的訊號，而是一個指定的範圍。我們可以在左圖的 Imaging 畫布上看到一個虛線框住的範圍，它對應到右上那個 scope ，以這個例子來說，scope 顯示的是整個框框內所有點的平均訊號，實際上我們可以在上面顯示其他更有用的統計。
最後，我這裡也附上 SineSun 的 jar 檔，有興趣的話，諸位看官也可以自行玩玩看 :)
Monday, February 02, 2004
The cocktail party problem
在一個雞尾酒會場上，假設有人事先在三個不同的位置分別安置了三支麥克風，意圖監聽大家的談話。由於酒會是在開放的場所舉行，麥克風錄到相互混雜的嗡鬧聲，很難好好地監聽出想要的情報。
想像你是當事人，面對好不容易錄下來的東西竟然無法派上用場，該如何是好呢？
為了解決這個難題，我們必須由各個麥克風錄到的資料中，把想要的聲音解析出來，這就是所謂的 Blind Source Separation, BSS 。
本學期生醫訊號處理（Biomedical Signal Processing）課程的 term project ，就是要利用獨立分量分析（independent component analysis, ICA）來達到 BSS 的效果。老師雖然沒限定大家實作的工具，但面對如此紛雜的矩陣及行列運算，不用 Matlab 這種好用的工具，那真是自找麻煩。以下是我完成專案的 Screen Shot：
程式一開始先在左上角的選單決定要載入的 Blind Sources ，其波形會在左邊的畫布顯示。決定好參數，並按下 Analysis 扭，我們要的訊號波形會出現在右邊的畫布。除了可以選取個別的波形來觀察外，我們還可以聽聽分解前的混音，及分解後的清音。
以這次拿來測試的聲音訊號來說，原始訊號混雜著男高音演奏、交響樂曲、搖滾歌唱、新聞撥報等四種聲音。分解出來後果然是原音重現，乾乾淨淨的，一點混雜都沒有，效果好到令我大吃一驚。
在 Pattern Recognition 課堂上，蔡文祥老師一再地提醒我們，資訊系的學生所受的訓練中，會傾向於利用合成（synthesis）的方式來解決問題，以後在解題時要是遇到瓶頸，不要忘了還有個很有用的方式，那就是利用分析（analysis）手段來處理問題。雖然當時他的目的是要強調他上課所教授的東西不只是抽象的數學式子，而是很實用的工具，還是無礙於此時此刻，在我內心響起共鳴。
Sunday, February 01, 2004
The Prolog Interpreter
這學期加入 AI 助教群，我打算讓學弟妹從實作中瞭解 Unification Algorithm ，但又不想為他們帶來太大的負擔。從眾多 Prolog language 的 open source 中，我選出了 Peter Bouthoorn 所開發的版本，它原本就是被用於教學，可惜其程式架構實在稱不上漂亮。在無法坐視不理下，我一次一小步地 refactor 它，改了幾百個回合，並將其中好幾個關鍵的地方整個重寫，才有一個適用的 Prolog Interpreter 。這真是個不錯的練習。
接下來是將這個動過手術的 Prolog Interpreter 版本當中的 Unify, OccrCheck, and UnifyVar 等 functions 挖空，要學弟妹參照 AI 課本的 Unification Algorithm 後，為這些挖空的 functions 補上血肉。
考慮到修課的人數眾多，為了讓自己在批改作業時不會哭出來，必定得把這個作業批改的流程盡量自動化。
於是我就為學弟妹準備了一對 .txt 檔: input.txt 及對應的 output.txt 。為了怕有些學弟妹過份聰明地以 printf 將 desired output 直接印出，在批改作業時另外準備其他 input 及 desired output是一定要的。這部分我以 Unit Test 的工具來自動比對，只有在比對出錯才要告訴我出錯的地方在哪，否則它只要簡單打個點代表程式還活著，並在通過所有測試後吐出 OK 就好了。
為了更省事，我在 Windows XP 下裝了 MinGW with MSYS 來模擬 Linux 的 terminal ，並寫了一個 BASH 的 script 來將這一百餘份程式作業自動作執行、比對及歸類的動作。
Unit Test tool 在 Java 下有 JUnit 可以用，無奈這裡用於開發的程式語言是 C++ ，所以勢必要另外找一套對應的工具。我最先注意到的是其中最有名的，移植自 JUnit 的 CppUnit ，進一步瞭解後，發現它 Java 味太重了，感覺很不純，而顯得有點礙手礙腳（唉呀，我是不是太偏執了），於是我最後選擇使用專為 C++ 打造的 Unit++ 。嗯，這次用起來果然很順手 ^___^
Labels: AI, compiler, CPP, functional, project, prolog, refactoring, software, unit test
Tuesday, June 17, 2003
Session Initiation Protocol
就 VoIP 網路而言， SIP是一個非常有彈性而且功能強大的通訊協定， SIP 能夠更有力的支援許多智慧型的電話網路服務及各種使用者平台，並且能夠快速而有效的發展許多先進的功能。
這次是要實作 SIP protocol 的 redirect server 。我決定讓它能夠支援 multi-user ，每次由 user end 那 send 出的 request 都會在 server 上由個別的 Thread 處理。
我將整個架構切割成 SipStack, SipProvider, SipListener 等三個 class 或 interface 。
- SipStack 將底層 network protocol 封裝起來，供 SipProvider 使用。
- SipProvider 則提供基本的 SIP message 傳遞及分送。並將收到訊息後的對應動作委託給SipListener 處理。
- SipListener 是一個 interface ，用來傾聽 SipProvider 送來的 event ，並處理。
此外， SipHeader 被設計來剖析 SIP message 的 header。
最後， RedirectServer 則 implements 了 SipListener 這個介面。 RedirectServer 也處理了所有關於 SIP redirect server 的高階協定。
由於要支援 multi-thread ，且軟體以 OO設計，再加上此 SIP 是 application layer 的 protocol ，所以決定以 Java 語言實作。
若只滿足於達到作業的功能要求，程式部分還滿單純的。唯之前並未真正接觸過網路程式設計，所以費了一翻功夫在相關程式寫法的摸索。
此外，我還為本程式立下 reusable 和 extendable 的目標。所以在分析及設計上費了一番功夫。
這個 SIP AP 的底層是採用 UDP 協定。原則上，在目前設計的架構下我們可以很容易地切換到 TCP 。也可以很容易地改寫成其他 SIP AP 。
沒力氣再掰下去了，有興趣的話，這裡也附上原始碼。請自行參照。
Tuesday, February 25, 2003
又遇 N Puzzle
針對 N Puzzle，之前以 CLIPS, C Language Integrated Production System 求解過，那是專家系統的課，所以我也很配合地，以 heuristic 的方式，寫起一條條的 production rules 。
這次研究所的 AI 課則要求分別利用 BFS (Breadth-First Search), DFS (Depth-First Search), Iterative Deepening DFS 及 A* Search 這四種方式來求解，並比較結果。
無論在 AI searh 理論方面，或是 OOA/OOD 上，這都是個有趣的練習，所以我自告奮勇要打頭陣，完成 framework, BFS, DFS, 和最後的整合及 CUI (Character-based User Interface) 等。
設計的目標有：
- Correctness
最起碼要能通老師指定的兩個 case 的試驗。 - Clarity
系統架構設計要清晰、簡單、易理解，以方便對軟體作追蹤、審閱、除錯、細部調整、功能刪減等。 - Performance
在滿足了correctness 及clarity之後，還要考量程式的高階效率和低階效率。舉凡底層資料結構的選擇、和高層抽象表示法連結上的介面設計等，都是考量重點。 - Flexibility
我們在設計時還希望對系統架構能保持一定的彈性。如，不要只針對 8-Puzzle 設計，而更進一步粹取出N-Puzzle的表達方式。
由於分析及設計階段就是採用 OOA/OOD 的方式，所以很自然地要採用支援 OO 的程式語言來實作。經討論，我們決定採用 ANSI C++ 來實作這份設計，並利用 GNU Compiler Collection 來製作可執行檔。
雖然我們只在 Windows 下的 DJGPP 搭配 rhide 的 IDE 及 Linux 下的 g++ 搭配 make 試著編譯過我們的源碼。但理論上應可以適用於任何支援「完整」ANSI C++ 語法的平台。除了 STL 外，還使用了namespace，所以古老的 C++ 編譯環境可能無法順利編出可執行檔。
※請參閱附件：
- The Report
- Its UML diagram
Monday, December 10, 2001
軟體系統的秩序起源－－《建築的永恆之道》評介之續篇
這一回，就如之前規劃的，來聊聊“軟體構築”。更精確地說，是軟體系統中，秩序的來源。
大體上，這篇文章會由我認知到這些想法的時間先後來描述：
～～
大部分的程式員，只要從事過幾個軟體系統的構築，在經過多次日以繼夜與軟體臭蟲纏鬥的歷練之後，相信很容易就能體認什麼叫做 garbage in garbage out－－電腦是個沒有自己想法的傻蛋，它只會依計行事，它只能根據程式員編撰的指令列表，逐一地執行指令，不多也不少。
「軟體系統的秩序是程式員從外頭強加進來的」
這就和每一個精密的人造製品，如鐘錶、手機、電腦等一樣，也如同每座偉大的建築物般，不用費太多想像，就可以知道其幕後必有設計者設計出這些東西。
Ｘ Ｘ Ｘ Ｘ Ｘ Ｘ
只要構築過幾個中型以上的軟體系統，就會發現，我們很難真正對這些系統的每一個細節都顧慮到：
隨著軟體系統規模的加大，緊接而來的複雜度滋長，是非常可怕的，所以每個優秀的程式設計師都很能體認，人類的腦容量在面對大型軟體系統時顯得十分卑微。
但是一個又一個重量級的軟體系統還是被完成了！難道就只靠善盡一些分析、設計的方法、流程等軟體管理方法。就能維持住我們挹注到系統中的秩序？人們真的就只靠自己對每一個細節的精確掌握就防堵了因開發過程中導致的“軟體熵”快速滋長？
晚近的軟體工程都非常強調軟體構築是一個反覆的過程：分析一些後再設計一些或撰一些程式碼；設計一些後，在撰碼之前，也可能再作分析的工作；撰過一些碼了，也可能再去作分析、設計的工作。整個過程充滿著意外、挫折、驚喜與學習。
「軟體系統與其建構者在互動中而滋長出秩序」
雖然很多人也許不願意承認，但軟體系統中的秩序並非只是單純地由程式師從外界引入。即使在構築的過程，軟體系統也透過人和外界環境產生豐富的互動。有時陷入混亂；有時軟體的完成，甚至還有水到渠成之感呢。
Ｘ Ｘ Ｘ Ｘ Ｘ Ｘ
在生物學上，有一個貫穿這個學門的通則，這對生物學這門充滿例外和驚奇的領域來說，的確是十分罕見的，這項一般性原理就是 Darwin 所提出的《天擇》
「軟體系統的秩序也可經由“天擇”產生」
天擇是生物演化的機制，而由John H. Holland 所提出的遺傳演算法作了第一次在電腦上實現天擇演化的示範。
現在，天擇已經被借用到許多軟體系統裡，以解決一些關於設計、模式識別及特徵搜尋等問題。並將這門研究統稱為“演化式計算”。
演化式計算解決問題的方式和傳統軟體如作業系統的設計方式雖然有很明顯的差距。但他們對於軟體系統秩序的來源，都較傾向於“由外而內”。
傳統軟體系統的秩序是程式員由外界給定的；演化式軟體系統的秩序是經由天擇選出後再注入系統的，而挑選的標準大致還是程式員由外指定的。
Ｘ Ｘ Ｘ Ｘ Ｘ Ｘ
在許多情況下，我們對問題沒有一個明確的解法，而演化式計算的方法又顯得太過緩慢及浪費計算資源。
有一個做法是，先找出系統中的交互關係，據以建立軟體模型，然後讓這個模型設計自己，使解答經由“自我組織”的方式“突現”出來。
對我而言，軟體秩序中最難有直覺性認知的來源就是這種被 Kauffman 稱為自在的秩序（order for free）的自我組織原理。
「自我組織也可為軟體系統產生自發的秩序。」
非常複雜的系統通常具備收斂性的變化流程：恆定性或微擾下的穩定性背後之基本原理，也是許多複雜系統的自然特徵。
自我組織是自然界中最普遍的秩序原理，對物理學家而言，一點也不陌生。而天擇及自我組織聯手造就了生命系統的秩序。
英國神學家Paley曾想像有個人，在路上撿到了一只錶，這人發現「在事物裡有一個秩序原理，這個原理將這個錶的零件安排成目前的形式」根本不可能。因為「他從來沒見過由秩序原理製造的錶；也不能想像所謂秩序原理究竟是什麼，除非指的是鐘錶匠的智慧。」
Kauffman的錶是從內部經“自在的秩序”設計出來的。Paley 的錶是由外部的鐘錶匠設計的。Darwin的錶是以時間過程中純粹偶然事件的累積設計的。
～～
呵！遲了一個禮拜才整理出來，實在是最近比較忙，一不小心時間就從指縫溜了過去。
所幸，還是整理出來了，對自己雖有個交代，內文脈絡卻顯得不大連貫。倉促行文，諸位看官就把它當作消遣，看看就好 :p
Labels: concept, order, self organization, software
Thursday, July 13, 2000
《教堂與市集》的格言
[格言 1] 好軟體都是起源於程式發展者要解決切身之痛。
1. Every good work of software starts by scratching a developer's personal itch.
[格言 2] 優秀的程式師知道要寫程式，偉大的程式師知道要改寫（和重覆利用）程式。
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
[格言 3] “計畫好如何捨棄一條路吧，你遲早會想盡辦法這麼做的。”
-- 引自 Fred Brooks 《人月迷思》 一書的第十一章
3. "Plan to throw one away; you will, anyhow."
-- Fred Brooks, "The Mythical Man-Month", Chapter 11
[格言 4] 抱持正確的態度，就會發現有趣的問題。
4. If you have the right attitude, interesting problems will find you.
[格言 5] 當你對一個問題不再感興趣時，你最後的責任就是找位能勝任的接棒人。
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
[格言 6] 把你的使用者視為協同發展人，可以讓你傷最少的腦筋，但做到原始碼的 快速改善，程式的除錯有績效。
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
[格言 7] 儘早，經常發表新版本，並且傾聽使用者的意見。
7. Release early. Release often. And listen to your customers.
[格言 8] 以足夠多的“beta 版”測試者和協同發展者做基礎，幾乎程式中的每一個問題都可以很快地找出來，並且對某些人而言，針對發現的問題的解決方法是顯而易見的。
8. Given a large enough beta-tester and co-developer base, almost everyproblem will be characterized quickly and the fix obvious to someone.
[格言 9] 聰明的資料結構配上笨拙的程式碼要比相反的組合好。
9. Smart data structures and dumb code works a lot better than the other way around.
[格言 10] 如果你視 beta 版測試者如同你最珍貴的資源，那麼他們會以此做為回報。
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
[格言 11] 體認你使用者提供的巧思，以獲取好點子，有時候越後到的越好。
11. The next best thing to having good ideas is recognizing good ideasfrom your users. Sometimes the latter is better.
[格言 12] 通常，最適切和最有創意的解題法來自發覺自己對問題原先的觀念是錯誤的。
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
[格言 13] 設計上完美，不是“沒有東西能再被加入”，而是 “沒有東西能再被移出”。
13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
[格言 14] 任何的工具以我們所知道的方法來使用都會有用，但一個真正了不起的工具會以你從未想過的使用方法來發揮它的功能。
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
[格言 15] 寫作任何的通信閘軟體時，要盡可能地不去擾動到通訊的資料流，-- 並且絕對不要丟掉其中任何的資訊，除非接收方強迫你這麼做。
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to!
[格言 16] 當你設計的語言不是嚴謹到“完全 Turing”，你可以採用比較平易的語法。
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
[格言 17] 一個保密系統是否安全依存於它隱藏的秘密，注意不要有“虛擬秘密”。
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
[譯注] 以 fetchmail 為例，隱藏的秘密是指“通行密碼”,“虛擬秘密”是指把通行密碼編碼後存於設定檔中。
[格言 18] 為了要解有趣的問題，開始找你感興趣的問題吧！
18. To solve an interesting problem, start by finding a problem that is interesting to you.
[格言 19] 假如專案發展協調者擁有至少跟網際網路一樣好的媒體，而他也不靠強制力來領導，那麼一群人必定勝過一個人。
19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
詳細的內容，請參考《教堂與市集》（The Cathedral and the Bazaar）
Tuesday, July 04, 2000
The Thread Class Library for Linux
在設計應用程式時，一些需要並行處理（concurrent processing）的功能，已經很少人使用中斷（interrupt）的方法解決，也不必再自行利用一個輪詢迴圈（Round-robin loop）來達到並行的效果──因為現在作業系統的設計，都已經支援執行緒（thread）了。一個程式可以透過許多執行緒達到並行處理的作用。
一個執行緒的產生，是在應用程式開始執行之後，而執行緒所能運用的系統資源是應用程式可用資源的子集；在應用程式結束前，執行緒就要被銷毀。因為執行緒是應用程式執行時的一個子功能，程式結束後，執行緒就沒有存在的必要。
Linux 作業系統核心提供了 clone() 這個 system call 來支援 thread 的功能。此外， Linux 的共用函式庫中，也利用了 clone() 來實作了 POSIX thread, PThread 標準的 C 語言 thread 應用程式介面。不過在現在到處充斥著物件的後 OO 時代裡，一個傳統 functional 的 C Language API 似乎顯得有些礙手。
這個類別庫（classes' library）主要目的是利用一個 C++ Thread Classes Library ，來提供一個容易使用的物件式介面（object interface），以方便日後在 Linux 系統下開發多執行緒的程式。
“一個具體的問題描述是與一千個尚未運用的抽象觀念等值的”，所以接下來，就先描述一下我們要的 Thread 是長成怎麼樣的： 
一個多執行緒類別庫要考量的功能最基本的當然就是要能做好執行緒的內部管理，舉凡執行緒的識別、出生、狀態、行為和死亡等都要照料妥當。
如果執行緒之間要作通訊（communication），當然也要提供一個通訊的管道（channel）;此外，還要考慮到執行緒共用資源時所可能引發的同步（synchronization）問題和避免因互相等待而產生的死鎖（dead-lock）問題。
為了方便多個執行緒的管理，還可以提供執行緒分組的功能，分成一個個的 Thread Group，以方便整組一起操作。
當然，在更完備的功能設計下，每個執行緒和執行緒群組還可以設定個別的執行優先權（priority）。並納入凍結（blocked）後的執行排班（scheduling）設計。
※完整的說明請參閱：
Monday, July 03, 2000
Ant Simulation
大學（1997）的程式設計課要求學生在網路上找一個 JAVA Applet 的程式，研究後寫一篇報告上來。我在網路上找到 Mark Miller 所撰寫的“Manna Mouse”JAVA Applet，檢閱了原始碼後，覺得它的程式架構太雜亂了。於是決定自己利用物件導向分析與設計的方法，將整個程式重新設計過。
如此，一方面可以加深自己對物件導向分析與設計方法的熟練程度；另一方面我對於這個Applet 所使用的遺傳演算法也有很大的興趣，想藉此有更深的探究…
Grady Booch 一向在物件導向（Object Oriented, OO）的方法論上執領導的地位，他在1986年率先提出OO開發方法，開啟物件導向分析與設計的研究。
Booch方法在進行分析時，不只是針對問題本身作分析，也針對問題的領域進行分析。因為在同一領域的問題，有很多非常類似。實在不需要對這些類似的問題，每次都一一地重新作類似的分析。
對於問題的整個領域作一徹底的分析，雖然在一開始的時候需要耗費相當的心力，可是隨著分析的進行，我們對於整個領域就會有更深入的瞭解，最後不但累積了領域相關的知識，也完成了富彈性、高度可重複使用的軟體元件，對於將來開發新的系統將帶來非常大的助益。
Booch 的開發方法非常強調領域內的可重用性（Reuseability），其將軟體開發分成以下三個階段：
- 需求分析（Requirement Analysis）
- 領域分析（Domain Analysis）
- 系統設計（System Design）
上面三個步驟並不是像傳統瀑布式的分析設計方法般僵硬地要求一定要一步步地執行；而是允許在步驟間回溯（backtrack），進行反覆地修改與調整，直到系統符合需求為止。
根據生物學的說法，曾經在地球上出現過或現存的所有生物都是由構造簡單的、原始的生物，經由長期的演化而逐漸產生的。
生物演化的理論，在早期可分成：相信後天獲得的性狀可遺傳給後代的拉馬克（Lamarck）學說，及相信後天性狀不可遺傳給後代的達爾文（Darwin）學說兩大派。
由於後來新證據不斷地出現，及這幾十年來分子生物學的快速發展，生物學上已經知道自然界生物的演化機制是採用達爾文式的。雖然有學者提出人類文化的演進可以看成是採用拉馬克式的演進方式，不過這不是這裡所要討論的重點。
達爾文的生物演化論可分成以下幾個步驟：
- 遺傳變異（genetic diversify）：個體間因遺傳基因型（genotype）的差異而顯現出各式多樣的表現型態（phenotype）。
- 自然選擇（natural selection）：自然界對於不能夠於所在環境中適應良好的個體發生淘汰的現象。
- 繁殖複製（reproduction）：未被淘汰的個體經由繁殖，產生許許多多的後代。這其實是一種選擇放大（selection amplify）的情形。
新產生的後代間又稍有不同而產生了遺傳變異，因此不斷地變異－選擇－複製，變異－選擇－複製，變異－選擇－複製......一直反覆循環下去即發生了生物的演化。
遺傳演算法在電腦科學上屬於演化式計算（Evolutionary Computation）的一環。遺傳演算法其實是以電腦來模擬生物演化的過程。通常用來解一些對問題解法沒有很充分瞭解的例子，或在用傳統的解法成本過高的時候使用。
※請進一步參閱《模擬螞蟻──以物件導向分析遺傳演算法》
Sunday, July 02, 2000
The Puzzle Game
大學時（1996）選修的“專家系統”課，任課老師要我們以 CLIPS 實作智慧拼盤程式。當初對這的專家系統的 CLIPS 感到滿新鮮的，所以就把這個問題的核心往自己身上攬，而將使用者介面讓其他組員去發揮。CLIPS 是 C Language Integrated Production System 的縮寫，由美國 NASA 太空中心的一個人工智慧部門所發展，就發展專家系統而言，是個很有用的工具。
“智慧拼盤”（puzzle），是一個ｎ×ｎ的格狀棋盤（grid board）遊戲。棋盤上的每一格都有一個正方形的積木（block），每個積木都有自己正確順序（order）的位置，為了區別，依序編上1到ｎ×ｎ的 編號。遊戲啟始時先將其中一格積木取走，造成的空缺（blank），使相鄰的積木可以移動至空缺上，並編上“0”。如此，利用這個空缺，可以將棋盤上原先 就定位的積木之順序打散（disorder）。玩遊戲的一方（player）所要完成的目標（goal）就是要將積木利用空格 （編號為0），排回（reorder）原先的位置。
這個題目的目的是要設計一個會玩智慧拼盤的專家系統，所以一開始由人將積木的順序 打散，再要求電腦將其排回正確的位置。為了達成更好的展示效果，於是選定了圖形化的使用者介面。又為了簡化問題，於是先從３個階層著手，也就是３×３的智 慧拼盤遊戲，作為測試規則的用途。不過，為了將來能夠將系統套用於任何階層，所以規則制定時都很一般化，原則上這些規則要能在任何階層的智慧拼盤下運轉， 至於能否在任何階層都求出解答，不是目前所要求的。
這個軟體的開發平台是在 MS-DOS 下的 CLIPS v6.0 上建立 puzzle 規則，並利用 MS Windows 3.1 下的 MS Visual Basic 設計使用者介面。
※請參閱《智慧拼盤》
Saturday, July 01, 2000
Graphing for the Pattern of Antenna Field
專四下學期至專五上學期延續一年（1994-1995）的專題課。我選了任教工程數學及電磁學的柯盟卿老師開授的“天線場型電腦繪圖”作為畢業專題。
原先的動機是想藉此磨練自己程式設計能力，又可藉由專題對電腦繪圖有一定的探究，再加上柯教授對於學生的要求：只要學生照規定行事、得到成果，其餘的細節絕不過問；當然啦！有任何疑問時，也可以隨時得到他耐心的解說。
當時我選擇了 Borland C++ v3.1 作為軟體開發的整合發展環境，並將內定的語法語意檢查功能全開，以期保障軟體最基本的強固性。此外，於程式撰寫的過程也力求完全利用 C++ 對物件導向程式設計的擴充功能，以達到最佳的學習效果。
這個專題最主要的內涵是要將天線電磁場強度的空間樣式（pattern）以電腦繪圖的型式呈現出來。
其用途除了可用作電磁學課堂上的教學展示外，還可以對於有心研發天線產品的人員建立方便的觀測模型，以減少反覆試作成品而造成不必要的浪費。
最基本的功能要能在給定了軟體關於天線的參數後，把天線四周的電磁波強度顯示出來。
經由分析，在工程實務上，只注重天線電磁場的場型（field pattern）。所以在圖形繪出前要先經過正規化（normalization）的處理。
又天線場型強度，其電場和磁場僅相差一個常數，故我們只選定了電場的部分著手。
最後，也決定了讓程式的執行平台最基本的要求在當時最普遍的 286AT 配合 DOS v3.3 的作業系統版本。不過為了繪圖的效果，程式被設計成必須在 640*480 VGA 模式下執行。
※請參閱《天線場型電腦繪圖》
Subscribe to:
Posts (Atom)
