[
https://issues.apache.org/jira/browse/THRIFT-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022792#comment-15022792
]
Tom Lippincott commented on THRIFT-3433:
----------------------------------------
It looks like when building a compact double, Haskell uses doubleBE, and when
parsing one, it uses bsToDouble, which assumes big endian input, and checks the
local machine's ordering for whether it needs to swap it to little endian (see
the def of bsToDouble in Protocol.hs). It says big endian is "network order",
which I guess Thrift...doesn't use? I think the fix is pretty straightforward
in either case, but I'd rather someone more familiar and capable of verifying
all of this do it...
> Doubles aren't interpreted correctly
> ------------------------------------
>
> Key: THRIFT-3433
> URL: https://issues.apache.org/jira/browse/THRIFT-3433
> Project: Thrift
> Issue Type: Bug
> Components: Haskell - Library
> Affects Versions: 0.9.3
> Reporter: Tom Lippincott
>
> When reading in a string-to-double map from the identical file using the
> Compact protocol, Python gives the correct values:
> ...
> u'roh': -12.012431158160835
> ...
> but Haskell is totally off:
> ...
> ("roh",6.355136015066463e-157)
> ...
> The funny thing is, if I read it into Haskell (and the numbers are all off),
> then write it out to another file, that file still has correct numbers when
> loaded into Python. So it seems that the raw information is being
> (de)serialized correctly at the bit-level, but Haskell isn't interpreting it
> as a double the same way as Python...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
