Why does fread sometimes return incorrect values?

I regularly use MATLAB to analyse data generated elsewhere. Most commonly, I work with int16s and single precision floats.

However, I recently needed to use (64-bit) doubles. Some values read back fine, but others don't.

For example, if in my C code, I generate and save this number to file:

double x = -3.0 * cos(M_PI * 3.0 / 8.0);

then MATLAB correctly reads back the value (approx) -1.1481 from the file. If I interpret the file as uint64, then both C and MATLAB agree that this is:

MATLAB: 1.3831e+19

C: 13831221214917623563

However, if in my C code, I generate and save this number to file:

double x = -3.0 * cos(M_PI * 5.0 / 8.0);

then MATLAB reads back -8.1120e+242 instead of (precisely) 1.148050297095269289827. Furthermore, MATLAB and C now disagree about the uint64 interpretation:

MATLAB: 1.7465e+19

C: 4607849178062847754 (= 0x3ff25e69fd02ff0a)

As shown in this online tool, 0x3ff25e69fd02ff0a is the correct hex representation of 1.148050297095269289827.

What am I doing wrong?

[dpb]

Have to see the actual code that wrote and read with, not just description. Attaching the file would also be wise.

[Guillaume]

Matlab never displays uint64 in scientific notation, so clearly you're not reading the numbers as uint64.

As dpb says, we'd have to see the code you use.

4607849178062847754 is indeed the uint64 representation of -3.0 * cos(M_PI * 5.0 / 8.0);

>> x = -3.0 * cos(pi * 5.0 / 8.0);
>> typecast(x, 'uint64')
ans =
  uint64
   4607849178062847754

[Harry]

I am reading the numbers as uint64 but, by default, fread() casts to double. This isn't the problem.

I had a look in a hex editor and noticed that the file somehow contains 9 bytes instead of 8 (with an extra x0d prepended at the start of the file). I can only think that this is a bug in the C compiler. It's curious that the C code still reads back the "correct" value from file. I'm really not sure what is going on there.

Still, not MATLAB's fault, so this isn't the place to be asking. Sorry for wasting your time.

[Guillaume]

by default, fread() casts to double. This isn't the problem.

Hum, it can be, any uint64 > 9007199254740992 (flintmax) may be rounded when converted to double.

[Harry]

I'm aware that a double has fewer than 64 mantissa bits, but rounding isn't the problem here. When MATLAB represented an expected 13831221214917623563 as 1.3831e+19, it was beyond reasonable doubt that this wasn't a fluke. When it represented an expected 4607849178062847754 as 1.7465e+19, this was not a rounding error.

Answer 1

[Harry]

I had a look in a hex editor and noticed that the file somehow contains 9 bytes instead of 8 (with an extra x0d prepended at the start of the file). I can only think that this is a bug in the C compiler. It's curious that the C code still reads back the "correct" value from file. I'm really not sure what is going on there.

Still, not MATLAB's fault, so this isn't the place to be asking. Sorry for wasting your time.

[Walter Roberson]

How is the file being opened? If it was being opened in text mode instead of binary mode, then the 0x0a at the end of the number would be translated to 0x0d 0x0a .

[Harry]

You were right, Walter. My C code was opening the file in text mode. Well spotted!

[Walter Roberson]

The conventions in MATLAB and C are opposite. In MATLAB, fopen expects binary unless you use the 't' permission, whereis in C, fopen expects text unless you use the 'b' permission. It is easy to get a mismatch when going between the two programming languages.