[ 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)