有關電腦起卦

Wong兄：

您這問題，除了站長或程式撰寫者能回答以外，其餘人士，並無法給出一個客觀的答案。因為要評斷一個占卦程式的優劣，如同要評斷一個骰子的對稱性，如果沒有到達一定的量，少數的幾百占，不管是說好或著說不好，並沒有統計意義。

過去當我還很在乎占驗率的時候，總覺得占卜時道具與儀式，對占驗率有極大幫助，因此對電腦占卜或論命，自然容易鄙視，甚至嗤之以鼻，但現在則不然，我認為不管什麼學問，都應該與時俱進，占卜也不例外。如果撰寫程式者是一位懂易理的人，那沒有一種工具能比電腦更隨機與均衡。因此要請站長告知，進階版的程式，六七八九的機率是採哪一種？只要您認同這樣的分配機率，電腦占卜，是可以使用的。不單是卜卦，在這邊，我也看到有同好用程式解卦，雖然電腦解卦仍不完美，但跟十幾年前相比，實有天壤之別，未來一定大有可為。

占卜時，我們當考究工具的公平性，工具如果不均衡，占驗率一定受影響，不過即使工具是100%公平與均衡，卻不必然保證占驗。工具的均衡是占驗的必要但非充分條件，這是每一個占卜者在占卜前必須放在心上的。

我看見站內卜卦程式是用下面的方法以 pseudo-random 取卦:

焦氏: Math.round(Math.random()*10000000000000000)%64+1
初級: Math.round(Math.random()*10000000000000000)%64+1
進階: Math.round(Math.random()*100000)%8

普遍來說, 電腦 pseudo-random 的質量 (可說是 "隨機度/感"), 是高位置 (high order bits) 的比較好.  (更正2: 2016 後 web browser 的亂數產生器基本上已經修正了.)  而上述的方法, 先乘大後取餘數, 是採取了中至低的位置 (尤其 "焦氏" 和 "初級").  此外, Math.round() 是四捨五入, 也極輕微地使機會率偏了一丁點.  我建議修改如下:

焦氏: Math.floor(Math.random()*64)+1
初級: Math.floor(Math.random()*64)+1
進階: Math.floor(Math.random()*8)

(容我大膽估計, 站長先把數字乘大, 應該是想減輕由 Math.round() 所引致的機率偏差.)

(更正 1: Math.round() 所引致的機率偏差被緊接的餘數計算修正了.)

Javascript 裡面的數值, 是用 IEEE-754 的 binary64 格式儲存, 即是 Java 的 double.  它用了 1 bit 放正負號, 11 bits 放 "指數", 52 bits 去放 "有效數", 折算成十進數就是 15 至16 個有效數字 (理論值是 15.95).  大家可以想像, "987,654.321" 這個數字是儲成 "+1 * 9.87654321 * 10^6", 正負號是 "+1", 指數是 "6", 有效數是 "9.87654321".  不過電腦不是用十進數, 全是用二進數的.

Math.random(), 基本上是由(僞)亂數產生器, 拿出一定數量的 "(僞)亂" bits (0 或 1), "製成" 一個等於或大於 0 又小於 1 的小數.  數學上我們寫成 [0, 1)

Math.random() 是 [0, 1)

那麼 10000000000000000 * Math.random() 是 [0.0, 10000000000000000.0), 亦即是 [0.0, 0.5) + [0.5, 9999999999999999.5) + [9999999999999999.5, 10000000000000000.0)

再來一個 Math.round() 的四捨五入, 便得出 [0, 10000000000000000], 共有 10000000000000001 個數值, 當中 0 和 10000000000000000 的出現率比其他數字少一半.  可幸接著就 "% 64", 所以 0 至 63 的出現率理論上是相同的.

問題是 10000000000000000 這個數字太大了.

10,000,000,000,000,000 的二進制有 54 個位, 但 Math.random() 只有 53 bits 的 "隨機度" (因為限制了 0 至 1), 所以 10000000000000000 乘 Math.random() 所得的積數, 最低位置的 bits 其實是由前面的 bits 衍生出來的.  (如果使用特定的質數, 是可以把 Math.random() "隨機度" "適當地" "分散" 到積數的高低不同位置, 但背後的數學太艱深, 我不會.)

此外, Javascript 裡面的數值只有 15~16 個有效數字, 而可能的出現的積數, 十中有九, 整數部份都需要 16 個有效數字.  所以相乘數值後的個位甚至十位都有機會不準確, 而且有一些數值是直接丟失了.

最後一步, 用 "% 64" 計出餘數, 只取用了積數最後的 6 個 bits.

所以無論是 0 ~ 63 的出現率, 又或者是 "隨機度", 都有問題.

那 "進階" 的 "* 100000" 又如何呢?  現在很晚了, 請恕我明天才可以繼續.

簡單來說, "Math.round(Math.random()*100000)%8" 沒有問題, 但可以簡化.

隨機度方面, 是先取最高約 17 bits 的亂數 (100,000 ~= 2^16.61),  再取這 17 bits 的最低 3 bits (8 = 2^3).  而因為 2016 年後差不多所有瀏覽器都改用了比較高質素的(偽)亂數產生器, 所以這個方法是可行的.

分佈方面, Math.round() 是有問題.  但因為 100000 可以被 8 整除, 所以又修正了, 變成沒有問題.

但為甚麼要寫得那麼複雜呢?

我的建議, 只是引用了 Mozilla (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random) 的例子.

這個易學平台一字一句都是站長的心血結晶 大家有目共睹.  

"(僞)亂數產生器" 只是 "pseudo-random number generator" 的翻譯, 沒有其他意思, 若有冒犯, 請你原諒.

此外, 我發現 2017 和 2018 的資料有 xml 格式. 

http://www.weather.gov.hk/gts/astron2017/24SolarTerms_2017.xml

http://www.weather.gov.hk/gts/astron2018/24SolarTerms_2018.xml

1) 是不是由立春時間 "2016/02/04 17:46:02.659" 開始排 "小過"?

2) "驚蟄 和 "春分" 相䧚不足 30 天, 是不是用 6:6:6:6:6:1 的比例排入 "需, 隨, 晉, 解, 大壯"?

站長：

弟想建議再增加一隻一爻變的程式進入網站之中，

如果真有心習易者，一爻變可說是中階的版本，除了解卦的方法有共通性外，學者可體會易經中的易理與文句，這方是學易最有價值的部分。

焦氏易林，弟曾經研究數年，本想是否可藉此釐清多爻變的占解法，多年下來，除了歸納出論卦以之卦為主外，其餘一無所知，研究尚秉和的註解亦然，他可以把卦象說得無懈可擊，但卻忽視最基本的論卦方向與易例，這有可能是弟沒有人指導，自己瞎耗所致。萬般沮喪下，最終只能自我解嘲，焦氏易林偏向籤詩系統，毫無邏輯可言，與易經不同，雖然用之占卜亦有所中，然卻遠不及易經有益，邏輯也不如納甲，故與其花時間研究，不如拿那些時間研究易經或納甲。

以上為個人偏見，網站上如有能通曉焦氏易林者，尚望能指導一二。

高島吞象好像分三次取下卦, 上卦 和 動爻.  三次都是用 49 枝竹籤開始, 隨意分兩份, 只算其中一份. 取下卦和上卦是拿 8 的餘數, 取動爻就拿 6 的餘數.

那是不是以卦辭為背景, 再用爻辭去解?

高島吞象的略筮法其實用的是梅花易的先天數起卦法。

設計程式只要把機率原理控制好即可。不需仿效梅花易。

我認為只要設定成兩個變數：1. 取本卦的機率為1/64，然後對應到1-64卦。2. 取變爻。機率控制在1/6，初爻，2爻，3爻至上爻的機率皆為1/6。

最後呈現的有兩個資訊：1. 卦辭（含十翼解釋）。2. 爻辭（含十翼解釋）。

最後並提供詳讀周易今解的連結。到時後周易今解裡，我會再加anchor，讓每個卜卦結果都能夠連到每一個爻辭的解釋。

站長想不想小改一下占卦網頁, 方便用家張貼連結?

例如 "http://www.eee-learning.com/eeeApp/eee.html?gua=666999" 就是否之泰.

如果覺得可行, 我可以嘗試幫助.