novus log

雖然說自己有笨到，不過還是很幹的事件.....
事情是這樣子的，前陣子我把舊顯卡給其他需要的人，然後趁機會換了張新顯卡。
我是用慣雙顯示器的人，很幸運擁有一個操了N年還不壞、只是顏色差了點的17吋舊液晶螢幕，這個顯示器只有 VGA 輸入。另外我還有一個較新的顯示器，是 VGA + DVI-D。
我的舊顯卡用的是雙 DVI-I 輸出，轉成 VGA 並沒有什麼問題，可以經鬆愉快地使用雙顯示器。而新的顯卡有 VGA、DVI-D、HDMI 三種輸出，由於比較新的那個螢幕也有 DVI-D，想當然耳接雙顯示器也沒什麼問題。
但是原本應該非常簡單的事情卻出現了波折。顯卡到貨並裝好之後，我翻遍手邊所有線材才發現我根本沒有 DVI-D 線，應該是當初買螢幕時就沒有附。這也不是什麼大不了的事，到附近的3C連鎖賣場買一下就好了。
賣場裡的DVI傳輸線接頭有塑膠蓋，而且盤繞的方式讓人看不清實際的 pin 腳，外包裝明確有「DVI-D」、「DVI Digital Video Cable」、「DVI公-DVI公」、「Support all high resolution DVI monitors.」等等字樣。由於是急需而且也沒別的商品可選擇，所以我就很天真的相信包裝上的字樣了。
可是代誌不是憨人想的那麼簡單，回到家打開包裝一看 pin 腳，赫然發現橫槓的四周有四根針--這不是真‧DVI-D，而且很不巧我的螢幕和顯卡都不吃這四根針。這種小事當然難不倒我，立刻老虎鉗伺候。除去那四根針之後顯卡端終於可以順利接上，但我之前一直沒發現顯示器端很嚴格地只吃 DVI-D 的短槓，就算拔掉那四根針還是不能用。這表示我剛才完全耍笨做了白工，腦中不禁浮現出武林名言:欲練神功，必先自宮；就算自宮，未必成功。
總之，我手邊的顯卡、顯示器、傳輸線這三個自稱 DVI-D 的產品竟然有三種不同的腳位，其中只有顯示器才是嚴格的 DVI-D，傳輸線根本是拿 DVI-I 來混充。
不得已只好到更遠的一家3C連鎖賣場，這才找到真正的 DVI-D 線，雖然只有 Single link 不過也可以接受，最後終於又可以用雙顯示器了。回家途中忽然想到，早知道一開始直接買 HDMI 轉 DVI-D 傳輸線會比較省事啊。這個故事告訴我們，如果要買DVI傳輸線，請務必確認針腳配置再買。

有人轉這個給我看
http://www.youtube.com/watch?v=q33ZpVvX-nk
江博士被主持人形容成「對上帝粒子非常有研究」。呃...有沒有人能提供一下，他參與過哪些相關國際研究計畫，或者是發表過哪些相關的學術論文呢？
我對台灣的電視節目真是越來越無言了，沒想到中天竟然還非常沒創意的照搬友台的節目形式。
希望以後不要每一台都這樣玩，要求上節目的來賓說學逗唱樣樣來，不然 Peace 大以後大概也不願進攝影棚了吧.....XD

這裡介紹一種方法，可從連續出現的數字序列，回推線性同餘函數的相關參數。先聲明一下，密碼學、亂數、數論並不是我的專長，只是最近看到有人問，碰巧我讀過而已，如果內容有錯漏歡迎指正。這裡介紹的只是通俗易記的做法，可能不是目前最好的方法。
線性同餘法是目前常見的偽亂數產生法之一，可以寫成：
x[n] = (a * x[n-1] + c) mod m
其中 a、c、m 為根據某些原則小心選定的常數，這裡不多介紹。假如我們取

記得這是某位朋友在一年多以前遇到的問題。當時他需要分析程式中各個 branch 和 statement 的執行統計資料，那時候我跟他建議 gcov，但沒多久他就跟我抱怨說 gcov 在 Mac OS X 上無法使用。因為這不是我關心的問題，而且我手邊沒有任何 Mac 系列的開發環境，所以就沒有繼續深究。
今天我們又談到同樣的話題，強者我友早就解決這個問題，他眼也不眨一下就直接在編譯器內部增加一個 compile pass，使編譯器自動在被編譯程式的每個 basic block 植入計數程式碼，最後再寫個分析程式處理統計資料。這差不多是 gcov 的工作方式，只是自己做的比 gcov 更直接符合需求。
接下來要講的是，我終於知道為何在 Mac OS X 上使用 gcov 會有問題。原因在於 Mac OS X 預設的 gcc/g++ 指令並非執行真正的 gcc/g++，而是 alias 成 llvm-gcc。因為 LLVM 並沒有提供相關的 code instrumentation 服務，所以不會吐出 gcov 可用的資訊，改用正牌的 gcc 或者 clang 應該就沒有問題了。以上資訊提供給有同樣需求的網友參考，不過我不是 Mac 使用者，所以有問題別找我。
所以我朋友真正需要做的只是安裝正港GCC，然後就可以正常使用 gcov 了。不過自己改寫編譯器或許可以獲得更多的控制能力，也不見得是多此一舉。

新聞連結：http://www.appledaily.com.tw/appledaily/article/headline/20120603/34273637
反對活動臉書（含市府簡報內容）：http://www.facebook.com/psnlit
新聞摘要：

最近一直沒時間寫新文章，所以貼篇舊聞。
Donald E. Knuth 是在大學時期打工才接觸到電腦，那個時候他剛好也在學校籃球隊幫忙。他紀錄了每位球員在不同位置的表現，並且在 IBM 650 主機上設計程式進行統計分析，以這些資料作為球員調度的依據。原本 Case Institute of Technology 在上年度只有贏得 6/16 場球賽，使用 Knuth 的方法後至少已經贏得 11/14 場球賽，後來成為聯賽冠軍。

可能有不少人在書上讀過這段故事，不過我最近看到這段影片，終於發現他們籃球隊以往戰績不佳的可能原因之一，如果只看書本文字介紹就無法發現這點。

很多人在比較商品時會使用「性價比」這樣一個概念，通常是將商品規格量化後再除以價錢得到的指標，有些時候會反過來算。我知道現實中大家講性價比全憑直覺，沒有人會真正去除，這只是一篇說明數學原理的文章，只要掌握數學原則就能推廣到其他最佳化領域。雖然說是數學，不過你可以放心裡面完全沒有計算，而且應該在高中程度以內。
有人使用「C/P值」來表示性價比，但這似乎不是一個很正式的用法，C 和 P 各自代表什麼大家也說不清楚。其中一個可能是 cost/performance，但若是這樣 C/P 值應該越低越好，顯然和口語上的用法相反。另一個候選者是 capacity/price，看起來符合一般人的使用習慣，而且字首都對得上，但似乎只有中文世界是這樣用的。還有人主張這應該是 CPI（Cost Performance Index） 的誤用，不過我覺得有點懷疑。
不論如何，我以下採用的都是「性能/價格」這個普遍的用法。性價比被詬病的原因之一，在於大部分商品的性能本來就非常難量化，本文打算忽視現實的使用情境，專注於「F(價格, 性能) = 性能/價格」這個函數的數學特性，所以先假設所有商品都能夠完美無爭議的量化。本文另一項不符現實之處在於假設產品性能與價格都是連續分佈，現實中的產品幾乎都是離散的。
如果假設商品性能範圍為 2~10，售價範圍為 2~10，性能/價格畫出來的圖形如下。

自從我更新 Palemoon 12 之後就沒辦法使用 Hotmail，但停用所有 Plugin 之後恢復正常。
經過進一步測試，問題似乎出在 Foxit Reader Plugin 上面，停用 Foxit 就沒問題了。
如果網友同時裝 Firefox/Palemoon 12 與 Foxit Reader，遇到 Hotmail 無法運作的情形，可以嘗試停用 Foxit plugin。

這個實驗在電腦裡躺了一段時間了，雖然不是很有價值的實驗，但想說既然做了不如就整理一下放上來吧。
大約兩個月前在 xkcd 上看到有位仁兄挑戰既有的資料結構常識：「假使只查詢而不需要更新資料，使用排序陣列搭配二分搜尋，效能通常會勝過複雜精巧的二元搜尋樹」。這位仁兄很意外的發現，用 std::lower_bound 對排序過的 vector 做二分搜尋比 map 還慢。他提供的程式很快被網友點出兩個錯誤：

算是回答一個網友的問題。（真希望回答問題有錢可拿.....）
在沒有標準程式庫的情況下，計算 sin、cos 這些函數值最直覺的方法可能是用級數逼近。但假如我們只想求有限範圍內離散數字的三角函數值，級數逼近就顯得有點複雜了。
舉例來說，假如你在設計火砲射控系統，那麼處理的單位應該會是密位（mil），北約制的密位定義為1圓周 = 6400密位。