Author: Bruce Moreland
Date: 00:04:43 01/23/98
Go up one level in this thread
On January 22, 1998 at 20:02:17, Stuart Cracraft wrote: >I'm trying to get my hash table to be a little bit more full. Maybe >that's >a bad idea. It's already doing okay at or around the expected percentage >of successful probes. If I were in your shoes I would try to get the hash table thing working simply and without any bugs, which will be hard enough. Since your program is pretty new, you'll probably change tons of stuff, and this will change how it responds when you do benchmarks to see what is better. You can come back to this when everything else is in top shape. My litmus test for hashing has always been that if Fine 70 gets Kb1 in a second or so, you're probably OK, but if you stall out at around ply 18, you have something horrible going wrong. Fine 70: 8/k/3p/p2P1p/P2P1P/16/K w - - 0 1 The key is Kb1 and you should see a score jump of around a pawn at some point, and if you get a PV you should eventually see a "Kxf5" in it somewhere. Of course, if you get this in a second or so, you might still have something horrible going wrong. Hashing bugs that I've seen have involved the following: 1) You have to be careful when hashing mate scores, since they are depth-specific. When you implement distance-to-mate endgame databases, these problems can get really awful since you are dealing with mate scores so often. 2) The effect of things that aren't hashed. It makes no sense to hash the entire path to get to a node, so there is always a risk that you can make a wrong decision based upon a hash table node, because some position appears in the path you took to get to one node that didn't appear in the path you took to get to the other. What this means is that certain moves that will appear below this node may lead to repetitions in one case and not the other. This happens enough to be annoying, and I think that it is impossible to fix. Simply not hashing draw scores will not do it, although it may make a problem (usually a fail-high followed by a failed resolution of the fail-high) stop manifesting in a specific case. 3) Failure to hash en-passant square (if present), castling flags, or side to move, can cause problems, especially this last one if you use null-move search, I'd think. 4) General bugs having to do with failure to store or interpret the bound info properly. It's amazing how often you'll hear that someone got something backwards in here, and stored some nodes as "less than 40" rather than "greater than 40" or whatever. I'm sure there are a lot more, since I have had a lot more than four bugs. bruce
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.