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<[email protected]> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-gnubg > > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
