[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Petch
Subject: Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?
Date: Tue, 01 Sep 2009 03:18:24 -0600
User-agent: Microsoft-Entourage/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]