Re: [Bug-gnubg] Re: gnubg bug? Baseline Information

[Philippe Michel]

The changes to eval.c you committed don't help for me. I still get the 
wrong results.

On the other hand, adding the g_print() in eval.c 1.376 does indeed work 
around the problem. So does the following change :

--- eval.c.orig    2009-07-10 21:32:52.000000000 +0200
+++ eval.c      2009-08-08 20:59:46.000000000 +0200
@@ -5765,7 +5765,7 @@
       float arInput[200];

       for(i = 0; i < ml.cMoves; i++) {
-       move* const pm = &ml.amMoves[i];
+       move* const volatile pm = &ml.amMoves[i];

        PositionFromKey(anBoardOut, pm->auch);
        SwapSides(anBoardOut);


On Sat, 8 Aug 2009, Christian Anthon wrote:

> It was indeed a compiler issue. The following non-fix made the problem
> disappear for me:
>
> replace
>
>           pm->rScore = UtilityME(arOutput, pci);
>           if( i < nPruneMoves ) {
>
> with
>
>           pm->rScore = UtilityME(arOutput, pci);
>          g_print("%f\n", pm->rScore)
>           if( i < nPruneMoves ) {
>
> around line 5811 in eval.c.
>
> I attempted to fix the code. But my attempts made the code a bit
> slower or did nothing. I ended up committing something that is much
> simpler, but slightly slower than before. You are welcome to suggest
> changes and test it for speed. In particular the sorting is a bit
> overkill since we only need the 10 best pruned moves in no particular
> order. And I'm not sure that the forced inline of eval_prune is an
> advantage.