Yes, the noise doesn't represent all 1000 they'd have to use a divisor of 8 (Shift right 3) to represent all values between 1 and 1000 in 8 bits (And then only allow noise that is multiples of 8 to be set). Basically, this code is buggy as it is, likely not many people care if there is no caching with noise.
I¹m in agreement (Both Jon and Oystein) with not caching for noisy evals and skipping the each lookup if there is noise. Then use 1 or 2 of the extra bits for more plies (1 would give us 8 plies and 2 16 plies). 16plies would likely be sufficient for a very long time. As for the reduction code, removing it would simplify the code and people can always go back in CVS to retrieve the old code pre-removal (We could tag it). If someone says "keep the noise in caching" then we could reuse the noise bits in the reduction code as well. On 01/09/09 3:01 AM, "Jonathan Kinsey" <[email protected]> wrote: > > I'm not too sure about the noise part of the key either: > >> ( ( ( (int) ( pec->rNoise * 1000 ) ) & 0x00FF ) > > this will store 0.000 to 0.256, anything higher will get ignored. > > I think we can just skip the cache for any noisy evaluations (it's skipped > already for non-deterministic ones). In general the only noisy evals are for > 0-ply player settings so I'm guessing this is largely unused anyway? > > Jon > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
