我並沒有去專門為了lisp使用字首表示式而去網上尋找鼓吹有關此方面的文章或書籍。我也並不是lisp的狂熱愛好者。學習lisp最初只不過是學習其偉大思想。 不過當我慢慢學過lisp一段時間之後，我慢慢的發自內心的喜歡上了它。我用的是scheme，乙個教學用的語言。當然對於其使用的字首表示式我也想說一下我自己的認識。
先說一點：字首表示式也可以叫波蘭式，字尾表示式也可以叫逆波蘭式。
上過資料結構課，我們都知道字首、中綴和字尾表示式分別對應的表示式樹的先序、中序和後續遍歷。也就是說字首、中綴和字尾表示式這三者可以互相轉換的。
比如：
很多人是很不適應甚至反感字首表示式的，因為很不習慣，我們從小學習數學，學習基本的四則運算，好像數學都是用的中綴表示式。真的是這樣子嗎！
其實不是的，在四則運算加減乘除以外的世界，其實都是用的字首表示式，舉個例子，比如根號√4，這是在數學再常見不過的求根表示式了。它就是乙個字首表示式。 根號在最前面。當然根號是個一元運算子，根號裡面的被視為乙個整體，對整體求值。
在舉乙個例子，比如令許多人頭疼的積分∫。它也是字首表示式，積分符號∫在各個引數的最前面。
現在看來，數學書上就是在用字首表示式，大家也都可以適應，為什麼到了程式設計中就不怎麼適應了……
當然更坑爹的是逆波蘭式：比如pascal中定義變數var x : real; 或者近來的年度語言golang的定義變數var x float。(順便說一句，之前看過王垠的部落格，它也不喜歡go的這種定義變數方法) 大家習慣的是比如double x;這樣子的定義變數方法。
當然有些時候，在處理二元關係的時候，無論是波蘭式還是逆波蘭式都沒有中綴表示式好理解。就比如我們的四則運算，只不過是把加減乘除當作了特殊的運演算法。 也就是只能處理二元關係的運算子(這裡的是減號而不是負號–一元運算子)。
除此之外呢，比如函式f(x . y)，這個樣子寫是表示函式f中可以有多個引數。也就是c語言中的f(int… a)可變引數。
如果我們把函式f當作是乙個運算子，其實它可以是運算子或者是它就是運算子，因為它處理了引數。函式就是乙個採用字首的表達方法。
因為如果你不用字首你怎麼寫出表示式呢？比如要定義x，y，z這三個引數的和的函式，sum(x, y, z)，如果用中綴你如何寫出表示式呢？ (x sum y) sum z 這個樣子嗎？這個樣子好像也停坑爹的。也就是說字首可以支援任意多的引數，而中綴只能支援兩個。因為到了多元關係之後，中綴幾乎不存在 這樣的表示方法，根本沒有可比較的物件。
所以當處理非二元關係的時候，字首表示式還是有一些優越的。另一點，如果這個operator的名字比較長，放在前面會好看一些。(竊喜
當然使用字首表示式可以與函式表示方法相統一。這個樣子，就可以使得很多事情變得和諧，統一。
說了這些，其實字首中綴最大的分歧在於二元關係上，如果二元關係出現的多，那就使用中綴表示式，如果多元關係出現的多那就使用波蘭式。
關於群智慧型優化演算法的一些雜想
群智慧型優化演算法個人認為最本質的就是迭代演算法，而針對單一演算法所存在的缺點如易區域性收斂 全域性搜尋能力差等 根據不同的演算法內部迭代過程的所呈現出的不同機理，這就使演算法與演算法之間的混合有了理論基礎，關於混合演算法現說下自己的若干思路 兩種演算法交叉迭代，再與兩種演算法的效能相比較，這也是一...
cola php,ColaPHP2 0的一些想法
colaphp第乙個版本0.1alpha是2009年7月發布的，到最新的版本1.3ga，三年多的時間，13個版本的發布，1.x系列差不多就這樣了，基本上不會有大的設計改變，後續如果發版本應該也只是bugfix之類。很久以前就在設想colaphp2.0做些什麼，也曾經透露2.0只會支援php cola...
關於RemoteView 的一些字型的一些問題
最近在做乙個 在notification 新增 天氣通知的小部分 發現困擾在 如何給 remoteview 中的字型 作修改 大家都知道 textview 設定字型 在xml 中 可以 設定 3種 而其他字型的設定 需要通過 typeface 去設定 具體 將字型放置在asset 資料夾中 type...