6 ms·
I'm trying to express why Go is a difficult problem to solve. I'm saying this (scoring, play-out) has been a difficult problem, which was not solved even a sma
by ronaldx 12y ago
I'm trying to express why Go is a difficult problem to solve.
I'm saying this (scoring, play-out) has been a difficult problem, which was not solved even a small number of years ago, and is still not considered straightforward. Even if it is solved correctly now, that's only a start.
I would also note that Monte Carlo is by definition a heuristic method - it is statistical and not guaranteed to be optimal.
- rockdoe 12y agoI would also note that Monte Carlo is by definition a heuristic method - it is statistical and not guaranteed to be optimal. So is the endpoint evaluation in chess programs. This isn't a difference between Go and the other games. (In fact, pretty much nothing in your original post is)
- ronaldx 12y agoAnyone who has a modest understanding of chess can codify very simple rules for identifying a winning endgame. There are extensive wikipedia articles on what constitutes a winning endgame in chess, as the board simplifies towards the end of the game: https://en.wikipedia.org/wiki/Endgame_tablebase https://en.wikipedia.org/wiki/Endgame_tablebase says "All chess positions with up to 6 pieces have been solved" So, I disagree. Even if you don't count this as a theoretical difference, it is a practical difference.
- rockdoe 12y agoAnyone who has a modest understanding of chess can codify very simple rules for identifying a winning endgame. The exact same thing can be done in go, scoring a finished game is trivial. The strength of the program simply isn't determined much by correctly identifying and scoring terminal positions, but the intermediate ones. And for both chess and go, one very much uses heuristics which are often wrong. If the heuristics were never wrong, you wouldn't have to do the tree search part at all. Endgame databases only have a tiny effect on the strength of chess programs (a common misunderstanding!) just because it's not very common for the game to be still "flippable" by the time they become relevant. In all the other positions, you need the heuristics. The situation for checkers on the other hand, is very different. There the endgame databases were critical for solving the game, but due to mandatory capturing rules the search space reduces much faster. Edit: Not sure why HN won't let me reply. But anyway: the error that you're both making is assuming that the positions in which humans stop and score are "endgame" or "finished" positions. That's not at all the case! A game is finished if there are no more legal moves besides filling one's own eyes. Counting at that point is trivial because all the life & death situations are "resolved". Monte Carlo programs play until those positions, not the ones where a human would stop the game. (if you now bring up seki, you get half a cookie)
- thinkpad20 12y agoIt seems you've studied this more than me, so perhaps I'm just misunderstanding you, but it sounds like you are equating a finished game with endgame. Scoring a finished game is obviously trivial, but even when a small number of positions remain open on a Go board, the game tree is still combinatorically vast, and I don't think there are any "simple rules" for determining optimal play.
- thesteamboat 12y agoAs it turns out, Go endgames are surprisingly tractable with clever mathematics. See for example http://senseis.xmp.net/?MathematicalGo http://senseis.xmp.net/?MathematicalGo
- sehugg 12y agoI wouldn't say scoring is trivial -- it depends on both players agreeing which stones are alive or dead. Experienced Go players "just get it" but computers don't: http://www.andromeda.com/people/ddyer/go/scoring-games.html http://www.andromeda.com/people/ddyer/go/scoring-games.html
- rockdoe 12y agoScoring is trivial - if the game is actually finished. No human wants to play go games to the finish so essentially all human games are scored by agreement. But a Monte Carlo program just simulates the game vs itself. See the addenum to my post above.