Re: [gnugo-devel] Floating point arithmetics

[Arend Bayer]

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

> * 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 s.th. 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.)

Arend