Re: Extracting IEEE 754 floating point numbers

[physgreg]

Thanks for all your replies. I tried printing out the value of 1.0, packed as a float, then unpacked in hex. I got the value 0000803f. Then I tried the same with the encoded value sent from my application, and got 3f800000. This looked like it could be the little endian/big endian problem, so I tried the suggested conversion

unpack "f*", pack "N*", unpack "V*", $_[0];

which did the trick. I have one last query - does the order of the bits matter as to whether the format qualifies as a IEEE 754 floating point number? This is quite a concern, as the application that was causing the trouble is a test suite for a particular standard (which specified IEEE 754 as the floating point format), so I don't want to code to this application if it is wrong!

Once again, thank you for all your suggestions.

[Thelonius]

Does the order of the bits matter as to whether the format qualifies as a IEEE 754 floating point number?

No, but when sent between machines they should be stored in network byte order, which is what the application did.

[jmcnamara]

I have one last query - does the order of the bits matter as to whether the format qualifies as a IEEE 754 floating point number?

Both systems are valid since the IEEE754 specification doesn't state which order the bytes should be in. And just to clarify, it is the bytes that are reordered not the bits. ;-)

--
John.

[physgreg]

Great! Thanks for the clarification - I feel a lot happier now. I also found the same issue with double precision numbers, but in this case I had to do a 'reverse' on the input (as per a previous suggestion), as there was no applicable unpack format that would work.