[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Floating point arithmetics

From: Arend Bayer
Subject: Re: [gnugo-devel] Floating point arithmetics
Date: Thu, 16 Sep 2004 21:37:14 +0200 (CEST)

> I rapidly concluded that there must be an underlying problem with the
> connection code. And I strongly suspected floating point arithmetics.

> After some debugging, I could spot a location where things could (and
> actually do) go wrong, in the ENQUEUE() macro. The first comparison
> involves values which haven't been normalized, with the consequence that
> the delta, vulnerable1 and vulnerable2 fields might (or might not) get
> overwritten, leading to possible variations in the further processing
> of the queue.

> point one (well, sort of). So I wrote a simple patch, just replacing
> float declarations by int ones, and scaling all the constants by 10000
> (smallest constant found in the ENQUEUE_STONE() macro).

I think for 3.6, we should rather accept the platform dependency. While
the patch is probably obvious, it is still big, and I feel a little
unsafe about adding it so shortly before 3.6. (But that is just my

> * Positive
>   break_in:100    FAIL 1 D9 [0]
>   nngs:1280       PASS D13 [D13]
>   connect:70      PASS 0 [0]
>   global:1        PASS B3 [B3]

> * Negative
> - Performance impact is heavy : +2% or so in reading nodes, 
>                                 +5.7% connection nodes,
>                                 timing around +5% (imprecise)

Did you try replacing some ">" by ">="? 

Personally, I prefer the fixed point arithmetics as you wrote them (over
adding tons of "+0.0001" etc.). I did similar for the SPEC branch
at that time; I remember some reservations from Gunnar about putting it
to mainline.

Since spread_connection_distances() itself is sometimes very prominent on
profiles, it would also be good to know how its performance alone is
affected by using floats/ints. (I can test this if profiling is a hassle
on your side.)


reply via email to

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