Author: Tim Foden
Date: 12:08:57 12/18/00
Go up one level in this thread
On December 18, 2000 at 14:34:22, Robert Hyatt wrote: >On December 18, 2000 at 12:42:57, Bruce Moreland wrote: > >>On December 18, 2000 at 07:08:38, Tim Foden wrote: >> >>>Hi All, >>> >>>I have recently been looking at lots of old posts (I've been mucking around >>>with my own archive browser with better search functionality), and I keep >>>coming across the FINE 70 position as a good test for a hash implementation. >>> >>>I have been worried about the hash code in GLC for a while now, but I haven't >>>been able to track anything down that is wrong. I'm not sure there _is_ >>>even anything wrong. >>> >>>But... on the FINE 70 position below, GLC takes ages to see the gain of the >>>f5 pawn. >> >>Here are some more ideas for experimentation. If you can turn your hash table >>completely off, see what that does. Another thing to explore is what happens if >>you leave your hash table on, but don't allow it to generate cutoffs. >> >>I have done a lot of testing of this position over the years. I use it as a >>sanity check now and then, in order to see if I have broken hashing or if >>various pruning experiments cause it to explode. >> >>My first experience with it involved some output from Cray Blitz, which showed >>it solving this in the 18th ply. >> >>My own program completely bogged in the 18th ply, but didn't find it. I >>determined that this is what happened when my program had severe hashing bugs. >> >>When I fixed these bugs my program went like blazes but it didn't solve the >>problem until ply 26. No big deal, that was only a couple of seconds. I spent >>some time trying to figure that out, and eventually decided that this didn't >>matter. > > >This is an interesting problem... here is why. Suppose the first move you >search is bad, and then your opponent's reply is bad (your move ordering at >the first two plies sucks). Now, at ply-3, you discover that you can force >a win from this position I will call (P). But then you try better moves for >your opponent, and you don't see anything good. Then you try a better move >at ply-1, and although you can't search deep enough to directly see the win, >you can search deeply enough to reach position (P) which you recognize as won >from the hash table. > >The bottom line is the better your move ordering, the later you see this. If >I recall correctly,this is a 26 ply winning plan to grab the first pawn. With >perfect move ordering you should see this around depth=26. With less than >perfect ordering, you can shorten this quite a bit. It is also _very_ sensitive >to hash replacement and table size, as the critical position (P) has to be able >to stick around long enough to be useful. If it gets overwritten, then you >have to find it on your own.. > >good hash test of course... and this should bog badly at some depth. By >the time you hit ply=30, you will see _lots_ of pawn promotions but they get >pruned away instantly by the alpha/beta window. But once you hit 30+, you >will eventually find a way where you can force a queen no matter what the >opponent does. And suddenly those cutoffs don't happen any more, and the >search simply hangs as you will _never_ be able to search your way out of >a tree that deep with queens on the board. > >The hanging isn't necessarily a bad thing, here... Agreed. But GLC hangs *before* it sees the pawn win, let alone the forced promotion. I think it is an indicator that something is not right. I just don't have a clue what it is! :) Cheers, Tim. > > >>> 23 15.81 1.05 3530404 Kb1 Kb7 Kc1 Kb8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 Kb7 Ke3 >>> Kc7 Kf3 Kd7 Kg3 Ke7 Kf2 Kf7 Ke3 Ke7 Kd3 >>> 24 2:21 1.05 25881k Kb1 Kb7 Kc1 Kc7 Kd1 Kd8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 >>> Kb7 Ke3 Kc7 Kf3 Kd7 Ke2 Kd8 Kd3 Kc7 Kc4 Kd7 >>> 24 2:21 1.05 25895k Kb1 Kb7 Kc1 Kc7 Kd1 Kd8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 >>> Kb7 Ke3 Kc7 Kf3 Kd7 Ke2 Kd8 Kd3 Kc7 Kc4 Kd7 >>> 25 2:21 1.05 25908k Kb1 Kb7 Kc1 Kc7 Kd1 Kd8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 >>> Kb7 Ke3 Kc7 Kf3 Kd7 Kg3 Ke7 Kf2 Kf7 Ke3 Ke7 Kd3 >>> 25 2:22 1.05 25930k Kb1 Kb7 Kc1 Kc7 Kd1 Kd8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 >>> Kb7 Ke3 Kc7 Kf3 Kd7 Kg3 Ke7 Kf2 Kf7 Ke3 Ke7 Kd3 >>> 26 11:47 ++ 127200k Kb1 (a=0.55 b=1.55 e=1.55) >>> 26 22:23 2.25 236793k Kb1 Kb7 Kc1 Kc7 Kd1 Kd8 Kc2 Kc8 Kd2 Kd7 Kc3 Kc7 Kd3 >>> Kb7 Ke3 Kc7 Kf3 Kd7 Kg3 Ke7 Kh4 Kf6 Kh5 Ke7 Kg5 Kd7
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.