今天聽到了某件消息, 感覺像是背後被捅一刀一樣, 我心底覺得很生氣. 雖然我很知道對方心底的感受是因害怕而過度表現, 我不願意對她發怒, 但是基本上我個人的情緒感覺是生氣的.

論文排版, 只是一組syntax的規定, 照理說應該是context-free的! 但我真沒想到, 在由Word重度使用者組成的環境下, 已經不容許其他軟體的存在. 結果, 本來context-free的排版規格, 被附加了太多與Word操作與結果外觀相關的規定, 甚至是延伸規定. 不僅如此, 還因為我沒辦法做出跟Word排版結果一模一樣的東西, 就不想處理我的審查案件. 為什麼要這樣子? 這幾天我很努力, 而且努力的份量比使用Word排版的人用得更多! 這些努力妳完全不看, 就只看文件是不是夠Word嗎?

標楷體為什麼會是一個強的規定, 強到不容許其他的楷體存在? 甚至, 竟然強到即使我早已去申請字體相容授權了, 審核者仍執著於字體外觀稍有不同而造成的影響!

我實在不後悔使用L^AT_EX, 並且對這個軟體充滿了感恩之意. 由於這份感謝, 這一週我拼上所有的精神努力把Word佔據之下的格式規格以L^AT_EX實現.

使我不滿的是, 論文格式審查是查看我的文件是否符合規定的語法, 而不是檢查我的文件看起來是否與Word排版出來的文件相似! 我只想要符合格式! 我不想要符合Word! 拜託, 在大學就算不會Word也沒什麼關係.

編排論文排版的過程中, 上網查詢L^AT_EX命令同時看到了其他學校的論文規格, 他們幾乎都有對Word與L^AT_EX提供開放的論文格式. 但是, 我們學校學院沒有! 太蹧踏人了不是嗎? 只要不用Word做東西的都不是人了.

規定是死的, 而我希望以活的方式遵守規定. 然而, 上方的審查者, 卻可能因為死的規定而更死守規定與傳統, 將我的文件逐一與他人的Word文件比對. 這究竟有什麼意義? 對不打算遵從Word的人, 妳以Word限制我, 有什麼價值?

最近在檢查論文格式, 我用L^AT_EX排版, 最後卻遇到最嚴重難以處理的問題: 標楷體.

因為仔細看, cwtex的楷體跟標楷體實在差了一點點. 標點符號也長得單薄了一點.

解決辦法很麻煩. 好像沒時間了. 哎!

我想, 至今我也只是有一些過去證明自己能寫程式而已吧!

最近有個面試. 雖然我已經確定不必再參與面試了, 但約定的公司還剩一個, 我就想, 去看看吧! 那家公司是做手機應用程式的. 面試官要我準備一些履歷, 以及一份C++程式, 能夠當場講解.

要準備什麼程式呢? 一開始我是想大一所寫過的貪食蛇應該夠看了吧! 後來, 左想又右想, 覺得不對勁, 貪食蛇實在太簡單而且沒有什麼技巧了. 接著, 我想到同樣在大一時寫了非遞迴的 Hanoi 塔問題. 我使用的方法, 不是傳聞中的模擬 stack, 而是某種 pattern matching:

1(3)2 <- 1(2)3 -> 2(1)3

1(2)3 表示把一堆圓盤從左邊 1 柱移到右邊 3 柱, 中間是會借用到的 2 柱; 在 1(2)3 之前會有個動作 1(3)2, 之後會有個動作 2(1)3. 將所有搬移情況組合成規則表, 我的程式是產生一串容納解答的陣列, 第一次先在中間填入第一個答案, 於是第二個答案可以填入前半的中間, 第三個答案可以填入後半的中間.

在這個程式中不能使用樹資料結構, 否則一走訪就跟遞迴解一模一樣. 為了避開樹走訪的遞迴, 我當然使用迴圈, 第一次先把全列分成二部份, 在中間位置填入第一個答案. 第二次, 把全列分成四部份, 三個分界點有二個可以填第二個答案與第三個答案. 第三次是分成八部份, 七個分界點有四個要填入新答案... 整個程式寫得相當長.

在復習這個想法時, 發現我當時似乎只想找出小範圍內可接受的解; 然而, 現在我一開始就想解 64 個圓盤, 必須有 2^64-1 長度的陣列. 就用整數陣列好了, 圓盤數為 28 時產生了 1.5GB 左右的陣列, 而 32 個以上的圓盤數字使程式一開始執行就直接判斷無法執行而中斷.

看到這一篇blog: http://blog.pixnet.net/piratechu/post/1891437 (程式人員的面試心得及基本原則), 感想怎能不多? 以往 "有程式就好" 和 "有結果就好" 的程式思維一點都不夠看. 許多時候, 程式跑得不快, 寫得不好看而且寫得很慢, 我想我真不會寫程式.

經過編碼之後, 應該不會在Google排名很前面.

前幾天寫過一次感言, 那個感言是正面的. 不過, 在最後幾天, 倒是有些負面的感想.

基本上, 最後我是覺得有些失落與失望, 因為隨著課程的進展, 我發現真來不及消化吸收. (好比乳糖不適症?) 於是, 當我一直知道這些東西應該很重要, 必須多花時間努力學, 同時卻發現自己的體力甚至於腦力根本跟不上的時候... 我生氣了. 然後, 就沒有心力想把一個考試做完.

雖然說不喜歡考試, 但是, 換做是平常的場合, 對這些知識不能熟悉地談論其中的要項與性質, 我想這是很嚴重也很麻煩的情況. 接下來幾個月或一年, 都要繼續把 semantics 看完. 這次 denotational semantics 的課程是我的極弱項.

到最後仍然精神力不足... 我已經到了極限了.

精力容易耗盡的人, 生活得非常辛苦.

今天FLOLAC最後一堂Program Construction課程, 提到maximum segment sum, 導出來的程式真簡單.

話說, 上週的上週, 我去一家公司面試, 面試考題有maximum segment sum呢! 不知道答案是不是那麼簡單? 不過, 我想, 他們的題目除了要找到最大的區段總和, 還要知道有最大總和的區段是哪一段. 若也要紀錄區段的頭尾, 似乎要有一些 if-else 才行.

過幾天有空再想想.

很可惜當時沒辦法推導給面試官看.

緊張緊張緊張, FLOLAC 的課程只剩下四天了, 也就是說, 我們還剩四天要喘息... 四天的作業... 噢! 但我覺得作業少太多了. 比較沒逼迫了. 這次課程是比較好一點的地獄.

晚近的邏輯研究群似乎使 λ 這個符號帶有比其他希臘文符號有較多的語意了. 這是我的感覺.

有點像畢達哥拉斯的結社, 某種圖樣變成標記圖章.

這麼說來, 喜歡做邏輯研究的人, 基本上是喜歡看一些看起來漂亮的東西, eye sugar 的偏好者, 嗎?

這一篇應該歸類為「社會觀察」.

FLOLAC 第一週, 時間飛也似地過去; 不像去年那樣子度日如年. 這次我真的不緊張, 體力也不繼, 所以瞌睡非常多. 哎... 不過這次開頭的基礎課程, 有一大部份是差不多都知道的, 邏輯, 函數語言和型態系統差不多都熟, 就敢放手同時做點其他的事情.

不過, 陳恭老師, 莊老師, 以及穆老師和 Schaefer 老師, 我在分心以及體力喪失 (譬如按照荷馬的伊里亞德詩中所提, 被銅槍鐵槍刺透的戰士總是 "被黑暗矇上了眼睛"; 那些戰士雙眼如何被黑暗矇上, 我在課堂中也是如此...) 其中感受到, 老師們的態度是除了辛苦準備課程之外, 還有許多的客氣與謙和. 所以我在這方面覺得很抱歉. 在這方面我必須努力改改生活型態.

雖然這麼說, 我卻上課也昏, 回家也昏, 或許到了某種界限? 身為人真辛苦, 想要顧及靈性的事情的時候, 同時還要顧慮血肉的事情.

沒錯! 最感到可惜的是, 在重要的 denotational semantics 部份, 我也昏了, 沒有仔細聽完. 好慘喔! 新知識的部份才是該專心的. 只好自己在家補課了!

另外, 這次很幸運得到了新訊息, 可以考慮是否加入微程式科技公司的研究群. 我想我的意願非常高. 謝謝Luke!

昨天聽Josh一番講話, 感受到那份熱血了. 不過, 沒想倒是幽默感十足的人, 讓我一直呈現 XD 狀態.

我的心境實在還跟不上他呢! 我需要自己調整一番.

在做第二 functional programming 作業. 今天雖然上課在打瞌睡, 但我仍在半醒情況把課聽完. 不曉得有沒有漏掉什麼.

前一天不該為第一次作業把精力耗盡的...

目前正在看第二次作業的第三題, function composition 部份. 我的感覺是, 裡頭大有玄機, 玩弄 Haskell 的技巧玩的很大, 題目八成出自穆老師之手. 但我相信陳恭老師自己研究所開的課程也有這麼強的訓練. 後來一算, 是自己想難了. 答案還蠻簡單的.

經過反覆折疊自己曾經學過領略過的事物, 想到一個最基本的方法. 蠻令我自己驚訝的, 原本以為會是更複雜的作法.

使用到 Accumulating parameters 主要用意是對付 functional programming 實作上的難題: 如果在 stack 累積了一大堆未消化的東西, 該怎麼辦? 所以大概就是要簡單吧! 不能給自己找麻煩, 不能用了 accumulating 之後, 還是要慢慢算才能算完.

我的答案是:

1. 從 fib 0 開始往高位數字算. (明確地說, 應該是從 fib 1 或 fib 2 開始往後算) 因為從 fib 0 與 fib 1 才能夠把明確的值 accumulate. 若是由 fib n 往前算, fib n 拆解成 fib (n-2) 與 fib (n-1), 根本找不到明確可 accumulate 的值. (或許也可以把所有的 fib x 收集在一個 List 最後再一次解開, 但太麻煩了.)

2. 根據講義提到 accumulating parameters, 我用了二個 accumulators.

檢查自己的答案, 我想, 或許我對於遞迴的想法有一些執著於 imperative programming 的遞迴該是甚麼樣子的, (特別是與 iteration 有區別) 所以在寫這個題目時, 有一點不想把程式寫成目前我這個答案的心態. 我下意識覺得它是錯的. 不過, functional programming 的遞迴應該是另一種 paradigm.