[Top][All Lists]

[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: Arend Bayer
Subject: Re: [gnugo-devel] arend_1_33.5: Try to address VC inconsistencies
Date: Mon, 22 Apr 2002 16:05:35 +0200 (CEST)

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
1. Replace all comparisons "x > y" with "x > y + EPSILON" with suitably
   defined EPSILON. This would be the standard way to do comparisons
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.


reply via email to

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