[隨筆] 研究的實驗結果這回事

最近看了許多跟系統架構相關的文章，讓我想到剛升碩一時不知天高地厚的跑去修了虛擬機器這門課，然後因為各種聽不懂大受打擊的事情 XD 當時這門課的期末專題是要想辦法找出 QEMU 中可以改善的地方，然後做實驗說明改善的結果跟幅度，現在想想當初能順利做完這個專題還拿到高分實在是運氣破表 XD

[筆記] 最佳化演算法 (Optimization Algorithm) 的使用與誤用

(這篇的數學式有用到 javascript 來顯示，請不要檔掉 JS，不然顯示上會很奇怪 XD)

最佳化演算法簡單來說就是個搜尋演算法，這類演算法的再做的事情是給定一個問題，定義合法的解集合 (或是空間，英文是 solution space)，再給一個函數用以判別一個解的好壞 (objective function)，這類最佳化演算法就會在解集合中找出符合要求的一個解。

有點難懂？舉個例子：假設我想要再一個 2D 的平面座標中找到一個點使得 $f(x, y) = (x - 5)^2 + (y + 3)^2$ 得值最小，求 (x, y) 為？在這個例子中，solution space 就是 2D 平面上所有可能的點座標，而 objective function 就是 $f(x, y) = (x - 5)^2 + (y + 3)^2$。而最佳化演算法就是針對 "任何" 這樣的問題，找出一個盡可能滿足 objective function 也合法的解給你。沒錯，就是任何這類需要在一個 solution space 中找解的問題都行。所以這類演算法很萬用，但也因此容易被誤用。

[EDA] Steiner Tree v.s. Spanning Tree

一般演算法講到 greedy method 時都會用 spanning tree (生成樹) 當範例，因為 spanning tree 有 O(n log n) 的 greedy method 可以找到最佳解。相對於 spanning tree，某些情況人們會更偏好 Steiner tree (中文好像是翻成史坦納樹)，兩者雖然都是要找一個方法把給定的點連成一顆樹，並且一般都會要求 cost 要最低，但是一個很大的差別在於 steiner tree 允許連線時增加多餘的點，但 spanning tree 不行。有多餘的點可連差異會很大嗎？我想可以參考 wikipedia 這篇的圖例就會知道這差異有多大。簡單的一個結論是 minimum steiner tree 的 cost 是小於、最多等於 minimum spanning tree。

[隨筆] 簡潔而精準 與 冗長但易懂 都幾?

在 FB 上看到朱家安 (哲學哲學雞蛋糕的作者，最近有上去臺灣吧介紹哲學的那位) 的這篇詢問文時，想到了剛開始寫論文的一些事情，當時也被老闆告誡過跟這篇文章想問的事情有關的原則。

我相信其實不只哲學論文，一般學界的論文都會為了要求精準而簡潔而使用了大量的符號去避免冗餘的文字還有錯誤的解讀，因為自然語言很常出現同樣的一個句子可以有 2 種以上的解讀方式。像那篇文章中的 A1、B1 就用了一些代號去代表一個特定的事件、情境等等的現像。相較於 A2、B2 來說，因為可以大量減少文字中所需要的代名詞，而且因為符號所代表的事情是固定的，因此可以減少讀者在解讀上的困擾。比方說，如果文章的某個段落提到 "該事件"、"此方法" ... 等等之類的用詞時，讀者通常必須要能緊緊的跟住文章的脈絡才能正確的理解這些名詞在指涉哪些內容；相對的，姪皆使用代號的話就沒有這個問題，比方說我上面的 A1、A2 只要有看到原文的都會知道我在指甚麼。

當然，依照情境優點也是會變成缺點的：當今天代號過多時，一般人會難以將大量的代號與其所代表的意義迅速的連結，因此下場就會變成讀者會需要常常翻閱每個代號的意義，反而增添閱讀上的困擾與意願。我想應該沒有人喜歡閱讀文章時還需要常常往回翻每個代號的用意吧？就我自己的想法，適量的使用代號有助於理解文章的內容，當然何謂適量就是另一個問題了。我的看法是當作者自己本身都必須往回翻翻看有多少代號然後哪些是甚麼含義時就是個警訊了。另一個可以著力的點是使用代號時也盡量都使用默認常用的符號，別自創新符號。

備註：

有看到推文有人提到數學式子，但我覺得數學式子跟代號又有一點微妙的不同，因為複雜的數學式子會有理解困難的問題，但代號應該沒有複雜的代號這回事 XD

[閒聊] 人際關係

最近因為發生了點事情，所以比較常跟人聊到人際關係這回事，一個可以簡單可以複雜的問題

[隨筆] 性格

最近覺得要想了解一個人，除了從平時的互動可以略知一二外，最好的方法其實是觀察他的負面情緒

 一個人在身處負面情緒的狀況下因為多少失去理性了 (當然，憂鬱症這種已經屬於精神疾病的不在這邊的討論範圍，我沒那麼厲害)，此時展現出來的就有很高的機率是他的原始面貌。比方說，容易有肢體衝突、容易有語言上的暴力、酸言酸語、孤僻、高傲、自尊心強烈 ... 等等，在人身處負面情緒時很容易展露無疑。當然，也有些人即便身處負面情緒下還是有著關懷、體貼、包容 ... 等等的正面情緒，所以觀察一個人身處負面情緒時會有何反應大概就可以簡單的窺探一個人的本性。

不過，我果然還是不習慣跟刺蝟類型的人相處太深入，因為當這類人身處負面情緒時，張開的刺保護了自己，卻也阻隔了所有試圖 - 不論是好意或惡意 - 靠近的人，而且往往越接近的人被傷的反而是最深的。或許是我自己的偏執，往往很希望可以在別人低潮時試圖陪伴，因為我覺得這或許可以給別人一種安心感，現在覺得這種自做多情的事情還是別幹了，往往自己被弄得滿身傷還不被諒解。

[EDA] Design Challenge in Rouoting Algorithm - 繞線演算法的設計困難處

在 IC 設計中，Routing (中譯：繞線) 的用意就是把需要連接的地方用金屬線連起來，概念很簡單。要判別一個 routing 結果的好與壞也很容易：計算總線長就好。因為總線長越長也就意謂著需要越多的金屬線以及空間，所以如果有許多種不同的 routing 結果，我們會選擇總線長最少的那個當成最後結果。

隨著製程的演進，現在 routing 要考慮的因素越來越多，因此在演算法的設計上也就越趨複雜，而且通常難以有個通盤考量的好結果。這一篇要來簡單的總結現在 routing 上最重要的設計考量 - 繞線資源的規劃與使用 (routing resource estimation & management, 以下簡寫 RREM)

[隨筆] 程式能力該如何檢定?

最近這幾年推廣寫程式的風潮越演越烈，比方說科技界的大老的推廣、人人都該寫程式、甚至也有教授開始推廣國中小的學生開始學習寫程式。究竟為什麼推廣寫程式，我想已經有很多文章在闡述這點了，今天想談的是從這點往下延伸的問題：

究竟如何判斷一個人的程式能力?

[閒聊] 我都可以，你們決定吧 -- 群體沉默的開場白

我相信大家應該有這種經驗：

那些時間 / 地點 / 方法 (... 請自行帶入其他可能的名詞) 我都可以，給你們決定

然後每個人都這麼說完一輪後，如果又是在聊天是用打字的對談，接下來肯定會有很長一段時間沒有任何人發言，看最後是誰耐不住尷尬、或是受不了一直沒結論，願意跳出來隨便提一個方案。

[C++] Recursion Using Lambda Expression

C++ 的 lambda expression 搭配 std::function 就可以做到 recursion 的功能