On Wed, Apr 18, 2007 at 09:12:30PM -0700, David Roundy wrote:
I just want to read in a file full of Doubles (written in binary format
from C++)
Note that if you write double's from C++ then you need to read CDoubles
in Haskell and then realToFrac them (which will presumably be optimised
out
On Tue, Apr 17, 2007 at 11:42:40PM -0400, Brian Alliet wrote:
Perhaps we just don't care about ARM or other arches where GHC runs that
Are there really any architectures supported by GHC that don't use IEEE
floating point? If so GHC.Float is wrong as isIEEE is always true.
The one most
On Sun, Apr 22, 2007 at 10:43:23PM +0100, Ian Lynagh wrote:
On Tue, Apr 17, 2007 at 11:42:40PM -0400, Brian Alliet wrote:
Perhaps we just don't care about ARM or other arches where GHC runs that
Are there really any architectures supported by GHC that don't use IEEE
floating point?
On Sun, Apr 22, 2007 at 10:36:17PM +0100, Ian Lynagh wrote:
On Wed, Apr 18, 2007 at 09:12:30PM -0700, David Roundy wrote:
I just want to read in a file full of Doubles (written in binary format
from C++)
Note that if you write double's from C++ then you need to read CDoubles
in Haskell
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
Duncan Coutts wrote:
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.
Speaking for myself, I certainly didn't realise you were
On Thu, 2007-04-19 at 12:23 +0100, Jules Bean wrote:
Duncan Coutts wrote:
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.
On Wed, Apr 18, 2007 at 12:34:58PM +1000, Duncan Coutts wrote:
We can't actually guarantee that we have any IEEE format types
available. The isIEEE will tell you if a particular type is indeed IEEE
but what do we do if isIEEE CDouble = False ?
All the computer architectures I've ever used had
On Wed, 2007-04-18 at 08:30 -0700, David Roundy wrote:
On Wed, Apr 18, 2007 at 12:34:58PM +1000, Duncan Coutts wrote:
We can't actually guarantee that we have any IEEE format types
available. The isIEEE will tell you if a particular type is indeed IEEE
but what do we do if isIEEE CDouble =
On Wed, 2007-04-18 at 08:34 -0700, Bryan O'Sullivan wrote:
Duncan Coutts wrote:
I'm currently exploring more design ideas for Data.Binary including how
to deal with alignment. Eliminating unnecessary bounds checks and using
aligned memory operations also significantly improves
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
Hi all,
I'm wondering what exactly inspired the decode/encodeFloat implementation
for Data.Binary? It seems to me like it'd be much better to use a standard
format like IEEE, which would also be much more efficient, since as far as
I know, on every implementation a Double and a CDouble are
On Tue, Apr 17, 2007 at 10:32:02AM -0700, David Roundy wrote:
I'm wondering what exactly inspired the decode/encodeFloat implementation
I kind of wondered the same thing when I first saw it. Looks like it
was just the quickest way to get it going.
Are there any suggestions how I could use
On Tue, Apr 17, 2007 at 02:50:14PM -0400, Brian Alliet wrote:
I threw together a somewhat portable longBitsToDouble function a
while ago for another project.
http://darcs.brianweb.net/hsutils/src/Brianweb/Data/Float.lhs
It doesn't depend on any unsafe operations or external ffi functions
On Tue, Apr 17, 2007 at 12:18:29PM -0700, David Roundy wrote:
machine ghc run on). It might not be fast enough for you though as it
still goes via Integer in the conversion.
It seems like this conversion shouldn't take any time at all, and we ought
to be able to just copy the memory right
On Tue, 2007-04-17 at 10:32 -0700, David Roundy wrote:
Hi all,
I'm wondering what exactly inspired the decode/encodeFloat implementation
for Data.Binary? It seems to me like it'd be much better to use a standard
format like IEEE, which would also be much more efficient, since as far as
I
On Wed, Apr 18, 2007 at 12:34:58PM +1000, Duncan Coutts wrote:
We'd like to use IEEE format as the default Data.Binary serialisation
format for Haskell's Float and Double type, the only thing that makes
this tricky is doing it portably and efficiently.
You should note that your current method
17 matches
Mail list logo
