2011年3月25日 星期五

甚麼天氣的圖阿?

我也知道圖在 What's the Weather Web 神貘天氣是很重要的, 所以要畫圖也要有圖解阿, 只是說實在的, 深入淺出是我最不善長的一環阿, 本想請人幫忙寫的, 但還是自己跳出來寫好了...

上圖是取自於 3/23 在 Weather Channel 對 台北 的天氣預報, 而 Weather Channel 是在當天就不會再預報一次的天氣, 而是在 9 天前就開始預報天氣, 所以在 X 軸雖只看到 -8, -6, -4, -2, 但事實上前後還有個 -9 與 -1, 指的是在 3/23 的幾天前的預報...

很明鮮的在 3/23 的前 9 天也是 3/14 對 3/23 預報是 13~15 度, 依序下去每天都有對 3/23 有預報, 所以紅色是預報的最高溫, 藍色是預報的最低溫.

綠色是在 3/23 我們實際測得的溫度是 13~15 度, 而整體而言都算很準吧, 因此我們要看誤差的話, 應該是看紅色線跟綠色上端的面積和與藍色線與綠色下端的面積合, 而在這個圖就是很明顯的高於綠色到紅色的面積與低於綠色到藍色的面積就是誤差.


而這張圖是當天中央氣象局的預測, 而中央氣象局是在 7 天前才開始發布那天的預測, 而到當天也會持續發布當天的預測, 而這邊來看, 藍色線都比綠色還要高或一樣, 所以低溫的誤差是藍色到綠色底的面積總合, 而高溫的誤差有一天是較低的, 但在面積來看還是可以把三塊面積加總, 但所謂三塊面積加總事實上也是每一天的最高溫預測與實際最高溫的差總合, 當這兩個總合加起來就是總誤差, 若跟上圖來看可以看得出來誤差相當的大.

因為每一個單位預報的週期都不太一樣, 因此我們會依天數做平均, 只是這個平均不是都維持每天不變, 而是依天數的差距乘上等比級數 0.9, 這個也是說, 越早預測的比重也越低, 也是說若我們認為預測明天的天氣是 90% 的話, 昨天預測明天天氣則是 81%, 前天則是 73%, 依續下去, 而明天當天的預測比重則是 100%, 因為若是當天預測當天還有誤差, 這當然是最糟糕的囉.

2011年3月22日 星期二

神貘天氣哇 What's the Weather Web 公測


在 3/21 大概完成了一個初步的心願, 這是從莫拉克之後, 雖說一直想去中央氣象局看能不能做點甚麼貢獻, 但說真的, 我須要學習的東西還很多, 因此只好先自己做吧.

資料探 勘的假借法? (Data Mining)文章說到, 有時我們無法取得第一手資料, 但我們可以嘗試用有系統, 可以自動化, 較為客觀的第二手資料做 "加工", 獲得要的答案, 就像是我們無法取得台北市交通狀況, 但從網路上公車的行車記錄幾乎就可以算得出來台北交通狀況, 用這個當 KPI 是再真確不過了.

因此若要了解天氣預測的準確與否, 最簡單的就是比較預測與真實的關係, 所以這計劃就產生了前題, 而接下來就是從這二手資料中, 是否可以純用數學模型算出一個比這些天氣預測系統取得更準確的 KPI 呢?

花了 10 天, 終於把這個 Weather DataMining 做個了斷, 嗯, 是基本的雛型, 也就是先定義出預測準確率的 KPI, 這公式很單純就是:

1. 從今天, 昨天, 前天一直到有預測今天氣候的資料做記錄, 跟實際今天的溫度做比對, 最簡單的就是取面積 (積分這差距).

2. 距離越遠的日子, 準確率應該也越低, 所以採取個等比比重做為調整, 且每一個單位並不是擁有相同的預測天數, 所以也要 Normalization (正規化), 目前每早一天, 就比前一天少 10%.

3. 最近這三天的預測應該是要最準確的, 所以我們特別做了個加權, 因為也不是每一個單位都有針對 "今天" 做預測.

最後就以上述的公式定義出溫度預測準確度的 KPI 了.

Weather DataMining 氣象探勘這篇文章提到, 是否預測穩定度跟準確率相關, 所以我們接下來定義穩定度是甚麼? 穩定代表一定有變化的差距, 目前有幾種可能定義:

1. 當天跟(前一天以前的平均)差距.

2. 當天跟前一天的差距.

3. 當天與前一天的差距以及更之前差距的等比累積再正規化.

而會先試算看看才知道那個較為準確, 說不定實務上又會做綜合指標, 而若能找出穩定度, 又能找出穩定度與準確率的關係, 此時新的預測模型就會出來了.

這個網站最早是我跟紅色死神開始規劃的, 因此想說以我們兩個人的名字命名, 本來最初是想說來個 "紅黑大對抗", 或者是 "SunDog/紅獸" 這樣的想法, 但在偶然之間取最後兩個字, 跟 "什麼" 有相當的諧因, 所以就變成 "神貘天氣", 而最後是想說加個驚歎語, 而原本是叫 "阿", 後來改 "呀", 最後為了配合跟 "WWW" 致敬, 所以就變成 "哇" 了, 因此目前公測的名稱是 "What's the Weather Web (WWW)".

有不少朋友說願意一起來幫忙, 包含如何 Deploy 到 ipad/iphone, 現在已經有個雛型了, 所以準備開始好好的玩了, 我最近就會敲大家了.

(圖例就是網站的圖, 可以看出從當天以前之前每天對溫度預測的變化, 若是當天已經是發生了, 就會有綠色範圍指示真實溫度, 因此可以輕易看出準確率, 而網站網址為 http://weather.datamining.tw 神貘天氣哇)

2011年3月19日 星期六

從歷史圖型來看數字預測

在系統調校的一開始, 我一定會問大家一個問題: "系統負荷 60% 是過高還是過低呢? 系統負荷 6% 是過高還是過低呢?" 當然這個 "過高過低" 指的是一種不正常的現像, 而在之前要有一個前提: "何謂不正常?", 所以就要知道這系統的歷史記錄, 一台機器平常都是 80% 在跑, 現在只有 60% 負荷, 表示有甚麼工作沒在動了, 而若是平常一台機器負荷還不到 1%, 現在跑到 6%, 一定發生甚麼問題.

因此, 歷史資料對於我們的判斷是相當重要的, 尤其在很多可以量化的時間序列來看, 要搜集與儲存這些資料是相當重要的, 但接下來的就是要去判斷, 因為這判斷未來所須要的資訊就是來自於過去, 加上自己的想像與經驗(模型), 這在資料探勘中, 就是屬於資料搜集, 資料清理對接下來的資料探勘的重要性.

但在之前, 到底怎樣的判斷 (探勘) 是對或錯呢? 我常常說, 資料探勘所知道的可能是大家早就已經知道的東西, 只是要在短時間內從這麼大量的資訊做出大量的決策是人做不到的, 即使這事可能是由人來做是最好的, 所以電腦只是來輔助人的判斷, 而在真的去 "處理/探勘" 之前, 最直接的方法就是: "Data Presentation/資料呈現".

說到這些數字與資料的呈現, 最常用的是表格與圖型, 但說到要能夠直覺的一目了然, 還是要從圖型來看, 因此我常會要求用 MRTG 或 RRDTools 來做出一個基本的圖, 因為這是輔助判斷的最好方式.


我常會說, 人眼與心智是最好的判斷系統, 就像上一張圖, 這是一個歷史資料圖, 若我們知道當上面的線圖接近到 100 時系統就會有問題, 那看了這張圖, 你認為合理的狀況這三五天內會不會出問題呢? 若是用電腦的模型來看至少有兩種方式:

1. 迴歸: 就上圖一算, 數字的變化是往下降的, 說不定過不久是 0. (黃色線)
2. 平均: 目前剛好是平均, 所以應該沒甚麼大變化. (藍色線)

但我們人眼一看就知道, 趨勢不是紅線就是淺藍的線, 不應該是黃色或藍色, 若是淺藍的話, 大約 5 天就會出問題, 若是要樂觀一點來看, 紅色會出問題的日期還要 10 幾天, 所以還有更多的時間, 但出問題是必然, 只是若用上面兩個常用的模型來預測, 往往會失準, 但相較之下畫出圖後用人來看反倒是最準的.

在上一篇的 "氣象資料探勘" 的文章中, 收集資料後, 當然就是要做進一步的分析與預測, 但新的模型與方法找出來至少要一段時間, 因此在之前想要讓大家知道誰預測比較準確, 最簡單的方式就是畫出圖來, 這就是明天各家氣象預測的歷史軌跡圖:



這張圖可以看得出來除了 The Weather Channel 在高溫在今天有下修外 (大概是昨天上修太多了) , 大家都是維持往上修正, 所以當大家看到各家的天氣預測, 應該心裏有個底, 就這個趨勢來看溫度不太會比預期得還要低才對, 當然這也是除了預測外, 若能知道 "預測的歷史趨勢變化" , 在對於這種有 "時間性" 的預測往往會有更準確的感覺, 這也是有趣的地方.

當然這只是一個示範, 而這計劃目前暫時定名 "神貘天氣呀", 這說是 "甚麼天氣呀" 更應該是說我跟 "紅色死神" 一個小小合作發想的作品, 除了希望做出更個人化, 更人性的預測外, 也打算做 iphone/ipad 的 app 來讓大家玩, 所以有甚麼建議請大家多跟我或死神說.

2011年3月9日 星期三

Weather DataMining 氣象探勘


在渾沌理論出來之前, 即使已經過了所謂科學終結的時代, 那時社會的氛圍還是在想說只要有足夠的資料, 就可以 "模擬(Simulation)" 出氣候給予預測了, 但是一隻蝴蝶(誤)把這想法給粉碎了, 但不代表說模擬計算不重要, 只是沒那麼 "絕對" 罷了, 因此在我小時候, 台灣最快的電腦不是在國家高速網路中心, 而是在氣象局.

無論是 Simulation 或 Emulation, 我們知道在計算在氣象可用的模型是相當多的, 甚至有很多歷史資訊可以參考, 但套句 Data Mining Forecast 兩大定律: 天底下無新鮮事, 天底下沒有相同的事, 再怎麼計算也只是種猜測與推估, 只是眾多可能性之一, 但到底除了這個之外, 還有沒有其他候選答案, 也就是 Minority Report, 這個可能在現實上要大眾了解是須要再教育的, 只是預測的單位不只一個, 無論是中央氣象局, 中央氣象台, 還有國外許許多多的單位都在做預測.

當然這些都是不同的看法與觀點, 甚至因為適用性不同, 預報方式也有不同的角度, 但到底那個是最準確的呢? 基本上有了 iPad 後, 我就很習慣的多看幾家, 除了 Weather Chanel 外, Accure Weather 也是不錯的參考, 只是最後就實務上檢驗那個是最準的呢? 看樣子並沒有這樣的資訊, 因此我就想若是氣象預測的準確率是可以成為 KPI 的話, 到底誰能夠拔得頭幬呢?

事實上說要知道誰最準 , 就實際面應該是我們也是想要從中知道最準的答案吧, 甚至若是不準的話, 會往那邊偏差呢? 若心裏有個底的話, 也是相當不錯吧, 因此這個 Weather DataMining 的小計劃就慢慢在腦子形成了.

在還沒有公布答案之前, 事實上所有單位都會對某天做很多次的預測, 從兩週前, 到一週內, 到三天內或是在明天, 每次的預測都不盡相同, 當然我們知道時間距離越遠, 變因越多, 誤差會更高, 但若能夠掌握好的模型與變因, 理論上很快就可以在幾天前就收斂, 但實務上是即使說要預測 2 小時後的天氣都很困難了, 更何況是在兩天前, 我想除了 Nami 娜美外應該沒有多少人有這能力.

有了準確率的 KPI, 更可以用收斂穩定度做另一種輔助參考, 理論上預測穩定度跟準確率有相對的關係, 因為若是用最 "真確" 的方法去預測, 穩定度是 100%, 當然準確率也是 100%, 但這是不太可能的, 因此在沒有準確率公布答案之前, 是否可以用穩定度來做考前猜題, 倒也不失個好方法.

這計劃最主要是要滿足我對數字與預測的惡趣味外, 也希望用這個小計劃好好的自己踢一下, 不然我之前所提的計劃都太大了, 當然也真的做出自己以及大家想用的東西, 有意義的東西, 放在 ipad 用自己希望的 UI 來看, 而最後也是要慢慢朝向我莫拉克後, 想說對台灣氣象有些幫助的自我期許.

有誰還有對這計劃有興趣嗎? 來找我報名吧!

資料探勘的假借法? (Data Mining)

前幾天有一個很重要的事, 就是 M$ 自己做了一個 IE6 Countdoown 的網站, 希望在 2014 年能夠讓 IE6 從地球上消失, 但我這篇不是在寫 IE6, 雖然我是網站開發者, 只是我只處理到資料庫端而已, 所以我並沒有那麼痛恨 IE6, 所以當看完這網站我並沒有很大的想法.

但仔細看了一下這網站的數字, 這網站的資料是取自網路界鼎鼎有名的 Net Applications .com, 很多網路分析資料的數字都是取自於這間公司, 所以也沒甚麼好意外的, 而在一個噗浪的討論串中, 有人說了一句話: 亞洲好像是最慘的, 仔細一看, 亞洲說不定占了整個 IE6 的三分之二, 當然其中有一半要歸功於中國大陸.

討論到這邊, 台灣的狀況也沒好到那邊, 最後大家七嘴八舌的說台灣真正的問題不在民間, 而是在公家機關, 此時就講到這些政府單位的固步自封, 食古不化, 甚至到貪污腐敗的程度, 所以認真看了一下:

中國 34.5%
南韓 24.8%
印度 12.3%
台灣 10.7%
日本 10.3%
越南 10.0%
香港 7.6%
若不說這是 IE6 的占有率, 而是說公家機關的 "官僚度", 甚至說是 "資訊暢通率" 說不定有許多人會相信與認同.

事實上在任何數字背後都有其意義的, 這也是我常說的 "Nothing Comes From Nothing", 事出必有因, 很多事情無法確切的知道, 或者是量化的得到, 若是用另一個管道取得不同的資訊, 說不定真的可以參照.

而在這份數字中, 表現最好的是挪威與芬蘭都不到 1%, 這更似乎可以證明些甚麼的感覺, 但 IE6 的占有率應該是用兩個因子來造成的.

1. 資訊的利用率
2. 資訊的進化率

也就是說, 若都沒在用網路, 當然也不會有 IE6 的問題, 但若只知道使用網路, 而不知道去進化, 去更新, 這才是最糟糕的事, 我們很清楚的知道台灣的公家機關是如此, 但事實上也是人民, 廠商放任如此的結果, 也可以說這是社會的氛圍也不為過, 畢竟政府是我們選的, 我們建構的, 而從這邊倒是真的可以看清一些事情.

說到這邊, 大家應該會懷疑我的標題應該是 "從 IE6 來看台灣政治的困境" 這樣才對, 這也沒錯, 事實上我最近在玩一些數字的時候, 常常會面臨到一些問題, 雖然我們期望在資料探勘可以用較為 "平面" 的角度去抓取資料, 但事實上任何動作與行為都有出發點, 要能夠去避免偏見是不太可行, 只是這些也不是問題, 真正的問題是: "抓不到", 以及 "無法定義"...

尤其有些數字是人去填的, 就像是這次馬政府認定政見完成率有 88% 那樣, 說這是公正客觀的指標還不如說這是個話術比較實際, 因此有時候我們該去取樣的數字應該是更沒有立場的, 甚至是更大量的, 更即時的, 尤其若是用 "系統性", "自動化", "架構性" 的去抓這些數字, 能夠呈現的資料往往會超乎我們的想像.

例如我曾用噗浪去搜集過 "失眠", "感冒", "翻桌", "好熱", "下雨" 等等情緒性或較直接的現像的字詞計算來看社會, 有些是有點廢話, 當溫度交替時就會較多人感冒, 而我倒是想說若進一步的去搜集 "找工作", "失業", 說不定也可以呈現出社會的不同面與角度.

當然數字只是非常非常的表面, 不能用數字的表相來去看, 更應該像是統計去探索裏面的因子去做分析, 但這個倒不見的是 Data Mining 可以做的事, 畢竟有時我覺得資料探勘跟統計有點像 天文 vs 物理, 一個是你只能從觀察去找到答案, 另一個是可以去做實驗與驗証, 有時從這角度來看社會, 還覺得這個社會雖然說是個母體 (Matrix), 但說要去架構還真的不可能阿, 這也是人類有趣的地方.

下面是原噗的內容.

2011年3月2日 星期三

甚麼是 Context Switch


上一篇文章, 講了很多次的 Context Switch, 但到底甚麼是 Context Switch 呢? 我大概解釋一下.

電腦最核心的就是所謂中央處理器, Central Procesor Unit (CPU), 基本上就是接受指令, 輸入資料, 計算, 輸出資料做這樣的動作, 而事實上早期的電腦, 大多只有一個 CPU, 但要處理很多 Job 工作, 而最簡單的想法就是一個工作做完做下一個工作, 但這樣感覺後面的工作就一直在等待, 因此有人想說把工作切成很多很多部份, 而 CPU 每次就處理這些工作的一部份, 這樣感覺就是同時在處理很多工作, 稱為多工 Multi-Processing.

但事實上一個 CPU 一瞬間只能處理一筆資料執行一個程式, 一個工作須要成千上萬次的執行, 所以也不至於每執行一個指另就換下一個工作, 因為資料通常放在記憶體或暫存器 (Register, 就當作較快的記憶體), 而要把資料放在 CPU 能夠執行的記憶體才能執行, 這資料叫做 Context (文本), 但如此往往上百個工作事實上也無法把所有文本 Content 放在記憶體, 通常也要放進硬碟之類的地方, 等到要執行時再把要執行的資料讀進來, 再把部份資料移出去, 這動作叫 Context Switch.

很不幸的, 這個 Context Switch 的動作本身須要由 CPU 去做, 因此若是這個 Context Switch 發生的次數太多, 所花的時間也變多, 每個工作能夠分派的 CPU 在一段時間內能處理的次數也會變少, 甚至原本大家乖乖排隊可以在下次新工作分派之前執行完的情形, 反而因為 Context Switch 變多資源耗費很多便得無法執行完的話, 就會發生超越臨界值 (Threshold) 現像, 最後甚麼事都不能做或做得相當慢.

前面講完電腦的狀況, 但我們真正要討論的是人腦的狀況...

當然人腦到底有沒有這種 Context Switch 的現像呢? 當然我們都知道人可以一心多用, 甚至某些事情真的可以進到背景 (Background) 去執行, 只是人的思緒的確是有可能被打亂, 而在被打擾後, 想要回到原本的思緒的確要一段時間甚至回不來, 因此我一直在想, 我們工作的確會有這狀況, 而學習或唸書是否也會這樣子呢?

若真的會這樣的話, 人的學習應該是每一小時換一門科目或每兩小時換門科目呢? 而是修改成每兩天或每兩週再來換個類別 (例如數理一個類別, 文史一個類別), 事實上真正會須要換的原因是這些分門別類的科目, 在還沒有真的融會貫通之前, 做到 Knowledge is the One, 知識本一家之前, 我們是不是該在同一個時間內花更多的時間在一個科目或類別, 而不是一直換呢?

或許在某方面, 這樣一直換也不見得是壞事, 讓人的思緒更靈活, 但相對的也要付出還沒有深入學習就抽離的代價阿...

寫到這邊, 我 Google 到相關的定義:
1. Context Switch Wiki
2. Context Switch Deifinition
大家可以去參考看看...

(原圖取自 http://www.pedantique.org/)

2011年3月1日 星期二

Context Switch I: 思維切換的代價

在去年八月, 我寫了一篇從兩 種遊戲策略來看兩種生命模式, 說是為了要回應 Context switch in a Sprint?這篇文章, 但寫了之後, 一直沒寫下文, 因為我就進入了長達半年的低潮期, 這段時間我並不是真的沒寫文章, 甚至還有一篇不小心刪錯的, 其中我最想寫的是 2010 年我對 3C 產品的使用心得總結, 但最後還是沒有寫, 而此時突然想起這篇文章要寫, 就隨著衝動就寫吧.

我一直說我不是個好學生, 因為大概從高中時代開始, 我就一直很少上課, 即使人在課堂上, 心也不是在老師講的東西, 最大的原因, 是我在國二升國三時發現我必須要花半天到一天才能改變思維, 尤其是數理方面, 要進入這種思考模式, 手上拿著書可能前半天或前兩天念不到 10 頁, 但接下來的三天可以念完一整本, 即使是唸凡異的科普書也一樣, 以當時的能力而言, 說要把所有的學習與學問整合成一個相同的思維還太早, 至少我認為我不是天才, 所以要花這麼多的時間進入學習某種學科的狀況下, 說一天要排八堂課四個科目, 對我而言幾乎是浪廢時間, 還沒開始 Warm Up 熱身就要換個科目了, 說要去改變這樣的教學環境或改變我自己好像都很困難, 因此最後就有自個唸的覺悟了.

雖然我號稱 30 歲以前是個無業遊民, 事實上應該說作的工作連我都不想提起的失敗, 其中有兩個很強的經驗:

1. 因為看不慣中華電信壟斷網路資源, 曾經自告奮勇的去做當時科技為主的立委助理, 但做了兩個月, 我發現我平常是做工程師, 但政治的思維是有段差距, 雖說我大學時期長期從事學運, 但要一直切換這兩種身份對我而言是相當困難的, 所以最後只好辭掉了.

2. 後來我也去某財團法人上班, 想說平常我也是在寫程式, 在那邊也是寫程式, 應該沒甚麼關係吧, 但我在那時是在寫 BBS 程式, 而在 "公司" 寫的是協定與函氏庫, 雖然都是在寫程式, 但本質上是有相當差距的思維模式, 我也認知道我沒有能力去做這樣的切換, 因此離開也是必然的.

再加上有一次的 "賽斯經驗", 我大概就知道我比別人的 "Context Switch" 慢很多, 也就是說一般人說要切換思維模式可能耗損的集中力與專注力不多, 但我在做兩種不同領域的切換時候, 集中力與專注力要付出相當的代價, 所以我大概就知道, 即使我號稱能夠多工作業的人, 但事實上有個前提就是這些事情的思維邏輯都差不多, 不然我是做不來的.

PS. 原下標的時候是 "工作與讀書狀況", 但這邊怎看都不對, 只是已經快到淡水, 就只好換標題後存檔.

熱門文章