Why does fread sometimes return incorrect values?

2019 3 26
1 个回答
回答已采纳
更新时间：2019 3 27
4 次查看（30 天）

0 个投票

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?

5 个评论
显示 3更早的评论 隐藏 3更早的评论

dpb
dpb 2019-3-26
Have to see the actual code that wrote and read with, not just description. Attaching the file would also be wise.
Guillaume
Guillaume 2019-3-26
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
Harry 2019-3-26
编辑：Harry 2019-3-26
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
Guillaume 2019-3-26
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
Harry 2019-3-27
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.

请先登录，再进行评论。

请先登录，再回答此问题。

 采纳的回答

Harry
Harry 2019-3-26
编辑：Harry 2019-3-26

0 个投票

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.

3 个评论
显示 1更早的评论 隐藏 1更早的评论

Walter Roberson
Walter Roberson 2019-3-26
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
Harry 2019-3-27
编辑：Harry 2019-3-27
You were right, Walter. My C code was opening the file in text mode. Well spotted!
Walter Roberson
Walter Roberson 2019-3-27
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.

请先登录，再进行评论。

更多回答（0 个）

类别

在 帮助中心 和 File Exchange 中查找有关 Low-Level File I/O 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by