You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Jeff Whiting (JIRA)" <ji...@apache.org> on 2009/12/09 18:19:18 UTC

[jira] Issue Comment Edited: (THRIFT-644) Doubles are not IEEE 754 when writing in the BinaryFormat

    [ https://issues.apache.org/jira/browse/THRIFT-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788167#action_12788167 ] 

Jeff Whiting edited comment on THRIFT-644 at 12/9/09 5:18 PM:
--------------------------------------------------------------

I've attached the thrift file we are using.  The values we have set for each property are as follows:

firstClick = 0.14000000000000001332267629550187848508358001708984375
lastClick = 9.25
pageSubmit = 0.520000000000000017763568394002504646778106689453125
clickCount = 43

Just for some background information, we are attempting to move away from the php serialized arrays and to thrift. I've pulled these values directly from the php serialized array we are currently using.

Honestly I don't know enough about the thrift binary format to be able to look at two different binary encodings and tell you what is going on.  

However, I have looked at the java code (TBinaryProtocol.java) and it encodes doubles using Double.doubleToLongBits and according to http://java.sun.com/javase/6/docs/api/java/lang/Double.html#doubleToLongBits%28double%29 it is using a IEEE 754 encoding. Unfortunately php pack function produces a double that is "machine dependent size and representation."  So I'm assuming the problem is that the double is being represented differently between java and php.

As far as $data variable, that is just from the function writeDouble found in TBinaryProtocol.php.  Here is the entire function for more context:

public function writeDouble($value) {
 	$data = pack('d', $value);
 	$this->trans_->write(strrev($data), 8);
 	return 8;
} 

      was (Author: whitingj):
    I've attached the thrift file we are using.  The values we have set for each property are as follows:

firstClick = 0.14000000000000001332267629550187848508358001708984375
lastClick = 9.25
pageSubmit = 0.520000000000000017763568394002504646778106689453125
clickCount = 43

Just for some background information, we are attempting to move away from the php serialized arrays and to thrift. I've pulled these values directly from the php serialized array we are currently using.

Honestly I don't know enough about the thrift binary format to be able to look at two different binary encodings and tell you what is going on.  

However, I have looked at the java code (TBinaryProtocol.java) and it encodes doubles using Double.doubleToLongBits and according to http://java.sun.com/javase/6/docs/api/java/lang/Double.html#doubleToLongBits%28double%29 it is using a IEEE 754 encoding. Unfortunately php pack function produces a double that is "machine dependent size and representation."  So I'm assuming the problem is that the double is being represented differently between java and php.
  
> Doubles are not IEEE 754 when writing in the BinaryFormat
> ---------------------------------------------------------
>
>                 Key: THRIFT-644
>                 URL: https://issues.apache.org/jira/browse/THRIFT-644
>             Project: Thrift
>          Issue Type: Bug
>          Components: Compiler (PHP)
>    Affects Versions: 0.1, 0.2, 0.3
>         Environment: PHP 5.3 - Ubuntu 9.10
> Most likely all OSes 
>            Reporter: Jeff Whiting
>         Attachments: Timing.thrift
>
>
> Steps to Repro:
> 1.  Without the PHP thrift extension serialize a struct with a double (note I haven't tested this with the php extension)
> 2. Attempt to read the struct using Java
> Results:
> Java is unable to read the double correctly
> Expected Results:
> Looking at the PHP code in TBinaryProtocol.php the function writeDouble does the following:
> $data = pack('d', $value); 
> According to the PHP documentation (http://php.net/manual/en/function.pack.php)
> 'd' is: double (machine dependent size and representation).
> The double should be IEEE 754 compliant.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.