At 23:42 +0100 1/15/13, Nick Wellnhofer wrote:
>This function is quite obviously wrong:
>
> PARROT_PURE_FUNCTION
> static int
> auxcmpfunc(ARGIN(const FLOATVAL *i), ARGIN(const FLOATVAL *j))
> {
> ASSERT_ARGS(auxcmpfunc)
> return (int) (*i - *j);
> }
>
>You can't just cast a floating-point difference to integer and expect it would
>do the right thing. Every result between -0.5 and 0.5 will result in a zero
>integer meaning equality although the values compared are in fact different.
>Something like that should work:
>
> if (*i == *j) return 0;
> if (*i < *j) return -1;
> else return 1;
>
>On another note, the line "ASSERT_ARGS(auxcmpfunc)" is useless. auxcmpfunc
>will always be non-null.
>
Back in the days of Control Data floating point one could get far better speed
by taking advantage of the fact that a 48 bit integer with the same bit pattern
of a float was bigger than, smaller than, or equal to another bit pattern which
is really another float.
In C that kind of thing would have been a union but assembly was the real
language at the time. FORTRAN didn't have any numbers after it.
Normalized IEEE floats exhibit the same characteristic and the comparison will
work in 64 bits if the commands provided on the processor chip can get the
floats into registers than can be compared as integers. Would the speed be any
better than floating point subtractions in hardware? - I donno.
There is also the question of just what does one mean by equality when
inequality can be an artifact of the likes of decimal to binary conversion of
fractions with a finite number of bits.
--
--> Halloween == Oct 31 == Dec 25 == Christmas <--
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
