Releasing 5.0.0 today, maybe with FFA.sort()

Doug McNutt douglist at macnauchtan.com
Wed Jan 16 03:25:37 UTC 2013


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  <--


More information about the parrot-dev mailing list