觀察實驗資料和畫圖表的小技巧

之前在《減少操作實驗浪費的時間》提到一些做實驗的小技巧，方便自動化重覆實驗、觀察結果和產生圖表。最近實驗做得比以前更多，意外發覺更好用的方式 。有需求就會進步，這是工程師的宿命啊！

主要的改變有三點：

• 用 Python 寫程式執行實驗。Python 功能比 shell script 強上不少，也方便維護和增加功能。「Can I use Python as a bash replacement?」提到這樣做的好處和簡單的實施要點。什麼？你看了上篇文章發現我好像用 Ruby 較多？這．．．總之我跳槽了。男子漢做事，有時是不需要理由的！
• 改用 SQLite 當資料庫。使用 local database 至少有兩個好處：每次實驗都重建一個新資料庫，方便保留不同實驗結果；少掉煩人的設定，可以更彈性地使用。實驗後可以用 sqlite3 看內容，或另寫程式下 SQL 彙整結果。若有架 Wiki，直接將結果輸出成 Wiki code 也不壞，容易加上顏色、粗體和表格。
• 用 matplotlib 畫圖。matplotlib 是一套 Python 繪圖函式庫，能畫長方圖、折線圖、直方圖等多種類型圖片。更重要的是，它畫得還挺不賴的 (見官網範例)！既可以在 matplotlib 內建的應用程式裡看結果，也能存成 PNG 檔。依我個人過去用 gnuplot 的經驗，matplotlib 好用許多。不過這可能取決於使用者有多熟悉 Python。若你也喜歡用 Python，matplotlib 無疑是最好的選擇。「Tools I use: matplotlib」提出相似的見解，有興趣的人可以參考看看。

不論是 SQLite 還是 matplotlib 都有嚇死人詳細的文件，配合範例程式學起來挺輕鬆的。目前唯一的不便之處是，當實驗數據更多時，有時只想看部份東西，再一步步看不同層面。若一口氣把全部資料畫成圖表，不容易閱讀。有空時想來研究看看 Django (殺雞用牛刀嗎?)，看能不能寫個簡單網頁，做為互動呈現數據的介面。反正資料存在 SQLite 裡，容易用各種方式存取資料。

減少操作實驗浪費的時間

分享一下之前做實驗時發展出的小技巧，我這裡指的是跑程式的實驗。花點時間研究一些工具，可以剩下不少重覆執行的動作。

首先，畫圖方面 gnuplot 是最好的選擇，用法很簡單，google一下學個基本，之後要用什麼特殊指令，去 Demos and Screenshots 裡找符合的圖，將範例code抓下來試一試，改一改就會用了。看到常用的指令或參數，就到 Documents 的 Index 裡找詳細說明（比方查 xrange 的用法），減少試誤的時間。

gnuplot 最大的好處在於批次處理，初期費些工夫寫出滿意格式的 gnuplot code，接著就可以把所有圖表套用一樣的格式，想變更格式時，比方加格線或放大字型，只要改一份 code，所有圖表可以一同更新，這是 Excel 難以做到的，也許 VBScript可以，但學習代價應該會比 gnuplot 高。若會寫 shell script或scripting language如Perl、Python、Ruby、PHP，可以配合script和寫好的gnuplot code，執行一個程式讀入不同的資料檔，即可重畫所有圖表，這點 Excel 更不方便達成。配合 script 還可以自動轉成 LaTeX 用的圖檔格式。若不滿意 gnuplot 預設 EPS 的風格，像我較喜歡預設 PNG 的話，可以配合圖檔轉檔軟體，可以輕易地批次處理，像 Linux、FreeBSD上可以用 convert。做實驗時常要重畫圖表，很少能一次搞定，初期投資些時間在 gnuplot 和批次處理程式上，絕對會回本的。

若想再進一步自動化的話，可以將實驗結果存到資料庫裡，不要存到普通檔案裡。花點時間研究如何用 scripting language 或自己慣用的程式語言操作DBMS（如MySQL），看要在實驗結束時程式直接將結果寫入資料庫，或是先寫入暫存檔再另用別的語言 (例如直接用 MySQL script）將結果寫入資料庫。於是，透過 DBMS 網頁介面的軟體（如phpMyAdmin），可以輕易地觀察實驗結果，像是依時間排序資料、依數據大小排序，或要算平均、標準差等，都輕而易舉；要輸出成 gnuplot 或其它程式的輸入格式，也是非常容易。

最後，跑實驗的程式最好寫成從命令列讀參數，或讀一個設定檔設定參數，減少重新編譯的動作，也方便批次實驗不同參數。

總結一下，我自己的做法是：

1. 實驗用的程式從命令列讀參數。
2. 其中一個參數決定要將實驗結果直接輸出（STDOUT) 或寫入 MySQL。有時候做些小更動想看看實驗有什麼差別，不想塞太多資料進資料庫弄亂原有資料，可以下參數讓程式不要寫入資料庫。
3. 用 shell script 寫好測試用的批次檔，會輸入不同參數給實驗用的程式，產生所有要的結果。
4. 裝 phpMyAdmin，方便分析實驗情形，以及輸出 gnuplot 要求的輸入格式（用TAB分隔）。
5. 寫好 gnuplot 的 code，我不知道怎麼在 gnuplot 裡使用變數，讓它能配合shell script對畫圖作細部調整（如更改輸出檔檔名），所以我改用笨一點的做法，將gnuplot code存成字串，用Ruby配合不同變數產生有點不同的 gnuplot code 到文字檔裡，再執行 gnuplot 讀入新產生的 code 以符合細部調整。
6. 寫個簡單網頁顯示 gnuplot 輸出的 PNG 檔，方便用圖形觀察各組數據的差異。再寫個 script 利用 convert 把所有 PNG 檔轉成 EPS，確保論文裡的圖檔和我想要的樣子一致，但會犠牲向量圖檔任意放大的優點。

上述的方式我試過幾次，幫我省下不少時間，第一次試用時間投資就有回本，更不用說第二次之後的收益了。舉例來說，我其中一個實驗要求是記錄演算法各段落執行的時間，想配合各種不同資料量，判斷演算法的子項目平均時間差多少。但用 profiler 會拖慢執行速度，我只想記錄幾個主要步驟而已。這時輸入到 MySQL 變得相當順手，執行一次批次檔，上床睡覺，隔天早上下個 SQL 做平均，就可以看出差異。找出關鍵的部份後，再下 SQL 選出關鍵資料的細項，看看資料分佈的情況，有助於了解情況。想想看，若不用自動化實驗和資料庫來呈現數據，前述動作有多麼冗長無味，你會想重覆幾次這樣的事？更不用說集中精神分析結果和思考改進方式了。

知識管理：bbs, wiki, blog, bookmark (2)

上篇為《知識管理：bbs, wiki, blog, bookmark》，前陣子有學弟開始用Wiki，於是來分享近來的使用心得。

這篇重點在寫文章和工具的用法，一樣工具，隨著目的不同，用法會不同，寫文章(筆記)前要先決定讀者為何，這點明確定位後，工具用起來就會很順，反之，定位不清，寫起來只會綁手綁腳。

我目前的心得是bbs，wiki，blog，bookmark都會用到，我的心得不是工具的功能有多強，而是我對這些工具的定位更清楚了，下面描述的都是我的用法，不代表它們就是這麼用的。

使用工具前要先確保兩個重要功能：
1. 全文搜尋
2. 多重分類 (or tag)

再來的議題有：
1. 流通性 (傳播能力，有RSS者較佳)
2. 備份的便利度

比方Blog上述條件全符合，bbs完全不行，wiki的流通性不及Blog。

wiki是寫給自己看的，寫起來快速有組織即可，wiki適合條列編修，反覆修改，內文交互參照，很適合寫筆記和想法暫存，而且像DokuWiki有section editing和folding(plugin)，以及headline的sidebar，在wiki page成長後仍保有top-down的可讀性。

lab合作時有用wiki當公告欄放想法，個人想法暫記再從公告頁內開子頁面寫，避免大家頻繁改wiki時造成衝突，試用的結果挺微妙的，似乎有點亂，但滿有用的 ( wiki的特性是可以翻頁面修改記錄，可得知何時誰做了那些改變 )。

blog的流通性最高，用來寫給大家看，寫起來最累，因為對象廣，文章要有組織性，要有背景說明 / 出處參照 / 相關探討 / 文章分類，寫blog有助於組織想法，這種組織和wiki不同，wiki寫給自己看，加上便於修改，組織性比較隨性，blog則有一定受限，像我寫blog摸索一陣子後，就很少開新分類，開一個分類表示我有心在那分類產生後續文章，我在寫blog時的自我要求比較多，像是盡量避免笑臉符號，盡量用通順文章的格式，加強正式表達能力。

bbs則是介於blog和wiki之間的用途，由於看bbs的大多為已認識的朋友，要feedback比較快，而且寫起來比較快，不像寫blog會很在意文章架構，在意語句和段落間的連接性。

bookmark網站的用法還在摸索中，目前只是當URL暫記，說來諷刺，我的研究方向是針對bookmark，但用的頻率最少。

以上不管那一種用法，都有滿多實驗空間，像是讀書心得，在寫成blog前可以放在wiki上暫記，累積到一定的量再集合成文章，但不知怎麼，就是覺得寫在bbs上較順，順便期待在寫成blog前能不能先得到feedback。

另外我覺得開不同的wiki站感覺也不錯，我目前有三個wiki，lab的PmWiki記研究想法，個人的PmWiki暫存舊的，短期間的東西，不在意資訊的組織性，個人的DokuWiki記新的想法，逐漸將wiki架構弄得更明確，最近看《資訊架構學》和《隨意搜尋》有些心得，覺得wiki可以有更多可能，再摸索看看。

另外配合GMail的label + filter可以做到不錯的合作溝通媒介，人多時可以考慮用Google Newsgroup，大家再用GMail訂閱，依我目前的試用情形，三人使用mail溝通很有效率，確保大家都能即時看到資料，重點是要用label + filter將信件自動分類。

如果溝通時需要有行程表之類的長時間記錄，可以考慮用newsgroup或wiki記下來，我傾向用wiki記。

修課心得和對數位系統的心得

修課心得

po 這篇是給大學生參考，另外給自己重新體認學習的方法。我到大學快畢業時才發現自己一舉多得的做事習慣有意料之外的功效，像是把相似概念的課一起修，不僅是簡省時間，而且會加強概念的印證。

建議大家有機會的話，可以把類似概念的課一起修，或一年內連續修完，比方圖學和3D Game Programming、Compiler和Formal Language、OS和網路程式設計、AI + 演化計算 + Data Mining + 類神經網路。雖然會超累的，但效果絕對比分開修更好，可以從實務面和理論面互補不足，當然掛也是一起掛啦。另一修課重點是遊說強者一起修，每們課有個強者互相討論，各門課都會輕鬆一點，有室友一起修也很方便，就近討論效果很好。

數位系統的心得

（ 這篇心得寫於 2004/03/20 ，現在我完全不懂這些東西 ，用進廢退啊。 ）
在大二下時感受特別深，另外，最近終於弄清楚交大資工的定位，我想這有必要另開一篇文章寫出來，以供日後學弟妺們參考。以大二下必修課表來看 組語 / 數位系統導論 / 數位系統實驗 / 電子實驗 / 電子學 雖然有五門必修，是緊湊了些，但彼此配合得真的很好。

電子學講數位電路在物理上運作的原理，為什麼都用NAND？ 為什麼用CMOS實作gate？ 加上許騰尹老師在講時，會加重提到學這個和資工相關在那裡，學起來很實用。

承接大二上數位電路的課，電子實驗以市售IC在麵包板上直接接線，感受較真實實作的感覺，多少能體會實際用IC時和理論上操作的差異，比方寫布林代數時不會管用了幾個gate(比方not根本是隨便用)，也不需考慮線路要怎麼佈置才妥當，實際操作上完全不是這麼回事。

數位系統實驗從另一個角度切入，以模擬軟體操作來設計電路，較接近業界的作法，主題和電子實驗和上學期的數位電路呼應。

數位系統導論，再深一層地介紹數位電路的理論，比方簡單的CPU架構在hardware circuit以什麼形式表現，在寫組語時更有所體會。

組語裡有許多jump指令，需要自行check status flag來決定流程，而不是直觀的if - else (雖然MASM有提供.IF，.WHILE，不過是用巨集作的) 從數位系統導論裡可以了解，為什麼組語會這樣設計，這些指令的意義和低階hardware circuit吻合，從hardware circuit的觀點去看，可以理解組語的運作原理，比方不能”mov MEMORY MEMORY”的原因。

總之，從理論到實際操作，high level到low level，統統一把抓，交互印證，比起單修某幾門課，更是事半功倍。

還有後半學期的課還沒修到，相信陸續會有更多體會，不知道上述的心得，對於接觸過一點點數位邏輯的人，是否能夠理解呢？。

用bookmark網站快速截取主要概念

最近看到link讀一下後馬上收到del.icio.us裡，看一下大家用什麼tag，就知道這網站的keyword (or main idea)是什麼，再判斷是否有回頭看的必要，或收到del.icio.us，通常是直接點別人下好的tag收起來，省事 。

有些站intro寫得不清不楚，用del.icio.us來判斷真是超有效率的，不過也因用法過於隨便，目前還很少回頭看del.icio.us，反正就當備忘錄大全囉，重要的link再特別記到wiki or blog裡。

實例用法：TinyMCE

這站的介紹寫得滿清楚的，不用靠del.icio.us看也能明白，正好做方法的正向驗證，收進del.icio.us後，會看到tags:”javascript editor wysiwyg html ajax web webdev”，馬上明白這是用JavaScript寫的WYSIYWG editor，像html、web就是上層概念了。

Drupal TinyMCE的部份，tags:” drupal wysiwyg module tinymce editor cms web”，就多了Drupal這套件名的概念，對於看不懂的TAG，可以再看看http://del.icio.us/popular/TAG收了那些網站，或查它的定義，獲得新資訊。