Author: Robert Hyatt
Date: 11:27:05 09/10/99
Go up one level in this thread
On September 10, 1999 at 13:49:50, Bruce Moreland wrote: >On September 10, 1999 at 13:07:02, Robert Hyatt wrote: > >>On September 10, 1999 at 12:58:13, Bruce Moreland wrote: >> >>>Store all mate scores as bounds and see what happens. I'll tell you what will >>>happen. You'll find this in a few seconds and there won't be any bugs. >>> >>>bruce >> >> >>It didn't help a bit, unless I modified the bounds as I mentioned. I was always >>updating a true mate score, and getting rid of this didn't help a bit, as I >>expected when playing around yesterday. The problem was those "mate in N" >>bounds that get stored... they can be wrong if they aren't adjusted. I now >>store true mate scores as always, but mate bounds are reduced to just say >>"< -MATE+300 or > MATE-300. I use 300 because of the large tablebase mate >>scores that get stored. But I am still storing actual mate scores as I have >>never had a problem with that (i adjust them to mate-in-N from the current >>ply of course.) >> >>But those bound mates were causing this particular problem to blow up, because >>I would store > MATE-10 (mate in 5) at position X, ply 8, then look that up at >>ply=10 or 12 and make a wrong decision. It was _very_ hard to find in a tree >>of 1M nodes... > >I should clarify. > >Convert as follows: > >Mate in N becomes >= Mate in 500 >-Mate in N becomes <= -Mate in 500 I did both of those. They didn't affect this problem at all. However, as I mentioned, I have _never_ had problems storing EXACT type positions with mate scores. >>= Mate in N becomes >= Mate in 500 <- This is our point of dispute. ><= -Mate in N becomes <= -Mate in 500 <- So is this. ><= Mate in N is simply not stored. <- A nasty case. >>= -Mate in N is simply not stored. <- Likewise. > I now do the above (although I use 300). I wasn't doing this before. If a position said >= mate-in-N, I stored it as is. And that caused this ugly bug... although it really only affected positions where there were lots of transpositions to longer/shorter mates. Steffen's position just happened to highlight the problem for me. I do ignore the last two cases. In testing they were very very rare, and the test to not store them was slower than the tiny bit gained by not overwriting a useful entry with something that is almost meaningless... You used the term "a nasty case" on the last two. Did you run into problems when you stored them? Or just the overwrite issue? >This should confidently fix every bug known to man, it short-circuits all of the >problems you mention above, it will take you five minutes to implement, and the >only place you have special-case code for mate scores in the hash table is in >the hash table store code, you don't have to have weird stuff in your probe >code. > >bruce The only reason I don't convert mates to bounds is that this loses efficiency in tablebase hits, because I store the corrected mate scores and can use them directly. Otherwise I have to probe _again_ to get the real mate score each time I run by this position. Otherwise it is not very important, as until you find a mate, they aren't present. And once you found the mate, you can probably find the mate in N-1 without relying on the hash table, although it is neat to play the remainder of the mate-in-N variation instantly as your opponent replies.
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.