Author: Dieter Buerssner
Date: 12:36:54 07/11/04
Go up one level in this thread
On July 11, 2004 at 14:35:50, Eric Oldre wrote:
>a) did I just not let it search deep enough?
>b) does the fact that it took 3:51 to reach depth 21 indictate a issue with my
>tranposition table?
Yes. I tried this pos with only 1000 hash entries. It was solved in no time.
Independent of the hashing scheme you are using (say depth preferred or always
replace or more sophisticated), your hashing probably does not work well. I
assume, you have null move disabled.
>it was running at 1,200,000 nodes/sec.
From this speed, I guess you are generating the hash keys incrementally (in your
makemove/undomove?). A first start might be to check if they are correct, by
comparing the incremental keys with ones you generate from start. You might also
want to describe your hash struct, how you store/probe, when you cutoff, ...
>if there is a issue with my transposition table, could it be due to not having
>random enough keys? here is the code i'm using to generate the numbers.
>
>U64 rand64(){
> U64 retval = 0;
> retval = (retval <<15) | rand();
> retval = (retval <<15) | rand();
> retval = (retval <<15) | rand();
> retval = (retval <<15) | rand();
> retval = (retval <<15) | rand();
> return retval;
>};
This will work with many implementations, and will be very poor with other
implementations (all those, which have a RAND_MAX >= 2^15-1). A fast fix is to
use xor instead of or, to paste together the rand() returns. I prefer to use my
own pseudo random number generator. Not necessarily, because I expect better
results. It makes debugging easier, when you compare runs in different
environments (the C-library can have different implementations of rand(), and
then you cannot reproduce node counts, search trees, ...)
Regards,
Dieter
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.