On Tue, Sep 1, 2009 at 10:16 AM, Michael Petch
<address@hidden> wrote:
I began reviewing cache.c and have a major concern that 4 ply exceeds our
ability to represent a cache key uniquely. I am thinking out loud here, so
anyone can correct me. Eval.c has this:
/*
* Bit 00-01: nPlies
* Bit 02 : fCubeful
* Bit 03-10: rNoise
* Bit 11 : fMove
* Bit 12 : fUsePrune
* Bit 13-17: anScore[ 0 ]
* Bit 18-22: anScore[ 1 ]
* Bit 23-26: log2(nCube)
* Bit 27-28: fCubeOwner
* Bit 29 : fCrawford
*/
iKey = (
( nPlies ) |
( pec->fCubeful << 2 ) |
( ( ( (int) ( pec->rNoise * 1000 ) ) & 0x00FF ) << 3 ) |
( pci->fMove << 11 ) );
Clearly nPlies is forced to the 2 low bits.
Whoops, this is bad!
However, why the heck do we have 8 bits for storing the noise? Can't we rather have a key that is, say 5 bit for the plies and no bits what so ever for noise.
Then for evaluations with noise we should not cache anything at all, in my opinion. Retrieving cached values when using noise seems to me like something of more academic interest and studies.
My suggested solution becomes:
if ( pec->rNoise ) Do not add eval to cache.
if ( pec->rNoise ) Do not lookup cache for eval.
Doesn't that solve it?
-Øystein