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
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
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
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
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
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 =
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