2008年9月30日 星期二

碩士研究生涯回顧 (3)

續前回,仗著大學時抵掉四門選修,碩一上我只選了一門課。多出來的時間...又被雜事耗掉了。

當時 Web 2.0 風潮正在快速成長,引起我的興趣,開始試著自己架 wiki 管理知識、架 Blog 寫文章、從 delicious 中找不同的知識。當時覺得 web mining 很有趣,資料容易取得(就 crawl 嘛),又貼近生活,若研究有所發現,樂趣更多。當時已有一大票人發表 Blog 相關 paper,但不知為何,bookmark 相關的 paper 到不多,而我覺得 bookmark 的知識價值很高,於是就選定 delicious 做為奮鬥目標,試著從中找點子。於是碩一上就這麼結束了。

那麼這個只修一門課的學期,我到底在做啥?

當 OpenHouse 資訊組組長(這網址每年都會變,舊的大概都不會留)、當 DS 助教、帶專題生、在教研所打工、看閒書、思考人生以及寫 Blog,這段時間也是我學生時期事最雜(一堆會和待做小事,還特地找了記事工具)、閒書看最多和Blog 寫最多的時期。這段生活很有意思,不過研究產能只算過得去吧。寒假時先參加一個有趣的英文營隊,兩週就沒了。看看小說,接 case 學 Rails,花一週 Ruby 特訓,就碩一下了。

唔...名為研究生涯回顧,結果這個時期都在做管理和 coding。

2008年9月28日 星期日

碩士研究生涯回顧 (2)

續前回,從兩年前的暑假(2006/07)開始,我的研究方向轉為交通相關的 data mining / data management。想想,我覺得解決塞車問題似乎最有趣也最實用,老師也對這很有興趣,之前有專題生做過簡化版問題,於是就朝此方向前進。

CS 領域內,解決塞車的 paper 到沒很多,不過在 Operation Research 和一些不清楚分類的領域裡,有不少相關作品。塞車相關的研究滿有趣的,像有一篇討論塞車有多糟,或從另一角度來看,我們能解決塞車到什麼程度。印象中這篇 paper 估計,最糟的情況下,無管制的行車時間會是有管制的兩倍慢。另外也有看到其它領域如何解決塞車,像倫敦用塞車稅(congestion road tax)的作法很有意思。我個人是認為經濟學(?)的作法比較實際,以價治量是合理且有效的作法。不過反正問題還沒徹底解決,也可以想想自己的做法。

理想的作法是大家都聽政府或某有公信力的單位指示開車,假設 server (central or distributed) 算得夠快,理論上塞車量會降到最低。於是我將問題切成如下三個部份,準備各個擊破:

1. 若我們有部份車子的車速和位置,如何將這些資料轉為表示即時車速的 graph?
2. 若有表示即時車速的 graph,當我們告知駕駛人如何前進時,如何即時更新 graph,以避免大家走同一條,造成一段時間後的新塞車點?
3. 若有表示即時車速的 graph,也知道如何依駕駛人選的路徑來更新它,要如何在極短時間內算出大量不同需求的最短路徑?

當一切規劃差不多後,我發現這問題很難,三個月顯然作不完,但這題目還沒有趣到讓我想和它奮鬥兩年,於是又找老師商量,可不可以換題目啊...。幸好開明的老師又讓我換方向,但要求我帶新的專題生接手做下去,這是個有趣的插曲,待日後分享心得。

隨著我再度更改研究方向,第一個暑假也差不多結束了,即將邁入正式的碩一。這個暑假到沒做太多研究,被一些「外務」耗掉時間,例如:

  • 花了整整一週寫 Wow! Dice War!!
  • 看完十季的 Friends。一開始還有一邊切換無字幕、英文字幕、中 + 英字幕,後來乾脆都用中文字幕了。
  • 摸索 Web 2.0 相關東西,像 Blog、Wiki、Online Bookmark 等,這大概是和研究唯一有關的外務,後來我轉往這方向找研究點子。

另外還有協助將 lab 學長的論文投出去。我滿喜歡這篇的,完整版的內容比較多,可說是讓有的點都做到了,學長想出兩個新方法,一個可快速找到近似解,另一個可找到最佳解,且效率大勝暴力法。實驗結果說明前者的效率大勝後者,且和後者最佳解的誤差極小。後來論文投上了 DASFAA 2007,老師原本希望我去報告,可藉機認識學術研討會,也許可激發我做研究的熱情。不過我覺得自己不是第一作者,熱情不足,若研討會上有人提出討論,我大概也會興致缺缺,這樣似乎不太好。結果最後老師自己衝去,兩三天內來回的樣子,辛苦老師啦。

2008年9月22日 星期一

碩士研究生涯回顧 (1)

大四上申請上研究所後,花了許多心力找老師,當時我不確定自己對什麼最有興趣,最後挑和 AI 稍微相關的 data mining 做為研究方向,結果發展到後來,沒用到太多 AI 的東西,挺多看別人論文時可以嘴炮一下自己懂的 AI 知識(比方說 Simulated annealing、A*之類的)。

無視於大學時期 20% 達成率的偉大計畫,升上碩士前,我又給自己定了一個偉大目標:在碩士結束後,要投上三篇好的 Conference,並且至少要有一篇是 ACM 的。雖說做研究不是為了投論文,研究成果也不是要就會順利出來,當時想說,這樣至少畢業時能投上一篇吧?多少能逼自己更用心地體會學術生活,以便日後決定是否要讀博班。結果在老師的協助上,算有三篇第一作者的論文,不過都只是過得去的成果而已,只有一篇和 ACM 差到邊,和以往的計畫一樣,沒 100% 達成,但也差強人意地可接受啦。

這兩年多內,研究方向轉換超大,大致上的轉換流程如下:

  1. sensor network related problems
  2. social network / graph mining
  3. solve the traffic congestion
  4. social bookmark related problems: focus on tags
  5. social bookmark related problems: focus on bookmarks (URLs)
  6. joint clustering with the connected constraint
  7. social bookmark related problems: focus on users

回顧起來,真是亂七八糟啊...

一開始是大四寒假前夕時,指導老師要我看看 sensor network 裡的 multi-path 問題,類似 network routing 問題,印象中目的是在 sensor network 內傳輸資料,並要省 energy、減少 latency,而且不要過渡消耗特定的 sensors,並免沒電就不通了。但我對網路相關的研究興致不大,也不太能接受 sensor network 的研究方式(或說是前提假設),在和老師反映後,老師建議改看看 social network 或是 graph mining。結果看了一篇 graph mining 的 survey paper,和翻了一些書後,感覺太抽象太難懂,當時又對 social network 有些反感,所以也提不起勁做研究。加上大四下修課花不少時間,就這樣不知不覺地進入升碩一的暑假,並且題目換成交通相關的研究。

老師看我一直換題目,開始擔心我會不會耐不住性子做完一個題目,希望我這回試久一點。想想也對,這次我就試比較久,待下回再來細細分曉。

2008年9月15日 星期一

終於畢業了

隨著碩士生涯的結束,我短暫的學術生活也到一段落。

我一直覺得碩士是很難得的機會,一生一次,長時間投入自己感興趣的事,不用在意是否能成為產品、使用者是否覺得好用,只要自己覺得這解這問題有意義,就已足夠。大學生課業繁重;博士生畢業門檻高,做起論文難免會有得失心,相對來說,碩士簡單多了,可以丟掉學界的包袱,放手一摶。當然這一切的前提都是要找到一個肯讓學生放手試的指導老師啦。我當初找老師時就以此點為第一考量,結果也還不錯。回顧做研究的過程,當真是九彎十八拐,之後再來一一回顧這兩年的心得(連關西行在內,欠一堆稿了...)。

碩士時的生活作息也很難忘,由於我沒什麼課,有課大概也沒去上,我大多是在家做正事一兩小時,休息一兩小時,有時則連續做個三五小時不等,週一到週日維持差不多的生活型態,我滿享受這種生活週期,把做正事和休閒的時間切成許多小循環。可惜上班後就難以維持了(除非能在家工作)。對我來說,一天八小時實在是沒效率的做法,依過去經驗,一天只能全神慣注地做六小時,一天四小時比較不會累,剩下的時間只能做些簡單的事。

除生活作息外,和朋友間的互動也很有趣,可惜的是,當初想多了解各實驗室的研究領域,結果沒能達成。一但專心切入自己的題目,訂好一些時程後,就會開始沒止盡的衝刺,而沒心思顧及其它不相干的研究。

2008年8月31日 星期日

近兩個月使用 Python 心得 + 從 Ruby 對照的心得

最近兩個月都在寫 Python,反而 Ruby 快忘光了...

由於先前有 Ruby 的底子,轉學 Python 的進入門檻低了許多,一年前我和 Scott 聊過,我提些 Ruby 功能,Scott 就提 Python 要怎麼寫;或是反過來進行。當時就覺得這兩個語言的功能很像。經過兩個月的練習,現在我反而比較熟 Python,真是諷刺啊。

個人覺得 Python 和 Ruby 的主要不同是哲學層次的,Ruby 講求人性,給予使用者 (programmer) 極大的彈性;Python 則是有個明確的規則在,講求一致性。「Form is liberating」,我並不討厭 Python 的做法。舉例來說,Ruby 會提供許多別名方法 (alias method),讓使用者可以憑直覺用對功能,比方加一個元素到陣列裡,在 Ruby 裡有以下的寫法:

a = [] a.push 3 a.push(3) a << 3

但在 Python 裡,就只有 a.append(3) 一種。並且,Ruby 讓使用者可以在任何時刻改變任意物件的內容。所以 Ruby 的使用者不用擔心拿不到 third party library 的 source code,反正有啥難處理的地方,在 runtime 直接修改即可。方便歸方便,在大型專案裡意味著寫完函式庫後,作者無法保證使用該函式庫的人會讓函式庫元件照規矩運作,這使得程式碼協同運作充滿危機。

相較於 Ruby 強調直覺帶來的便利,Python 則是制定好最佳規則,照規則辦事。以 exception 來說,Python 遵從有意外就用 exception 的規則,除以零是 exception,dictionary (即 hash table)取用不存在的 key 也是 exception,取用不存在的變數也是 exception。反觀 Ruby,以人性的角度出發,這三者狀況的反應分別為:exception、nil (Ruby 的 null)、exception。從這可看出 Ruby 對 hash table 取用不存在的 key 的行為不一致,但這麼做確實比較方便,省去先查 key 是否存在再取值的動作。另外以查 method 為例,Ruby 的查法很直接(直覺):

[].methods.grep /push/

[].methods 就會顯示 [] 所有方法; methods.grep 就會對 methods 做字串比對。反觀 Python 則是透過 __dict__ 的機制達成:

[s for s in dir([]) if "p" in s] # dir() 會傳回 [].__dict__ 和 [] 父類別的 __dict__

Python 另對 __dict__ 有許多有趣的設計,像是 hasattr(),還有讓 __dict__ 替 function 帶來許多好處 (如 cache,可做到類似 C 裡 function 的 static variable 的效果),這部份太細了,不在此談論。

另一方面,兩者都強調 Everything is object,但對 object 的定義不同,Python 對 object 的定義可參見:《Python Types and Objects》:The Object Within。Ruby 的 OO 很強,Python 沒有 private/protected/package-private/public 這類流行的 OO scope 字眼,反而用變數命名前加底線,暗示使用者有底線開頭的物件是 private/protected,但使用者仍能直接存取。對我來說,我認為 private/protected/package-private/public 實在太難設了,若非經驗豐富的程式設計師,很難訂對,所以不訂也還過得去,省下煩惱 scope 的時間。

除 Unicode 支援良好外,Python 另一令我激賞的特性是 self-document。Python 規定 module、class、function 的文件必須寫在 module 的開頭、class 的下一行、function 的下一行。造成的結果是,許多工具如 ipython 能輕易地將程式碼內的文件顯示出來。只有有些寫程式和文件經驗的人就能明白,將文件和程式分開寫是多麻煩的事,通常下場是文件漏寫,或是文件過期。所以文件和程式愈能合為一體,愈有助於程式碼品質 (code quality)。

其它如 thread 的差異,和 C/C++ 結合的容易度,我還沒碰到無法比較,到是 interpreter 部份值得一提。個人認為好的入門書、好的文件和 interpreter 可大幅減低入門門檻,是否有好書取決於作者功力,這部份兩邊都有不錯的書;文件部份如前所述,Python 的設計相當棒,;而 interpreter 部份,ipython 實在太強了,像 Scott 是直接在 ipython 上寫,再存成 script 檔。經過這兩個月的洗禮,我決定先投向 Python 陣營,只好忍痛割捨 Ruby 寫碼的爽快感。

2008年7月29日 星期二

右腳只是輔助的 (2)

距受傷的日子正好四週整。

上週末照慣例又去讓中醫師複檢,這回可以動的幅度又進步了。回家後開始練習走路,雖然走久了會痛,但腳踝能動的幅度一天比一天多,真難想像兩週前會痛到無法站,一起床腳踝又會因為血往傷口流而超痛。現在雖然右腳走起來相當地不靈敏,至少可以一拐一拐地走了,只不過走路速度比用拐杖還慢...。週圍的人看到我能走後,都用神奇的眼光看著我,這...只是普通的走路,我本來就可以走的啊!

2008年7月15日 星期二

Python class mthod

Python 原本沒有 class method,只有 instance method,這在一些情況下不方便,比方 factory method。後來 Python 的改版做了修正,詳細的說明見 static methods,以及後來的改良語法 decorators,兩篇文章的說明淺顯易懂,我就不在這轉述了。感謝 Aethanyc 介紹。

decorator 不只可改善 classmethod 語法,還可以協助當 function wrapper,用來做 log、檢查參數。官網的例子很讚,值得一看,這裡摘錄一段 singleton 的做法:

def singleton(cls): instances = {} def getinstance(): if cls not in instances: instances[cls] = cls() return instances[cls] return getinstance @singleton class MyClass: ...

有興趣的話可以對照 Ruby 版的 cache,Python 應該也能寫出類似的東西。我很喜歡這種由外包裝的寫法,寫起來很乾淨,完全不會影響到原 function 以及 call function 的 code。