Author: GeoffW
Date: 03:05:51 06/05/04
Go up one level in this thread
Hello Dieter
>Same experience here. Allways replace (with a normal simple scheme, and a hash
>table, that can only store one score/bound/depth/draft per position) seems >just better,
That is interesting, I am glad you noticed the same effect, my first thought on
this was that I must have a serious bug somewhere in my code
> My explanation: you will keep
>with a depth preferred scheme some useless entries too long. Window bounds
>changed inbetween. You keep that deep lower bound entry, that is basically
>worthless with the new window bounds. An upper depth entry would be nice, and
>possibly good for a cutoff. But you have already that lower bound entry with
>deep depth, that is useless - and difficult to overwrite.
I did a very quick experiment based on your comments. I was a little unsure
though whether you meant the useless entries were the hibound or lobound, I
always find that confusing :-)
In my code
HIBOUND_FLAG means /* score >= real score (in case of fail low) */
if (((ph->flags & VALIDITY_FLAG_MASK) == VALID_FLAG) && (ph->depth > depth))
{
/* add 2 lines to stop it storing deep HIBOUND entries */
temp = (ph->flags & BOUNDS_MASK);
if (temp == HIBOUND_FLAG)
return FALSE;
}
I was trying to get less HIBOUND entries in the table to see what effect it
would have. It did make a significatnt difference, the first mod I did was no
longer seriously bad, in some test positions the above code was now better than
my original, only tested about 5 positions though. I will do a little more
experimenting today, but it does seem to suggest that my first mod caused the
table to fill up with not very useful HIBOUND entries.
>Sure, not a very scientifical description of what happens. I think, especially
My testing was even less scientific :-)
>in real games (not just test positions, and with pondering) overwrite always
>will win vs. depth preferred. Of course, there are various ideas possible (and
>certainly implemented) to have a compromise. For example, one table, that will
>be overwrite always, and another one, that will be depth preferred. In reality,
I was revisiting my code as I have just tried a 2 level system as you describe,
my first test with it showed it was horrible, much worse than my simple original
system. I could easily have some bugs in it though, I havent given up on it yet.
>Many people use the term "draft" instead of "depth", in my reasoning.
I know Bob uses that term and it confuses the hell out of me !
I always think of the search as progressing downwards, the term "draft" I think
of as the distance below the waterline. I.E the depth we have still to go in the
search, so that storing "draft" in the hash table seems wrong to me.
I hope it is just my understanding that is hazy and not my hash table code that
is completely backwards :-)
Thanks for your thoughts on this.
Regards Geoff
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.