Parsing of messages with floats and doubles does not seem to work

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Protocol buffer message with floats and/or doubles
 example:
package com.sporttrack.protobufexport;

option java_outer_classname = "PositionProtos";

message Coordinate {
    required double latitude = 1;
    required double longitude = 2;
    required float altitude = 3;
}

2. Create message (I do it with a Java application)
3. Parse the message

I expect to see, in the Coordinate Actionscript object, fractional values
for latitude, longitude and altitude. Instead I get very large integer
values. It seems that the conversion to Number is wrong.

What version of the product are you using? On what operating system?

I'm using protobuf-actionscript3-v2.1 in Flex.

The message is also consumed by other (Java and C++) applications, where it
works ok.

Original issue reported on code.google.com by ibo...@gmail.com on 20 May 2009 at 2:44

[GoogleCodeExporter]

I've created a patch to (possibly) fix this. 

I've changed the readDouble() and readFloat() functions in
com.google.protobuf.CodedInputStream to work with floats and doubles.

The functions will just put all bytes (4 for float, 8 for double) they read 
into a
ByteArray (last read byte first etc), and call the readFloat and readDouble() 
methods
of ByteArray.

Patch is attached.

Original comment by ibo...@gmail.com on 26 May 2009 at 9:26

Attachments:

• readDoubleAndFloat.diff

[GoogleCodeExporter]

I had to make some extra changes to allow for doubles and floats to also be 
written.
The patch attached includes the changes made for reading, so the 1st patch is 
not
needed anymore.

Original comment by ibo...@gmail.com on 26 May 2009 at 10:05

Attachments:

• readAndWriteDoubleAndFloat.diff

[GoogleCodeExporter]

Is there a reason why this patch has not been incorporated other than lack of 
time?
If you need resources I am wiling to help given you add me to the project to 
commit.

Aron 

Original comment by big...@gmail.com on 5 Aug 2009 at 9:52

[GoogleCodeExporter]

Looking at the path I wonder if it would be simpler to force the input stream 
to "be" little endian.
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/IDataInput
.html#endian

By default the IDataInput assumes to be in BigEndian BUT
http://groups.google.com/group/protobuf/browse_thread/thread/5dbcc1c028f8c8bf?pl
i=1
Actual protobuffer streams are actually little endian.

Telling/forcing the IDataInput to be little endian would avoid the buffer 
copies you make an just read directly 
from the stream.

Original comment by big...@gmail.com on 6 Aug 2009 at 3:40

[GoogleCodeExporter]

I can't test if that works currently, but that seems like a simpler and better
solution than my patch.

Original comment by ibo...@gmail.com on 7 Aug 2009 at 3:24

[GoogleCodeExporter]

bigman, ibooij,

sorry for the late answer. 

the last patch I saw was replacing a BigInteger by a Number to represent a 
Double. I
don't remember from the top of my head, but I don't think that's correct: a 
Number
has only 53 bits in its mantice, so can't be used to do 64 bits operations.

Anyway, bigman, you seem to have a better idea, so feel free to provide a 
patch. I
will also digg in the Google code doc, and see to provide you a branch.

Thanks,
Philippe.

Original comment by sorrydevil@gmail.com on 19 Aug 2009 at 6:38

[GoogleCodeExporter]

Philippe, you're most probably right on the BigInteger-Number issue, so please 
just
disregard my patch.

The company I worked for is not using the code in production, so the patch being
wrong is not an issue for them.

cheers,
Ilja

Original comment by ibo...@gmail.com on 19 Aug 2009 at 7:47

[GoogleCodeExporter]

Original comment by sorrydevil@gmail.com on 13 Oct 2009 at 12:09

• Changed state: Invalid

[GoogleCodeExporter]

I have experienced the same. (and the patch works for reading)

I am wondering how to force the IDataInput to be little endian. I allready set 
all incomming data to be little endian, as I had the same problem reading int 
as they came in from the stream. Tried it lots of other places as well but with 
no result.

Has this been intergrated with the current code.

Original comment by c...@reto.dk on 21 Mar 2012 at 10:37