十點到老師研究室外,怪了?不是約好十點要做paper review嗎?可能是塞車吧!一直到十點半老師的研究師燈才是亮的,敲門進去後老師要我請鄭老師,於是又跑到鄭老師的研究室敲門,鄭老師習慣是不關門的,但還是敲一下門,結果鄭老師既然講出一句:糟糕~你寄的paper我還沒看,我以為是明天meeting。那一定是糟糕的,依據上次的經驗,我肯定要大改造等篇paper了,等鄭老師到了之後開始review,但是鄭老師根本沒看過,所以變成我替老師做summary,等我一講完,我最不想聽到的東西出現了,鄭老師覺得我的Introduction不足以讓看paper的人知道問題和貢獻,要我修改整個Introduction,另外我的例子太長了(這是鄭老師第二次看這個例子Orz),希望我再修短一點,這真的讓我回想起之前有篇漫畫,修來修去,說不定又會變回我最一開始寫的版本,開玩笑的。

  之後鄭老師聊到他自己的經驗,他這個學期初也投了三篇paper,但三篇都被reject了,和演算法或是其他領域的paper不同,軟體的paper特別難上,因為只要是軟體總是會有人喜歡有人不喜歡,不像是演算法,你可以直接證明他是O(n2)或是O(nlnn)的複雜度,或是你可以真的把電路layout出來,然後證明他的效率耗電比是很高的,但軟體沒有公式或是辦法去證明好或壞,就如有人喜歡Linux討厭Windows,同樣也有人討厭Linux喜歡Windows,這種對軟體的喜好都會直接影響軟體paper通過與否,所以鄭老師建議我,要像M$一樣,把Introduction寫的像廣告一樣,讓審paper的人看一眼就知道你要解決的東西是甚麼?如果他不喜歡,直接reject,喜歡的話直接accept,不要讓審paper的人覺得:好像有價值,但又不曉得價值在哪裡?(我常常看到這種paper啊~還是說現在評審的口味改變了),然後因為不確定價值在哪裡,既不reject也不accept,一拖就是一年兩年,太浪費時間了。況且被reject也不是壞事,可以拿去投別的期刊。

  Review結束後和老師討論了一下研究室設備的問題,然後就回到自己的研究室,開始改paper,一直改到晚上才算有一個自己覺得漂亮的版本,加上鄭老師認為好的Introduction要讓非相關領域的人看得懂(奇怪我看過很多即使是同領域的我依然看不懂的Introduction...),所以特地把Introduction的部分轉成PDF檔分別給韋宏和弈君看,看來這次改成成果還不錯,扣除韋宏因為自身奇怪翻譯導致的誤解外,大多知道我在寫什麼,這才把修改後的版本寄給兩位老師,呼~還有例子要改,真是的,十頁的例子也花得不少時間寫的,如果當初覺得太長,真的應該早告訴我幾頁比較適合,多寫那麼多頁也是很累的...
arrow
arrow
    全站熱搜

    dbi1463 發表在 痞客邦 留言(0) 人氣()