gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies


From: Trevor Morris
Subject: Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies
Date: Tue, 16 Apr 2002 09:56:56 -0400

This patch solves these 5 VC-related dependencies.  Good work, Arend!
Note that this is compiler-dependent, as the cygwin build (running on the
same machine) did not have the failures that the VC build did.

-Trevor

At 02:34 PM 4/16/2002 +0200, Arend Bayer wrote:


>> Trevor wrote:
>> > ./regress.sh . trevora.tst
>> > 140 unexpected FAIL: Correct 'G4', got 'D4'
>> > ./regress.sh . lazarus.tst
>> > 6 unexpected FAIL: Correct 'H3', got 'H2'
>> > ./regress.sh . nngs.tst
>> > 770 unexpected FAIL: Correct '!K2', got 'K2'
>> > ./regress.sh . trevorc.tst
>> > 350 unexpected FAIL: Correct 'E3', got 'J4'
>> > ./regress.sh . global.tst
>> > 14 unexpected FAIL: Correct 'S9', got 'E1'
>> 
>> Dan wrote:
>> > Interesting that they're all failures.
>
>So this clearly shows the gcc-people have a better understanding of go than
>Microsoft :-)
>
>Now seriously:
>
>Trevor wrote:
>> >gnugo --quiet -a -w -t -d0xa -l games/trevor/auto/a005.sgf -L 12 
>> >--decide-dragon C4 -o vars.sgf
>> >
>> Here's the output from this command:
>>   http://www.public32.com/games/go/trevora.140.sgf
>>   http://www.public32.com/games/go/trevora.140.out
>> 
>
>Thanks. The problem is that two different "marginal eye space"-moves are
>tried by owl (at variation 75, stack B:B5 W:B3 B:B2 W:C2).  Looking 
>around for suspicious code quickly leads to the loop starting in line
>optics.c:912 that tries to determine the best attack/defense point. It seems
>to me that is is suspect to similar floating point numbers problem that made
>Gunnar introduce gg_normalize_float. (The value of both attack points
>gets computed as 1.0 - 0.1.)
>
>Looking again at gg_normalize_float, I am not really sure that this function
>can reliably solve the problems. Why should we safely assume that
>        90*0.01 - 90*0.01
>gets computed as equal to zero, if we cannot assume this for
>        (1.0-0.1)-(1.0-0.1)?
>
>In other words, I think its not true for all systems (i.e. processors)
>that the error in floating point computations is completely deterministic.
>But I don't really know and if someone has more reliable knowledge on that
>I'd be happy to read about it.
>
>The patch below is a proposoal to fix this. It would have to be tried out
>on Trevor's VC built (note that this may well depend on the processor, not the
>compiler) to see whether it solves the problem.
>
>Arend
>
>
> - new function gg_normalize_float2int to address optics.c-platform dependency 
>
>Index: engine/optics.c
>===================================================================
>RCS file: /cvsroot/gnugo/gnugo/engine/optics.c,v
>retrieving revision 1.40
>diff -u -r1.40 optics.c
>--- engine/optics.c     7 Mar 2002 05:35:28 -0000       1.40
>+++ engine/optics.c     16 Apr 2002 12:29:48 -0000
>@@ -26,6 +26,7 @@
> #include <string.h>
> #include "liberty.h"
> #include "eyes.h"
>+#include "gg_utils.h"
> 
> 
> /* This macro is not fully generalized. It works because it is used only where
>@@ -934,7 +935,8 @@
>        else
>          continue;
>        
>-       if (this_score > score) {
>+       if (gg_normalize_float2int(this_score, 0.01)
>+           > gg_normalize_float2int(score, 0.01)) {
>          best_attack_point = this_attack_point;
>          best_defense_point = this_defense_point;
>          score = this_score;
>Index: utils/gg_utils.c
>===================================================================
>RCS file: /cvsroot/gnugo/gnugo/utils/gg_utils.c,v
>retrieving revision 1.24
>diff -u -r1.24 gg_utils.c
>--- utils/gg_utils.c    25 Mar 2002 21:23:47 -0000      1.24
>+++ utils/gg_utils.c    16 Apr 2002 12:30:43 -0000
>@@ -338,6 +338,12 @@
>   return a * ((int) (0.5 + x / a));
> }
> 
>+int
>+gg_normalize_float2int(float x, float a)
>+{
>+  return ((int) (0.5 + x / a));
>+}
>+
> /* A sorting algorithm, call-compatible with the libc qsort() function.
>  *
>  * The reason to prefer this to standard qsort() is that quicksort is
>Index: utils/gg_utils.h
>===================================================================
>RCS file: /cvsroot/gnugo/gnugo/utils/gg_utils.h,v
>retrieving revision 1.9
>diff -u -r1.9 gg_utils.h
>--- utils/gg_utils.h    25 Mar 2002 21:23:47 -0000      1.9
>+++ utils/gg_utils.h    16 Apr 2002 12:30:43 -0000
>@@ -63,6 +63,7 @@
> double gg_cputime(void);
> 
> float gg_normalize_float(float x, float a);
>+int gg_normalize_float2int(float x, float a);
> void gg_sort(void *base, size_t nel, size_t width,
>             int (*compar)(const void *, const void *));
> 
>
>
>_______________________________________________
>gnugo-devel mailing list
>address@hidden
>http://mail.gnu.org/mailman/listinfo/gnugo-devel 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]