Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies

[Gunnar Farneback]

I wrote:
> On Cray I have so far an unexpected pass for nngs1:45. I'll try to
> track that one down.

This seems to be another variation of the floating point ordering
problem. In mkpat.c we have some code to optimize the anchor point:

    mi = ((float)maxi - 1.0) / 2.0;
    mj = ((float)maxj - 1.0) / 2.0 - 0.01;
    for (k = 0; k != el; k++)
      if (elements[k].att < 3 && (elements[k].att & anchor) != 0) {
        d = gg_abs((float)elements[k].x - mi)
          + gg_abs((float)elements[k].y - mj);
        if (d < min_d) {
          min_k = k;
          min_d = d;
        }
      }

Due to the 0.01 offset the numbers become inexactly represented and we
get the platform dependency potential. The patch below fixes this with
a gg_normalize_float() call, but the real question is why we have this
offset at all.

/Gunnar

Index: patterns/mkpat.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/patterns/mkpat.c,v
retrieving revision 1.66
diff -u -r1.66 mkpat.c
--- patterns/mkpat.c    31 Mar 2002 20:46:47 -0000      1.66
+++ patterns/mkpat.c    18 Apr 2002 19:08:45 -0000
@@ -855,14 +855,20 @@
     float d, min_d = 361.0;
     int k, min_k = -1;
       
-    /* we seek the element of suitable value minimizing
-     * the distance to the middle */
+    /* We seek the element of suitable value minimizing
+     * the distance to the middle.
+     *
+     * FIXME: What's the purpose of this 0.01 offset? It introduces
+     * potential for platform dependency in the floating point
+     * calculations.
+     */
     mi = ((float)maxi - 1.0) / 2.0;
     mj = ((float)maxj - 1.0) / 2.0 - 0.01;
     for (k = 0; k != el; k++)
       if (elements[k].att < 3 && (elements[k].att & anchor) != 0) {
        d = gg_abs((float)elements[k].x - mi)
          + gg_abs((float)elements[k].y - mj);
+       d = gg_normalize_float(d, 0.01);
        if (d < min_d) {
          min_k = k;
          min_d = d;