※ 引述《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