※ 引述《godfat (godfat 真常)》之銘言： : 希望這樣不會過度閒聊... XD : ※ 引述《AmosYang (LetMeGoogleThatForYou)》之銘言： : : 同感 XD 尤其是「試寫了一下…後來寫上癮」 : : 整個就是這樣 http://xkcd.com/356/ 的感覺 XD : what about computer scientist? lol XD : : clause 比較正式， clue 比較口語化， : : 在這個背景(context)底下，我覺得兩者都可以用 : 如果可以還是希望能用比較正確的名詞，不過我不是很確定 clause 在這裡的意思 可以參考 http://en.wikipedia.org/wiki/Clause clue 譯作線索，在這個 context 底下的確代表著「算出地雷位置的線索」 clause …中文我不知道該譯成什麼，比 clue 抽象， 可以算是完整 sentence 的 building block 哪個比較正確…我也不知道，就我的語感來判斷我是選 clause 但語感這種東西我也不知道該怎麼解釋 XD : : 我也是在這個問題上花了至少兩、三個小時 : : 但最後其實可以寫得很簡潔 (perf 是另一回事) : : clause/clue 的處理完全不需要考慮到特殊案例 : : 完全就只是 set 間的計算 : : 反而是每一代新、舊 clause 之間的取捨很重要 : : 雖然其抽象的實作對 perf 造成問題，但寫起來很爽 XD : 沒錯可以很簡潔... 慢慢調整之後，很多我原本分開算的東西， : 其實都已經變成同一件事了。不過一開始去想這個問題時，沒辦法 : 這麼輕易找到這件事。 : performance 就真的完全是另一回事了 XD : 我現在在想的是，有些計算應該是重複的，想辦法找出來應該可以節省很多。 : 還有前面可以多跑幾個讓地圖簡化的運算。不知道有沒有可能用上 dynamic : programming? 能省下來的計算在於 1. C1 * C2 與 C2 * C1 的結果會一樣，所以每個 pair 只需要作一次 2. 場面上可以會有很多 clauses, 其實 clause 之間的關連性很 sparse 所以這裡也能省下一些 例如說: C1: 0 <= { Cell1, Cell2, Cell3 } <= 3 唯一要跟 C1 計算重疊機率的，就只有 「任何含有 Cell1, Cell2, Cell3 的 clause」 這就可以省下不少 我覺得 DP 不會有太大有效用，因為要建表的話，最後整個表會非常 sparse 且這個表的 index 會很噁心，省下的時間說不定正好與查表的時間抵消 XD 我覺得在上述兩點就能省下至少 50% 的計算 (最後這段看不懂是正常的 XD 這裡自己寫過一次就懂了) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 24.148.239.184