On Tue, 2008-12-30 at 20:01 +0200, Berk Ozbozkurt wrote: > Don Dailey wrote: > > After 842 games with 19x19 go the version with the 3-4-5 line rule is > > scoring about 55% > > > > I thought it might do better, I think the rule is reasonably sound - but > > 55% is pretty respectable for such an easy change and it hardly slows > > down the search at all. > > > > Rank Name Elo + - games score oppo. draws > > 1 d2p 2037 12 12 842 55% 2000 0% > > 2 base 2000 12 12 842 45% 2037 0% > > > > > > > > > You are using the rule for move selection during the playouts and the > search, right?
The rule applies in the playouts, as well as final move choice. > > I think such a change may make engine objectively stronger while making > it more vulnerable against humans. I don't think that is the case. The premise is that it's wrong to violate this rule (even though we admit it is not 100% correct) - and even so, 99.9% of the time it's probably not a serious error. When the opponent violates the rule, the computer then is free to respond of course. > Even if the human opponent isn't > aware of the move pruning logic initially, it wouldn't take a lot of > games to figure out that the computer never makes a move away from the > last move to the center or to the sides. No, the computer can always move to line 3,4 and 5, OR it can make a move within distance N of ANY STONE sitting on the board. This is not limited to just the last move. So what you say next is probably based on a misunderstanding of how I implemented the rule. > Once the player understands the > reason (because the engine never _considers_ such moves) building traps > should be very easy for a good go player. For example, start a losing > ladder towards the center on one side, then start another losing ladder > to the center from another side, such that a ladder breaker in the > center can break both ladders. Now the engine would play thinking all of > its stones in the ladder are safe, oblivious to the fact it will be able > to rescue only one group of them, if a move to the center is made. Of > course the same idea may be used by a programmer to specifically build > an engine stronger against engines with 3-4-5 rule too. > > The engine should at least allow _opponent_ to break the rule in the > search tree. This is one of those things that look good on paper, but I have real doubt it would work in practice. I have never seen asymmetric rules or evaluation actually work out like you think it should. I never say never, you may be right, I'm just saying I don't have any faith in that idea. The problem with asymmetric rules like this, is that it's really based on the assumption that you (the program) doesn't know what it is doing, but your opponent does. If he plays one of those moves it "must" be good but if you play it it's probably bad. That's a self-defeating attitude to base a game playing program on and it's eventually self-limiting. It's funny, but I have done the same thing in my own games when playing a stronger player and have come to grief. I once thought I had a pretty strong attack (in chess), which my much stronger opponent, by his move choice, told me that he didn't believe there was anything there. My time was relatively short, so I "relied on his analysis" and believed him. It turns out that I was a fool in this case. He really needed to defend against my attack to win. He had a probably win if he had defended, and now he had a win because I failed to follow through with natural attacking moves. I should have just trusted my own analysis. Even if your opponent is stronger you should never assume his moves must be correct and yours must suck. > That is quite a bit harder to exploit. Now the player must > find moves with refutations outside of the allowed search window. But > there is now the problem of increased evaluation difference between odd > and even depths (as one "player" is objectively stronger.) > > Therefore I think you shouldn't let engine prune in the tree with *any* > simple heuristic rule, no matter how often that rule is a useful guide. > OTOH pruning in the playouts seems safe enough. Does that increase > strength too? I don't think you realize that this is not a tree based program - it is basically the simple reference bot modified with the 3-4-5 rule. The refbot does N playouts, then uses AMAF to select a move without any kind of proper tree search. But I definitely agree with what you just said about pruning in the tree. I don't believe in "hard pruning", it should always be progressive. Unless of course you have stone cold proof that a move is less than the best. For a practical program you may be able to do cold hard pruning right now, but this is inherently non-scalable. It means there will always be a class of moves your program can never play correctly even with an infinite or arbitrarily deep search. In the case of the reference bot, it's not scalable ANYWAY, no matter how many playouts it does. So it's perfectly valid to create hard and fast rules that may be wrong on occasion because there is no chance the program is going to be able to resolve the sophisticated details. It's almost like the eye rule we use. It's broken essentially, but random playouts cannot begin to understand the fine points of how and why it's broken. Not using the eye rule because you know it's broken would be a very bad decision. It's almost like estimating how long it will take for the apple to hit the ground using a tape measure and Newtons laws of gravity. Someone could criticize you for not using Einsteins relativity, a better predictor but that would be pretty foolish considering that your tape measure is so crude in comparison that it's not going to matter. That's probably why you said that things like this probably wouldn't matter too much in the playouts. - Don > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
