閒談中研院的研究助理

算來在中研院資訊所也當了三年助理

來提一下這邊的見聞


去年上任的所長說過
希望助理們不要待太久
這句話反映了助理的生態
一般說來
資訊所的助理的程度
最好的人才頂多只待一年, 是用來當申請國外學校的跳板
次好的人才待五六年, 是用來順便唸國內博士班
其餘的人待的年數不定, 理由不一, 可能是因為工作輕鬆, 或是國防役和替代役而有合約

在這種情況下, 難怪研究員會感嘆找不到最好的人才來當助理

不過這也有機可循
我認為是人才供需造成
今天一個電腦科學的學生 有很多去外面公司上班的機會
以薪水來看
中研院提供碩士四萬左右的薪水 加上1.5個月的年終
而且還沒有升遷的機會 (怎麼幹都還是助理)
吸引力相對低

同樣的薪水 對於生科方面的學生吸引力大很多
因為他們在外面沒這麼多機會
這也是為什麼我常聽到生科那邊的朋友靠么說那邊的研究員比較機車
吃定你沒別處去啊

找出文章中的所有引用

最近在用 Word 寫計畫報告，我在引用參考資料時，是使用 [xx] 這種格式。[xx] 是個交互參照，用來連到文章的引用列表。到目前為止一切順利，不過後來發現引用列表中有不少項目是沒有被引用到的，為了節省空間要，要找出沒有被引用的的項目把他們刪除。
但是自己用眼睛看過30頁的文章實在太累，所以寫了一個 Python script 來幫我找出有用到的參考並加以排序。程式如下:

import re

refdict = {}
fin = open('doc.txt')
for line in fin:
    refs = re.findall('\[\d+\]', line)
    for ref in refs:
        num = int(ref[1:-1])
        refdict[num] = 1

used_ref = refdict.keys()
used_ref.sort()
print used_ref

Python 下用來處理 bibtex 的函式庫 -- pybtex

最近在寫報告的時候，需要和同事整合各自的參考 bibliography)，我本身是採用 JabRef 來做書目管理， JabRef 使用的格式為 bibtex。為了檢查大家的參考書目書目有沒有重複，尋找了一下python 的函式庫，找到以下兩套:


1. python-bibtex
2. pybtex

python-bibtex 是書目管理工具，類似 JabRef，不過需要在 Linux 環境才能運作，所以就放棄了。
pybtex 是用來取代 latex 中的 bibtex 軟體，基本上功能和 bibtex 相同。好消息是 pybtex 有提供方便的函式可以直接剖析 bib 檔，用法大致如下:

from pybtex.database.input import bibtex
parser = bibtex.Parser(encoding="UTF-8")
bib_data = parser.parse_file('foo.bib')
print bib_data.entries.keys()
for k in bib_data.entries.keys():
    print bib_data.entries[k].fields['title']

有了 bibtex 這個工具之後，剩下來就只是比較 title 等簡單的工作了。

語音合成 (一)

上個月的時候，朋友E先生發想做中文的語音合成。
經過搜尋，我們發現目前以工研院的引擎的效果最好 (這邊有線上demo)

不過還是感覺不夠完美，同時也沒有可以調整的參數，
我們的理想是能做出語調和感情的調整。

動手之前我們先做了一番研究，一份較易懂的參考資料如[1]
語音合成牽涉的範圍很廣，大致可以分成兩個部分:
1. 自然語言處理 (Natural Language Processing): 讀取文字，分析出每個字的唸法
2. 數位訊號處理 (Digital Signal Processing): 把獨立的字的發音組合成一個句子

我們決定從第二部分下手，
因為第一部分可以先由人來給訂，而且也無關乎發音是否悅耳

而數位訊號處理技術很多，大致上可以分為兩派
第一派被稱之為 synthesis-by-rule，主要由語音學家發展出來。
第二派被稱之為 synthesis-by-concatenation，和前者的差異為，只採用少量的語言學知識，將語音視為聲音的片段，利用技巧來把片段整合起來。
由於不是語音學的專家，我們決定從第二種方法開始。

首先要有語音資料，目前找到能使用的是 gcin 的語音檔 (ogg格式)
http://ftp.twaren.net/local-distfiles/gcin/ogg.tgz


這個檔案包含約一千個字的發音，對應到國語的所有單字 (包含五種聲調)

原本每一個發音檔是放在各自的目錄下，同時目錄的名稱是中文，所以並不好處理，我先用Python script把檔案轉換成漢語拼音，放在同一個目錄下面。

接著為了由於ogg格式比較少有函式庫可以處理，為了方便起見，我先用 Wav2Mp3 這個軟體把 ogg 轉成 wav 格式。

[1] Thierry DUTOIT, "High-quality text-to-speech synthesis: an overview"

(未完待續)

產品評論 -- 增加硬碟擴充能力

由於硬碟的價格不斷下降
現在一台電腦中多放幾顆硬碟的情況已經很常見了
不過由於電腦機殼設計的歷史因素
擴充槽有兩種規格
大的是5.25吋, 主要供光碟機和早期硬碟機使用
小的是3.5吋, 主要供硬碟機和軟碟機使用

到了現在
由於5.25吋硬碟機已經絕跡
大的擴充槽只有放光碟機的作用
即使一部電腦只需要一台光碟機
主機機殼還是會配置兩個或更多的大擴充槽


為了增加3.5吋的硬碟數目
有種簡單的產品可以將3.5吋的硬碟放入5.25吋的盒子中
便可以固定在大擴充槽中

這時 EVERCOOL 這家公司想到
兩個大擴充槽的空間其實是可以放入三個3.5吋硬碟的
所以他們推出 armor cooling box 這個產品
真是很聰明的設計

可惜這個產品主要用在早期的機殼上
現在的機格大多有四到七個小擴充槽
放硬碟已經足夠
由此看來這個產品出現的時間點太晚了 不會賣的好

Blocks -- 電腦視覺研究上的MATLAB framework

前陣子在讀ICCV的paper時，有兩位作者引起我很大的興趣，原因不在於論文的好壞，而是他們把自己做實驗時的研究方法公開在網頁上。

為什麼說這是一件重要的事情呢? 這要先岔題一下:
在電腦視覺的領域，一篇好的研究，除了理論完整、實驗漂亮之外，能否讓其他人重複得到該作者的實驗結果也是非常重要的。

目前在這個領域，已經有公用的測試資料庫供大家使用。想像一下，說假設我提出一套方法，可以找出照片中的行人，要評估我的方法好壞，可以用一組前人已經做過實驗的照片，用他們的結果來比較。而這樣的比較結果，自然是放在我的論文之中。不過問題來了，當有人質疑我的實驗結果時，他們必須用想辦法重現我的實驗結果，不過這是一件很困難的事情。
困難的理由在於，首先你要把我的方法寫成程式，這是一件很花功夫的事，然而當你寫好程式之後還有一個難關，在電腦視覺這個領域中 (電腦科學的很多領域也是)，
一個演算法之中會有很多參數，而參數的設定不同就會造成實驗結果的差異
類比一下，好比說我給你一份食譜，裡面說要加牛肉幾兩、油、鹽、糖幾匙等等
如果我今天漏掉了其中一樣東西的分量，那你就只能自己嘗試，找出最好的分量，
不然味道就會差一點
令人驚訝的是，論文中就是會把很多參數給漏掉
這其實也不能責怪作者，當你的系統大到一個程度時，你自然不可能巨細靡遺的把每個參數寫在論文上面，尤其是當這些參數是跟你的演算法無關的部分。

面對這種情況，
許多論文作者並不會主動提供這些資訊，比如說放在個人網頁上面等等
有時候當你寫信去問時，得到的回覆可能是"抱歉，我的程式不知道放在哪個硬碟了"
這通常不是作者敷衍你，而是一個常見的情形，因為研究題目可能兩三年就會有變動，之前寫的程式往往不能再用(啊哈!你想到軟體的重複利用，但是研究人員不一定具有好的軟體工程能力)

比較好心的作者會把他的程式碼公開，讓其他的研究者可以輕鬆的重複實驗，
這樣子通常可以獲得回報:會提高其他研究者引用他的論文的意願，
而論文的被引用次數，是一個研究者最直接也是最重要的指標(甚至比發表的論文數目還重要)

回到一開始，Brian Fulkerson 和 Andrea Vedaldi 這兩位研究員，他們不只公開程式碼，同時也整理了整個實驗的架構，告訴你可以修改那些地方，讓你能在他們的基礎上來改進這個系統。這才真正的站在巨人的肩膀上! (當然這是指在學術界啦，在業界的話這可是公司賴以生存的寶物，怎能輕易公開!)

(未完待續)

失落的勾勾 ✓

前幾天老闆在用word的時候問了我 ☑ 這個符號怎麼輸入
本來用word的插入符號就可以搞定，沒想到找了半天居然找不到
敝人想了一下居然不曉得符號的名稱，以致於無法向 Google 大神求救

我先從方框裡面的勾勾✓下手
經過一陣搜尋，原來✓這個符號稱之為tick (此為英式英文，美式英文稱之為 check mark)
好在維基小神有保庇，把✓連他的同伴☑一起建了一條說明
看過條文發覺居然沒有中文的對應頁面，所以仍是不知該如何稱呼

回到原來的問題中，在符號表中找不到☑乃是因為使用的字形對Unicode的支援並不完整
因此自然不見☑的蹤影
把字型改為 Arial Unicode MS 後便出現了 ( Arial Unicode MS 支援 Unicode 2.1 版)

不過目前的 Unicode 已到 5.2 版，一共含有約10萬個字!
看來字形檔要支援最新的 Unicode 仍屬不易啊