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

[Gunnar Farneback]

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.

> 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.

I think the floating point operations are sane enough to be
deterministic at the processor level at least. They are certainly not
guaranteed to be associative or distributive but I'm unsure about
commutativity. I'm almost certain that the difference of two identical
(ordinary) values is guaranteed to be zero. It might make a difference
whether the floating point numbers follow the IEEE standard or not,
but I believe anything else is rare. All this is based on only
slightly reliable knowledge though, so it might be a good idea to look
it up.


Interestingly, there is a somewhat unexpected solution to the problem
of consistently ordering presumably equal floating point numbers.
Instead of trying to force them to really be equal, one forces them to
be different! The following is an alternative implementation of
gg_normalize_float():

float
gg_normalize_float(float x, float a)
{
  return x + 0.5 * a * gg_drand();
}

It does have some problems though, so I won't propose to use it, but
the underlying idea could be used in some refined form.

/Gunnar