Some operations wouldn't make much sense with Float, for instance the 'complement' function. What should it return? Also note that bit manipulation functions could cover only a small window of the value range. So it could happen that x .|. y = x, even though y is nonzero. Also rotation would be a destructive operation.

Perhaps I can illustrate this with an example. It's very common with SSE code to interpret a float as both a mask and a number. You can exchange the two freely. For instance, in c-like pseudo code, you can write: float mask = myval == 0 ? 0x00000000 : 0xffffffff float temp = 5 / myval float result = mask .&. temp Which returns 0 or the result of 5 / myval. Each line above turns into a single sse instruction, and there are no branches. Bit wise operations on Floats should operate as if you had reinterpreted the Float as an unsigned integer. There are plenty of other examples of bit twiddling floats. Floats have a well defined bit representation (if a slightly complex one) so it's perfectly reasonable to be able to manipulate it. A complement operation on a float returns a float, and is well defined, if the output bit pattern is one you want. An alternative way to model this would be to provide ways to reinterpret a float as a word32, which helps enforce static typing. I don't know of any way of doing this in Haskell though. Does that make more sense? Thanks, Sam

On 15:32 Fri 09 Jul , Sam Martin wrote:

There are plenty of other examples of bit twiddling floats. Floats have a well defined bit representation (if a slightly complex one) so it's perfectly reasonable to be able to manipulate it.

Note that the Haskell report does not require IEEE 754 binary encodings. In fact, it permits 'Float' to be a decimal floating point type. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

On 22:02 Sat 10 Jul , Sam Martin wrote:

...

Note that the Haskell report does not require IEEE 754 binary encodings. In fact, it permits 'Float' to be a decimal floating point type.

True. Although I don't really understand why? Or rather, I don't understand why it can't be at least slightly more specific and at least state that Float is a 32-bit floating point value and Double is a 64-bit floating point value. The exact handling of various exceptions and denormals tends to vary across hardware, but this at least allows you to get at the representation.

Because this precludes efficient Haskell implementations on platforms which do not support these formats in hardware (but might support other formats). Also, there are other problems if the Float and Double types do not match the corresponding types of the system's C implementation.

I realise it'll be platform-specific (assuming isIEEE returns false), but then so is the behaviour of your code if you don't require IEEE support.

IEEE 754 defines five "basic" floating point formats: binary32: 24 bits precision and a maximum exponent of 127. binary64: 53 bits precision and a maximum exponent of 1023. binary128: 113 bits precision and a maximum exponent of 16383. decimal64: 16 digits precision and a maximum exponent of 384. decimal128: 34 digits precision and a maximum exponent of 6144. Each of these formats has a specific binary representation (with the lovely storage hacks we all know and love). Additionally, there are two more interchange formats which are not intended for use in arithmetic: binary16: 11 bits precision and a maximum exponent of 15. decimal32: 7 digits precision and a maximum exponent of 96. Furthermore, there are so-called "Extended" and "Extensible" formats, which satisfy certain requirements of the standard, but are permitted to have any encoding whatsoever. A Haskell implementation tuned for development of financial applications would likely define Float as the decimal64 format, and Double as the decimal128 format. isIEEE would return True since these types and related operations conform to the IEEE floating point standard. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)