[Mono-list] System.Drawing.Drawing2D

[Carl R. Witty]

Stefan Maierhofer <sm@dhm.at> 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.

Carl Witty