Am 03.05.2005 um 05:19 schrieb Tim Rowledge:

> Minor problem with this when 64bitting it.
>
> There is a loop that tries to quickly check for any zero values by  
> extracting
> the floats as plain ints and comparing with (int)0. So far as I can  
> work out
> from webpages purporting to explain the IEEE float standard this  
> misses out
> half the possible 0 values since the S bit can be 0 or 1.
>
> Is there anybody out there with a good grip on the IEEE stuff that  
> can confirm,
> deny, explain this? The code in question is (the C code generated,  
> that is):-
>
>     rcvrPtr = ((float *) (interpreterProxy->firstIndexableField 
> (rcvr)));
>
>     /* Check if any of the argument's values is zero */
>
>     argPtr = ((float *) (interpreterProxy->firstIndexableField(arg)));
>     for (i = 0; i <= (length - 1); i += 1) {
>         if ((longAt(argPtr + i)) == 0) {
>             return interpreterProxy->primitiveFail();
>         }
>     }
>

The sole purpose of existence for FloatArrays is to gain speed for  
real-time calculations. So we take speed over correctness any time  
here. I'd even recommend compiling the FloatArray plugin with --ffast- 
math, which violates IEEE anyway. Someone might want to explore  
enabling all the auto-vectorization goodness GCC supports nowadays  
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html).

IMHO testing for (int 0) is fine because accuracy does not matter  
here. It might or might not counteract the compiler's ability to  
optimize the loop using vector expressions.

OTOH, we gain so much by using FloatArrays at all that the  
correctness penalty might not be measurable - so doing it correct  
wouldn't hurt either. But all bets are off until someone actually  
measures this, for example in Croquet.

- Bert -