[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnugo-devel] arend_1_33.5: Try to address VC inconsistencies
From: |
Arend Bayer |
Subject: |
[gnugo-devel] arend_1_33.5: Try to address VC inconsistencies |
Date: |
Tue, 16 Apr 2002 14:34:17 +0200 (CEST) |
> 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] GNU Go 3.1.32, Daniel Bump, 2002/04/14
- Re: [gnugo-devel] GNU Go 3.1.32, Trevor Morris, 2002/04/14
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, Trevor Morris, 2002/04/15
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, bump, 2002/04/15
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, Gunnar Farneback, 2002/04/15
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, Arend Bayer, 2002/04/15
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, Trevor Morris, 2002/04/15
- [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies,
Arend Bayer <=
- Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies, Trevor Morris, 2002/04/16
- Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies, Gunnar Farneback, 2002/04/16
- Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies, Arend Bayer, 2002/04/16
- [gnugo-devel] Handtalk series update, Jessie Annala, 2002/04/17
- Re: [gnugo-devel] Handtalk series update, Daniel Bump, 2002/04/17
- Re: [gnugo-devel] Handtalk series update, David Fotland, 2002/04/17
- Re: [gnugo-devel] Handtalk series update, bump, 2002/04/17
- Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies, Trevor Morris, 2002/04/17
- Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies, Arend Bayer, 2002/04/22
- Re: [gnugo-devel] GNU Go 3.1.32 - VC inconsistencies, Gunnar Farneback, 2002/04/18