On Tuesday 21 September 2010 07:11:24, Conrad Parker wrote: > On 21 September 2010 12:18, John Millikin <jmilli...@gmail.com> wrote: > > On Mon, Sep 20, 2010 at 03:22, Daniel Fischer <daniel.is.fisc...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
