bug-gnubg
[Top][All Lists]
Advanced

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

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


From: Massimiliano Maini
Subject: Re: [Bug-gnubg] Gnubg's Cache and Plies > 3 - problem?
Date: Tue, 1 Sep 2009 11:16:15 +0200

Isn't the reduction code the Snowie-like thing, where you can decide
to examine only a subset of the rolls ?
E.g. 50% = only consier half of the possible rolls for analysis/rollout.

If it's the case, I do think we can throw it away.

For information, my Win builds have REDUCTION_CODE  *not* defined.

MaX.

2009/9/1 Øystein Johansen <address@hidden>:
>
>
> On Tue, Sep 1, 2009 at 10:45 AM, Jonathan Kinsey <address@hidden>
> wrote:
>>
>> Note that all 32 bits are used if REDUCTION_CODE is defined. I'm not sure
>> what
>> the "reduction code" does exactly (something about reducing the number of
>> rolls
>> used in evaluations for a quicker less accurate calculation?), is it a
>> failed
>> experiment or is it actually used in general?
>
>
> It was something Nis Jorgensen came up with. I don't remember exactly how it
> worked, but it was cool enough!
> However it had to be #defined away to suite the pruning neural networks.
>
> No wait.... maybe I remember incorrectly. Maybe it was David Montgomery who
> added the reduction code and Nis who made a twist by letting some branches
> in the go n-ply and some other go (n-1) ply. I think it actually worked, at
> least when n=2.
>
>> I'm all for removing this code if it was found to have little use.
>
> Well, if someone wants  to take up this algorithm it would be interesting,
> however if someone wants that they can find the code in the cvs archives
> even if it's removed.
>
> -Øystein
>
>
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>




reply via email to

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