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

[Arend Bayer]

On Tue, 16 Apr 2002, Gunnar Farneback wrote:

> Arend wrote:
> > 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)?
> 
> This is probably a question of evaluation order. Unless the compiler
> is so aggressively optimizing code that it inlines gg_normalize_float()
> and significantly reorders its operations, I think the function is
> safe enough.

An explanation might actually be that the second value has been stored to
memory in mean time, while the first one is still directly available in the
registers of the processor. There it is stored with higher precision and
might _not_ get rounded to float before the comparison.

I see two good (i.e., 3.3.x) solutions to all these floating point
nightmares:
1. Replace all comparisons "x > y" with "x > y + EPSILON" with suitably
   defined EPSILON. This would be the standard way to do comparisons
   actually.
2. Don't use floating point (and integers instead) where it is unnecessary. 

I guess 2. could apply to all uses of floats in GNU Go.

Arend