You must do a signed compare unless you ensure that all the original values were positive. You must use an integer type that is the same size as the original floating point type. Each chip may have a different internal format, so comparing values from different chips as integers is most likely to give misleading results.
Most float formats look something like this: sxxxmmmm
s
is a sign bit
xxx
is an exponent
mmmm
is the mantissa
The value represented will then be something like: 1mmm << (xxx-k)
1mmm
because there is an implied leading 1
bit unless the value is zero.
If xxx < k
then it will be a right shift. k
is near but not equal to half the largest value that could be expressed by xxx
. It is adjusted for the size of the mantissa.
All to say that, disregarding NaN
, comparing floating point values as signed integers of the same size will yield meaningful results. They are designed that way so that floating point comparisons are no more costly than integer comparisons. There are compiler optimizations to turn off NaN
checks so that the comparisons are straight integer comparisons if the floating point format of the chip supports it.
As an integer, NaN
is greater than infinity is greater than finite values. If you try an unsigned compare, all the negative values will be larger than the positive values, just like signed integers cast to unsigned.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…