[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: Wed, 17 Apr 2002 02:45:43 +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.

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.


reply via email to

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