Reading IEEE Floating-Point 32bit number

[markstab]

I have a program written in C++ that works with single precision float (IEEE) in Windows. When I try to read data from that program in LabView they seem different. Labview also use IEEE single float representation. The numbers in the files are sine wave with amplitude 1 and 30 samples/cycle.
The first numbers are
0
0.207912
0.406737 etc.
Reading in LV the second number is 3E 54 E6 E2 where the left 3 bytes are mantissa and the right exponent and sign. Reading in LV the second number from the program1 I have CE E6 54 3E which is the mantissa on the right as little endian, but the exponent and sign are CE?! Any hint how to read it correctly in LV?

[Wiebe@CARYA]

Hi,

This works for the second file.

Regards,

Wiebe.
"markstab" wrote in message
news:506500000008000000D2B20000-1068850981000@exchange.ni.com...
> I have a program written in C++ that works with single precision float
> (IEEE) in Windows. When I try to read data from that program in
> LabView they seem different. Labview also use IEEE single float
> representation. The numbers in the files are sine wave with amplitude
> 1 and 30 samples/cycle.
> The first numbers are
> 0
> 0.207912
> 0.406737 etc.
> Reading in LV the second number is 3E 54 E6 E2 where the left 3 bytes
> are mantissa and the right exponent and sign. Reading in LV the second
> number from the program1 I have CE E6 54 3E which is the mantissa on
> the right as little endian
, but the exponent and sign are CE?! Any
> hint how to read it correctly in LV?



[Attachment Decode.vi, see below]

[Greg_McKaskle2]

> the right as little endian, but the exponent and sign are CE?! Any
> hint how to read it correctly in LV?

You are correct. The endian issue is what is causing this. There are
nodes built into LV for swapping words and swapping bytes. After
reading your values in and building an array or cluster, send them
through both nodes and you will have little endian values. Hopefully
the file I/O will offer built-in translation in the future, but at the
moment LV always assumes big endian or network endian data over networks
and files.

If you save data out from LV, the same applies. LV will write in big
endian. You can either do the swaps before writing, or you can do it in
the reader.

Greg McKaskle

[markstab]

Hi Greg,
swaping bytes will resolve only the conversion of mantissa but what is the solution for the exponent?

In the example they are different, and finally both companies MS and NI claim they are using the same format (IEEE). The first file is result from MS Visual C++ and the format is here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_ieee_floating.2d.point_representation_and_microsoft_languages.asp

you can read the same information about the format from Labview data storage application note for Single precision number format but they looks different.

[markstab]

Thanks Wiebe,

The second file really is not a problem. I have created it in Labview only for example to compare to the other MS format and see the differences. Here it is not necessary to swap bytes and you can read that file simply as single with the attached example.

[Jeremy Braden]

I think that you are confusing the way bits are stored with the format for floating point numbers. Floating point numbers consist of bits. One is for sign, some are for mantissa and some are for exponent. When the number is written to file, the bits are joined as bytes. It is the ordering of the bytes that big endian or little endian addresses. Please see the following links.

What Does the Term "Endian" Mean?

Writing Binary Files with LabVIEW That Can Be Read by Other Applications

[Jeremy Braden]

oops.

Writing Binary Files with LabVIEW That Can Be Read by Other Applications

[Greg_McKaskle2]

> swaping bytes will resolve only the conversion of mantissa but what is
> the solution for the exponent?
>

Go ahead and give it a try, this is done all the time inside LV. The
deal is that there are two ordering systems. One stores ABCD as ABCD
and the other as DCBA. Swapping words will get you BACD, and swap bytes
will give you ABCD. It doesn't matter which order you do the swaps in,
and all you really need know is whether the data is encoded the same as
yours, if not, do the swaps.

As for the confusion over IEEE 754, as the other response pointed out,
IEEE is concerned with bit ordering within the 32 bits, it doesn't
concern itself with the ordering of bytes within a 32 bit long word.

If you don't want to write this youruself
, I'm pretty sure you can find
tools for doing this on the web.

Greg McKaskle

[Rolf Østvik]

markstab wrote in news:506500000008000000D2B20000-
1068850981000@exchange.ni.com:

> I have a program written in C++ that works with single precision float
> (IEEE) in Windows. When I try to read data from that program in
> LabView they seem different. Labview also use IEEE single float
> representation. The numbers in the files are sine wave with amplitude
> 1 and 30 samples/cycle.
> The first numbers are
> 0
> 0.207912
> 0.406737 etc.
> Reading in LV the second number is 3E 54 E6 E2 where the left 3 bytes
> are mantissa and the right exponent and sign. Reading in LV the second
> number from the program1 I have CE E6 54 3E which is the mantissa on
> the right as little endian, but the exponent and sign are CE?! Any
> hint how to read it correctly in
LV?

After reading the original question and the other responses several times i
finally think i understand the problem.

Her is a suggestion fro solution
- Read the numbers as U32 (Unsigned 32) from the file.
- Use the Swap Bytes and the Swap Word functions.
- Use the "Type Cast" function to cast the numbers to single.

voila

--
Rolf

[markstab]

Thanks Jeremy,
That is the solution. I have the same answer from NI support. I was confused not from the byte order but from the difference when reading the bytes with the attached example. The second number is 0.207912
and in LV it is 3E 54 E6 E2, in WinC is CE E6 54 3E, then why is the difference between 3E and CE