Looks like are emails crossed quite nicely, anyway I will remove the reduction
code and the noise from the cache and change the plies to 4 bits unless someone
shouts (before tonight I expect).
Jon
Øystein Johansen wrote:
>
>
> On Tue, Sep 1, 2009 at 10:16 AM, Michael Petch > 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bug-gnubg mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
_________________________________________________________________
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/167688463/direct/01/
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
