※ 引述《AmosYang (LetMeGoogleThatForYou)》之銘言：
: LolAI 的設計
[略]
一開始覺得自己沒空所以沒參與，後來看大家討論到心很癢，於是就試寫了一下...
後來寫上癮了，所以多撥出一些預定外的時間來做這個，但發現還真的是沒什麼時間，
搞到現在覺得有點心神不寧，一直隱隱約約在想這個議題 = ="
雖然想說真是害人不淺，不過回到以前這種解題的感覺也滿有趣味的，很久沒這樣了
anyway, 其實我只是想說，寫完 minei 0.1.0 後，回頭來細看討論，之前都沒細看
是因為不希望影響自己的設計方法。發現 LolAI 的計算法幾乎跟我一樣 @@"
不過用的名詞不太一樣，我不知道是否應該有正確的名詞？
裡面的 clause 我是命名為 clue, 而我另外有個 clue set,
大致是表達一個 block (cell) 可以得到一個 clue set.
而 N1 則是 clue set 的 overlap (intersection),
N2 N3 則是 clue set 在計算機率過程中會產生的。
看到那段 min/max 實在是很眼熟啊 XDDDD
雖然我不是很肯定兩者是不是完全一樣？ (scala code)
http://github.com/godfat/minei/blob/minei-0.1.0/Minei.scala#L111-117
val min: MineSize =
(set.map((clue) => clue.amount - (clue.poses.size - overlap.size)
) + 0).max
val max: MineSize =
(set.map((clue) => clue.amount
) + overlap.size).min
很不幸的是，經過 tkcn 測試，0.1.0 輸 Tkcn4AI 很慘，沒贏過 XD
而這版的機率確實計算很不完全，沒考慮很複雜的重疊狀況，
只假設一個 clue set 裡面只會有唯一一個重疊。我自己試玩的感覺是還行，
這證明了我不太會玩這個遊戲 XD
後來想試著加大搜尋範圍，一方面是跑得變很慢，另一方面則是因為搜尋範圍
變廣了，複雜重疊的狀況也增加，導致這種簡易的機率的準確度大降，
反而會讓他變成白痴。用了一些搭乘捷運的時間，好不容易想出考慮所有重疊
狀況的組合，不知道這個週末有沒有時間實作出來...
本來上週想詳細說明計算方法的，結果一直拖到現在都還沒寫。
還是乾脆等全部想法實作完再寫？ XD
目前暫定計畫是這樣...
1. 寫完說明
2. 釋出 0.1.1, 基本上演算法一樣，只是調整了內部實作，希望有跑快一點
3. 寫好調整 input 的 adapter, 還有一些利於 debug 的 methods.
4. 寫好一些比較容易實作的想法，釋出 0.2
5. 視情況調整，看有沒有放 0.2.1 的必要
6. 完成比較困難的實作，釋出 0.3
不知道 tkcn 所提到的考慮剩餘地雷有沒有辦法做進去？因為我原本的想法是
完全忽略剩餘地雷，假設我們在一個廣大的平原上，地雷總數未知。但這似乎影響
也滿大的。考慮極端情況，原本 1/2 的可能，由於剩餘地雷只有一個，當然不會
有需要兩個地雷的情況。再考慮 stimim 提到的考慮對手的盤面，這樣就真的是
minimax 的演算法了，看來這可以發展成做很久的計畫 XD
我最早的想法真的太天真了 XD 本來是想說算得差不多應該就很強了...
像是我現在跟 0.1.0 玩就沒有 100% 的勝算...
==
其實我原本真的只是想講幾句話，說 minei 跟 LolAI 很像..
--
「行け！Loki！」（rocky ロッキー）
－Gurumin ぐるみん 王子？ XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.135.160.129