Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?

[Michael Petch]

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" <address@hidden> 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
>