[
https://issues.apache.org/jira/browse/THRIFT-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014286#comment-15014286
]
Jens Geyer edited comment on THRIFT-3433 at 11/19/15 8:19 PM:
--------------------------------------------------------------
The byte order is wrong. Interpreting the first double as bytes and swapping
all bytes leads me exactly to the second number:
{code}
before -1.20124311581608E+0001
after 6.35513601506646E-0157
{code}
was (Author: jensg):
The byte order is wrong. Interpreting the byte order of the first double leads
me to the second:
{code}
before -1.20124311581608E+0001
after 6.35513601506646E-0157
{code}
> 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)