賽局高手 – 全方位策略與應用

書有兩個作者,就如同博客來上面留言的書評,介紹賽局的部份還不錯看,蠻好懂的。可是一換到政治章節,就好像突然岔題了,感覺格格不入(而且容易過時,書上是寫2001左右的政局)。

首先介紹了靜態賽局,即參賽者同時出招,只互動一次。這時候一定會有納許均衡解(但不唯一),若有無論對手如何反應都有最好的策略,又叫優勢策略。採用不可預測性的策略,又叫混合策略(即用機率來決定用哪個策略)。

動態賽局則是出招有先後,這裡介紹了子賽局完美納許均衡,利用從最後的子賽局往前推的逆向歸納法。在動態賽局中,誰先出招對均衡影響很大。

在賽局中,不合作常是均衡解,常形成囚犯困境(合作是好,但不合作是人性啊~!)。但是如果是無窮重複的賽局,就有可能有合作的均衡解,任何只要超過最大的極小策略報酬,就可能形成長期支持的合作策略,即隱藏性勾結。

前述又還有分完全訊息跟不完全訊息,因為不完全訊息比較難,所以作者只用了拍賣跟談判來舉例,介紹了次高價拍賣(出最高價者得,但是用次高價的價錢)是不完全訊息下的貝氏納許均衡。

邊緣主義是一種刻意把對手帶到最大危險的臨界點,並以此迫使對手退縮的策略,重點是一道斜坡可進可退,千萬不可以弄成懸崖。要能控制好賽局的結果,建立自己可信的承諾跟信譽是非常重要的。而最適的動態策略是”會被觸怒”策略,永遠有反應,你善意合作,我善意回,你沒好意,我就懲罰逼使你釋出善意,同時也保有寬恕跟彈性,避免以牙還牙的報復困境。

當閱讀遇到數位

今天去政大聽了這場研討會(第一次去政大說),當然是衝著台灣Google研究所所長簡立峰去的,所以只聽了早上的場次,中午就落跑了…:p

簡所長先介紹一下Google現狀,提到Google不只是search engine,而是擁有一個龐大的 infrastructure (上萬台的server散佈各大洲),使用者一個簡單的 search 動作就會同時動作各洲的server來做 search,合併結果回傳給user。

要說為什麼Google可以有這麼多創意產品,倒不如說因為有這個架構,只要data進去,各種創意應用就會源源不絕的實現。 閱讀全文〈當閱讀遇到數位〉

Server 搬家,Lighttpd 初登場

還是自己架Server用起來比較方便,之前主要是家裡的頻寬太慢沒辦法架站,所以只好放在遙遠的 bluehost

這幾天家裡延宕已久的ADSL終於升級好了,從 9/8 線上升級到8M/640k,中間不知道打過多少通123,來了三個工程師終於搞定,給中華電信鼓鼓掌。

因為要用 Rails,所以 Web Server 我改用眾所推薦的 Lighttpd,不過第一次用調教了好久,主要是 Rails 的設定跟 wordpress 的 rewrite (跟 apache 格式不同)。

主要是 follow 著  lightyror.blogspot.com/ 來設定,本來想用同一個 domain,不同目錄的方法來跑 rails。一開始跑 fcgi 就出不來,try 了好久才知道沒裝 ruby-fcgi,用 gem install fcgi 也裝不起來,後來用 FreeBSD 的 /usr/ports/www/ruby-fcgi 很快就裝好了。

設好之後,因為多一層目錄的關係,還要改 routes.rb,這裡又try了好久不知道為什麼一直Recognition failed。成功跑起來之後,我發現 public 裡面的css跟圖片連結等還是不對。呼,還是用 domain 區分比較不惱人啊,回頭又把 DNS server 設好跑起來。

支援php+fastcgi照著lighttpd的文件做就可以了(先裝 php4-cgi 再裝 php4-extensions),麻煩在 wordpress 的 permalinks,原本用 apache 有寫好的 .htaccess 檔,換 lighttpd 之後就得自己來設定 rewrite了,找了 google 好像沒有也直接可以套用的… :(

溫伯格 你想通了嗎?

 蠻有意思的一本書,討論”解決問題”這件事情。沒有複雜的理論,可以很輕鬆的看一些故事,提供了一些不錯的思維切入點。

問題是什麼?

  • 在開始解決問題前,先釐清這個問題 : “誰有問題?”
  • 問題往往來自期望和感受之間出現了落差
  • 不要嘗試幫一個沒有幽默感的人解決問題,因為那簡直是自找麻煩。 (註:因為思考需要天馬行空一下,解法也可以很有創意)

這是什麼問題?

  • 不要把別人解決問題的方法,當成問題的定義。尤其是當解決方案是你自己提出的時候
  • 如果你很輕易就解決了別人的問題,那麼他們將不會相信你解決了他們真正的問題。 閱讀全文〈溫伯格 你想通了嗎?〉

學習 Programming 的歷程

thegiive提到他的學習歷程,覺得蠻有趣的。

我自己接觸的順序是

(2001) C++ -> Pascal -> (2002) PHP,SQL,Javascript -> (2003) Assembly、C、Java、Scheme、Prolog、C# -> Perl -> (2004) UML、Design Pattern -> (2005) CSS、XHTML -> (2006) Ruby、unobtrusive Javascript

第一次認真學的程式語言就是C++,啃的是侯捷翻譯的 Essential C++ 中文版,記得當時還唸了兩遍,滿滿的註記,看到了 procedural,generic (STL),object-oriented 等不同面向的精隨。C++不只是物件導向的C而已,而是更好的C,要我建議,我還是認為可以直接學C++,不一定要照先學 C 再學 C++ 的順序。

Pascal 是清大資工的大一程式設計課,不過最近他們開始改上C了,Pascal 是個古董嚕。PHP,SQL,Javascript 是要打工才學的,也開始接觸 web programming,學到很多經驗,一直用到現在。Assembly,C,Java,Scheme,Prolog,C# 都是課堂上學的,並沒有學的很深入,僅只是交作業程度,不過也讓我的廣度增加不少。Perl 是去學校計中打工學的,認真看了駱馬書,看到了一個非常有意思 hacker 語言。接觸了 UML,Design Pattern,才真正了解物件導向的威力與應用。碰到網頁標準興起,才又認真學好CSS。今年則開始認真學Ruby跟RoR,也打算把 Javascript 重新學過(當代的Javascript跟幾年前又有很大的本質差異了)。

老實說,學什麼語言要照什麼順序嗎? 還在學校的話,就學學C++或C吧,因為不論新出了什麼語言,C/C++是會存在到世界末日的那一天的。要做 Web Programming 的話,認真學好網頁標準(至少CSS跟XHTML)吧,只要還用瀏覽器看網站,這都是不變的基礎。至於要學什麼語言來安身立命,我覺得也是看機緣、主流、喜好跟自己的判斷了吧。

話說回來,拿 Ruby 當你的第一個程式語言也是不錯呢,可以看看Learn to Program,超入門的。