arend_1_34.1: Re: [gnugo-devel] 3.1.33 VC inconsistencies

[Arend Bayer]

On Sat, 20 Apr 2002, Trevor Morris wrote:

> I've noticed one thing so far that's odd.  Namely, aa_attackpats.c is 
> different
> btw. VC & cygwin builds.  You can see the VC version at:
>   
> http://www.public32.com/pcolon/builds/gnugo/2002-4-19/gnugo/patterns/aa_attackpat.c
> 
> The only other files that differ are eyes.c and the joseki files, but I 
> believe
> this is CR/LF differences only.  The differences in aa_attackpat.c look
> substantive.

I've done a quick web search, and it seems that for "release builds" (which
Trevor is using IIRC) the VC compiler will inline functions if they seem
suitable. (See 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.Ob.asp
 )

Then gg_normalize_float may well get inlined. As Gunnar pointed out
correcting my floating point remarks, this function may no longer be safe
in this case.

This could explain the differences in aa_attack_pats.c, and although I
couldn't quite parse the file, the diff seems to come from choosing
different anchors. It should be corrected by the patch below.

Are you sure that there were no differences in owl_*pat.c? I get a different
sorting in the list of patterns if I break at the same point. 
This can have 2 reasons:
 * DFA matching found the patterns in a different order, most likely by
   a different database.
 * There might be some problem in the sorting in get_next_move_from_list;
   this does also use comparisons between identical floating point numbers.
   However, there is absolutely no computations done with these -- apart
   from a nonsense (int) conversion which is also eliminated in the
   patch below.


Btw, as I see it there are 2 reasons to worry about platform dependencies:
 1. They might be caused by bugs.
 2. They are annoying for us when tuning against regressions.

However, if we have eliminated 1., I don't think they are a problem for
the stable release. In other words, in case this patch resolves the
VC inconsistencies, I don't actually see the need to apply it before 3.3
(and I would feel safer not to be responsible for such a very-last-minute
change...).


Arend


 - another try to address "choose best anchor"-platform dependency 
 - bogus (int) conversion removed in get_next_move_from_list

Index: engine/owl.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/owl.c,v
retrieving revision 1.82
diff -u -r1.82 owl.c
--- engine/owl.c        11 Apr 2002 19:52:05 -0000      1.82
+++ engine/owl.c        20 Apr 2002 16:38:43 -0000
@@ -2966,7 +2966,7 @@
     /* Maybe we already know the top entry (if previous call was ended
      * by a value cutoff.
      */
-    top_val = (int) list->pattern_list[top].pattern->value;
+    top_val = list->pattern_list[top].pattern->value;
     if (top >= list->ordered_up_to) {
       /* One bubble sort iteration. */
       for (bottom = list->counter-1; bottom > top; bottom--)
@@ -2979,7 +2979,7 @@
       list->ordered_up_to++;
     }
     matched_pattern = list->pattern_list[top];
-    if (top_val < cutoff) {
+    if (top_val < (float) cutoff) {
       list->ordered_up_to = top + 1;
       list->used = top;
       sgf_dumptree = save_sgf_dumptree;
Index: patterns/mkpat.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/patterns/mkpat.c,v
retrieving revision 1.69
diff -u -r1.69 mkpat.c
--- patterns/mkpat.c    19 Apr 2002 20:22:22 -0000      1.69
+++ patterns/mkpat.c    20 Apr 2002 16:38:54 -0000
@@ -852,24 +852,19 @@
     /* Try to find a better anchor if
      * the -m option is set.
      */
-    float mi, mj; /* middle */
-    float d, min_d = 361.0;
+    int mi, mj; /* middle */
+    int d, min_d = 36100;
     int k, min_k = -1;
       
     /* 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;
+    mi = (maxi - 1) * 50;
+    mj = (maxj - 1) * 50 - 1;
     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);
+       d = gg_abs(100 * elements[k].x - mi)
+         + gg_abs(100 * elements[k].y - mj);
        if (d < min_d) {
          min_k = k;
          min_d = d;