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

[Christian Anthon]

I believe that it is a flag to tell the algorithm that we are at the
top of the evaluation (e.g. 4ply), why it is needed and what it has to
do with the cache remains a mystery to me.

Christian.

On Wed, Sep 2, 2009 at 11:36 AM, Jonathan Kinsey<address@hidden> wrote:
> Michael Petch wrote:
>>
>>
>> On 01/09/09 10:26 PM, "Michael Petch" wrote:
>>
>>
>> On 01/09/09 5:22 PM, "Michael Petch" wrote:
>>
>> I haven’t provided the output, but I ran 0,1,2,3 plies (Same
>> filter and other settings). In those instances Cache Evals = No
>> Cached evals, which leads me to believe we still have an issue
>> with plies>3 with caching that hasn’t been discovered. I will
>> look at the code more tonight and if I see anything I’ll let
>> people know. My guess is we have missed something small
>> somewhere (I hope).
>>
>>
>> It appears we may be dealing with an optimization issue. Stay tuned.
>>
>>
>>
>> Its not optimizations. I can’t reproduce the problems now. I know there
>> is something that will cause it, I just don’t know what it was (So I am
>> positive there is a bug, I just can’t reproduce it). I am betting it has
>> to do with Pruning analysis options.
>>
>> On a side note can someone briefly explain “fTop” variable. There is an
>> inline comment in eval.c from a few years ago that fTop should be in the
>> cache but there were no available bits.
>
> Maybe it's a flag to show that it's the initial position being evaluated?
> I'm
> guessing because I haven't looked at the code in detail.
>
> Jon
>
>
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>