Carl R. Witty
27 Aug 2001 13:25:30 -0700
Stefan Maierhofer <email@example.com> writes:
> At first I thought that my shifting operation would cancel out small values
> i.e. (3 >> 4) == (7 >> 5)
> but this not the case because we are interpreting IEEE single precision
> floating point representations as ints. Since IEEE floating point
> representation stores the exponent in bits 23-30 (bit 31 is sign, and bits
> 0-22 mantissa) no problems arise here (since even for small numbers bits will
> be set to 1 in the exponent and therefore cannot be "shifted out" (because
> maximum shift is 5 bits)
> so IMHO it will not matter if some components contribute "less"
I don't think the order of the fields within a floating point number
is guaranteed anywhere, even if it happens to match the above on the
x86. I don't know if the bit ordering changes in practice, but if so,
the code might not work as well as you would hope on non-x86 machines.