[Haskell-cafe] question about Data.Binary and Double instance
duncan.coutts at worc.ox.ac.uk
Thu Apr 19 05:08:56 EDT 2007
On Wed, 2007-04-18 at 21:12 -0700, David Roundy wrote:
> On Thu, Apr 19, 2007 at 10:20:21AM +1000, Duncan Coutts wrote:
> > and people will for ever be defining newtype wrappers or complaining
> > that the whole library isn't parametrised by the endianness or whatever.
> > For existing formats you need much more flexibility and control. The
> > Binary class is to make it really convenient to serialise Haskell types,
> > and it's built on top of the layer that gives you full control.
> > We intend to work more on this other side of the library in the coming
> > couple of months. If you could tell us a bit more about your use case,
> > that'd be great.
> I just want to read in a file full of Doubles (written in binary format
> from C++) and print out text (into a pipe or file to be read by gnuplot).
> It's not a high-performancs use (the file is only a megabyte or so), but
> it's something that *ought* to be easy, and so far as I can tell, it
> requires tricky hackery.
Right, it should be simple.
With the api I'm hacking on at the moment you just have primitives like
(importing Data.Binary.Get as Get):
Get.word :: Get Word
Get.word8 :: Get Word8
and you'd need:
Get.double :: Get Double --IEEE double format
As you noticed, that's not a primitive which we have yet. With that it
should be really easy to get a sequence of them:
Get.run (mapM (const Get.double) [0..n]) :: Lazy.ByteString -> [Double]
> I suppose I was just disappointed, because I'd figured that the Binary
> library was there to do what I wanted. :( It was something I could have
> done in five minutes (counting tuning the gnuplot file) in perl, and it's
> embarrassing (which makes it frustrating) to fail in Haskell to complete it
> in... I couldn't say how long, an hour or so?
Yeah, we've concentrated so far on the serialisation of Haskell values,
not reading/writing externally defined binary formats. I don't think
we've been especially clear on that. But we do intend to tackle both.
More information about the Haskell-Cafe