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(); } }
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim World Ends at Ten! Pictures at 11 on Fox News!
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 -
I don't see anything that looks like an SUnit for FloatArray - this in a 3.8 #6599 or thereabouts image - should there be anything or does anyone have a test set?
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim The generation of random numbers is too important to be left to chance.
squeak-dev@lists.squeakfoundation.org