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.

Hmm, have you looked at the code in optics.c that was resonsible for the
VC failures? To me it seems highly unlikely that a compiler optimization
would result in changing the order of computations there. And if it does,
then inlining gg_normalize_float does not look so unlikely either.
(Of course, gcc doesn't inline because we don't tell him to.)

Btw Trevor, what processor is your VC built running on?

> Interestingly, there is a somewhat unexpected solution to the problem
> of consistently ordering presumably equal floating point numbers.
(...)
> 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.

That sounds cute, and in fact I find it aesthetically a lot more pleasant
to depend on the random seed than to depend on the orientation.

Arend