[Haskell-cafe] ANN: ieee version 0.7

[Daniel Fischer]

On Tuesday 21 September 2010 07:11:24, Conrad Parker wrote:
> On 21 September 2010 12:18, John Millikin <jmillikin at gmail.com> wrote:
> > On Mon, Sep 20, 2010 at 03:22, Daniel Fischer 
<daniel.is.fischer at web.de> wrote:
> >> unsafeCoerce is not supposed to work for casts between Integral and
> >> Floating types. If you try to unsafeCoerce# between unboxed types,
> >> say Double# and Word64#, you're likely to get a compile failure (ghc
> >> panic). If you unsafeCoerce between the boxed types, it will probably
> >> work, but there are no guarantees.
> >>
> >> There's a feature request for unboxed coercion (i.e. reinterpretation
> >> of the bit-pattern):
> >>
> >> http://hackage.haskell.org/trac/ghc/ticket/4092
> >
> > Interesting -- in that bug report, Simon Mar says that converting the
> > value using pointers will work correctly. I've changed d-b-ieee754
> > over to use this method (v 0.4.2); the tests are still passing, so
> > I'll call it success.

And I'd expect it to be a heck of a lot faster than the previous 
implementation. Have you done any benchmarks?

>
> I've been using unsafeCoerce:
>
> getFloat64be :: Get Double
> getFloat64be =
>     do n <- getWord64be
>        return (unsafeCoerce n :: Double)
>
> putFloat64be :: Double -> Put
> putFloat64be n = putWord64be (unsafeCoerce n :: Word64)
>
> but only tested it with quickcheck -- it passes about 10^7 checks,
> comparing roundtrips in combinatrion with the previous
> data-binary-ieee754 versions. However could that sometimes behave
> incorrectly?
>
> Should the d-b-iee754-0.4.2 versions with castPtr etc. be even faster?

No, Simon says

"Not terribly efficient, but better than using the FFI."

I would expect unsafeCoerce to be the fastest you can get (so far).

From the docs of unsafeCoerce#, I get the impression that will probably 
work, but it's not listed among the cases where it's *supposed* to work, 
hence it's probably in fact a little unsafe.

One problem I see with both, unsafeCoerce and poke/peek is endianness.
Will the bit-pattern of a double be interpreted as the same uint64_t on 
little-endian and on big-endian machines? In other words, is the byte order 
for doubles endianness-dependent too?
If yes, that's fine, if no, it would break between machines of different 
endianness.

>
> Conrad.

Cheers,
Daniel