🚀 go-pugleaf

Dan Oetting wrote:
> 
> Saving a permanent pawn hash on disk would work if the pawn hash table
> is large enough to hold every possible pawn configuration. Or if the
> pawn evaluation is complex enough that a disk access is faster, the pawn
> evaluations could be precomputed on disk and cached in ram. I don't
> think either of these conditions hold so we will typically have a subset
> of pawn configurations evaluated in the pawn hash table and recompute
> new configurations as needed.

I did try saving the pawn cache to disk on exit, read on
start, not clearing between games. The results seemed
slightly positive (IIRC), but you do end up having to manage
more files, and if you change what is cached then you have
to scrub these files, and of course vast chunks of free disk
space.

NB: In 5.02 I think there is a mistake in the pawn hash
score saved, as the outside pawn bonus is cached, but it
depends on the position of pieces rather than just pawns,
probably not important if you don't save the pawnhash
between games as it only is added in the endings.

I also hunted for decling returns with the pawn hash - one
would expect as the size of the pawn hash approaches the
number of likely pawn positions the collision rate would
tend to zero, and the benefits of extra space would tale
off. I guess my estimates for the number of likely pawn
formations in chess were way too optimistic.

> In the later versions of Gnu Chess 4.0 I had implemented transposition
> aging so that the transposition table did not need to be cleared between
> moves. Without aging, the hash table would eventually be filled with
> unreachable positions from previous moves making hash hits less likely
> and the damage from hash collisions more severe. Aging has not been
> carried into Gnu Chess 5 yet.

Is there a better explanation of this than the gnuchess4
source code? I need to get my hand into some real coding,
rather than just fiddling around the edges.

How big a difference did this make to gnuchess 4?
 
> If you use short time controls you may want to limit the size of the
> hash table since the time to clear the table before each move can be
> significant.

Oh - hadn't thought of that - I'll check out my timings.

All this talk of saving between moves got me thinking,
especially as I have been looking carefully at "sort" after
I discovered some minor tweaks to the program had huge
repercussions through minor changes to the move ordering.

Should I expect changes to SortRoot to have much effect? I
tried changing it to reflex the comments (it doesn't have
some stuff that the normal move sort has for no obvious
reason), and the results were promising but inconclusive -
same test scores in same time, 5% less Nodes examined (I'd
hoped it would find some more solutions, but it just found
the same ones with less effort AFAICT.)

The handling of "history" in 5.02 seems slightly irrational,
and deleting it from the code base entirely appears to have
minimal effect (In some previous testing deleting it had a
positive score!).

I think it is irrational as the ultimate value stored is
unbound and determined by the depth to which the code
searches, and the number of times a move is ranked as
"best". 

Thus when it is used to determine move ordering it may
easily become more important than other factors (Like taking
the opponents queen!) for reasons that are more to do with
computational speed than chess logic.

Does anyone know why HISTSCORE is defined as depth squared -
I assumed it was to encourage the testing of moves found
deeper in the search over one's found best earlier but why
this should be isn't intuitively obvious (to me it least
*8-)? i.e. If a move has proved best many times earlier in
the tree, why should I try one that has only been best once,
just because that occured further down? (Or does the maths
work out different?).

I was thinking of a scheme that bounds (normalises) the
history, and preserves history between moves with a scaled
down value (I figure maybe even just setting the value to
something between the highest centralisation bonus (5?) and
the lowest SwapOff bonus (ValueP = 100) if the history was
nonzero, should preserve enough information between moves to
encourage all the best moves to be tried after captures but
before any other moves.

Or is this just fiddling around the edges with the history?