I by pure coincidence was fixing a bug in some code in GHC that
involved converting a Haskell float into a hex IEEE form, this is how
its done in the code, just to add another way :)
castDoubleToWord8Array :: STUArray s Int Double -> ST s (STUArray s Int Word8)
castDoubleToWord8Array = castSTUArray
doubleToBytes :: Double -> [Int]
doubleToBytes d
= runST (do
arr <- newArray_ ((0::Int),7)
writeArray arr 0 d
arr <- castDoubleToWord8Array arr
i0 <- readArray arr 0
i1 <- readArray arr 1
i2 <- readArray arr 2
i3 <- readArray arr 3
i4 <- readArray arr 4
i5 <- readArray arr 5
i6 <- readArray arr 6
i7 <- readArray arr 7
return (map fromIntegral [i0,i1,i2,i3,i4,i5,i6,i7])
)
The nice thing about this code is it is pure Haskell and doesn't
involve using any unsafe methods. You do have to handle the platform
endianess with this method though while for the others you don't.
On 22 September 2010 05:59, Daniel Fischer <daniel.is.fisc...@web.de> wrote:
> On Tuesday 21 September 2010 21:35:21, John Millikin wrote:
>> Oh, I misunderstood the question -- you're asking about architectures
>> on which floating-point and fixed-point numbers use a different
>> endianness?
>
> Basically, I wanted to know whether there are such beasts (apparently yes)
> and if, whether they're numerous enough to worry about (apparently no).
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
