|
From: | Jonathan Kinsey |
Subject: | Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem? |
Date: | Tue, 1 Sep 2009 09:21:41 +0000 |
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 > > > > 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 > address@hidden > http://lists.gnu.org/mailman/listinfo/bug-gnubg View your other email accounts from your Hotmail inbox. Add them now. |
[Prev in Thread] | Current Thread | [Next in Thread] |