Re: [Haskell-cafe] Re: Float instance of Data.Bits
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/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Float instance of Data.Bits
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. 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. ta, Sam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Float instance of Data.Bits
Sam Martin sam.mar...@geomerics.com wrote: Is there a particular reason Float, Double, etc do not have instances of Data.Bits in the standard libraries? I note the Haskell 2010 report doesn't include them either. In fact, I'm not actually sure how you'd implement the instance for floating point types without having some kind of compiler-specific extension, or a c-binding. Could anyone fill in my missing knowledge here? 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. Nobody would really need the operations (we have integer types and UArray Int Bool for bit manipulation), and they would most likely be very slow. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Float instance of Data.Bits
2010/7/9 Ertugrul Soeylemez e...@ertes.de: Sam Martin sam.mar...@geomerics.com wrote: Nobody would really need the operations (we have integer types and UArray Int Bool for bit manipulation), and they would most likely be very slow. They won't be slow using SSE2 or something. I can see where they could be beneficial. But I agree that those operations have semantics not compatible with Data.Bits operations. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Float instance of Data.Bits
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 ? 0x : 0x 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Float instance of Data.Bits
2010/7/9 Sam Martin sam.mar...@geomerics.com: 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 ? 0x : 0x Notwithstanding mask is compatible with float sizeof-wize you should assign it a different type so you won't accidentally return a value of 0x. It is cumbersome in C, and much more easier in Haskell. Then you specify your operations over masks and floats, bind them to SSE2 primitives and use them as you wish. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Float instance of Data.Bits
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/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
