Author: Bernd Nürnberger
Date: 04:59:22 04/05/04
Go up one level in this thread
On April 04, 2004 at 16:11:46, Dieter Buerssner wrote: >On April 03, 2004 at 08:17:31, Bernd Nürnberger wrote: > >To investigate the problem, you could try the following. Disable null move (any >selectivity depending on the bounds), disable path dependent extensions (like >recapture), allow cutoffs from HT only, when the draft exactly matches (not when >the draft in HT is higher, than the current search depth, just use it for move >ordering then). Depending on the details of the engine, few more things would be >disabled. Then you should get exactly the same scores at the same depth, >independent of your moveordering. I did this, when I implemented hash tables the >first time. At the moment, I am also fighting with a HT related problem (after >reimplementing it). > >Regards, >Dieter In the mean time, I recognized that it's (at most ALSO) a hash table bug (or more for instance) at the moment. When XOR'ing values for the next move, I only naivly XOR'ed in moving piece from/to and captured piece/to and totally forgot about castling and e.p.!! (In the source code I wrote once deep in the night a big "TODO" in the table.xor() function %-) and forgot about it) I have to update properly when I loose any castling right or the e.p. field changes... and it will be simply to overlook something here... Greetings, Bernd
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.