Representing fractions in single-precision floating point

Question

Phil Ring 2019-4-17

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/457015-representing-fractions-in-single-precision-floating-point

编辑： James Tursa 2019-4-17

I have a specific application in which I must use only singles due to underlying processor contraints.

I am trying to get the fraction 1/27 to be stored in single-precision floating point, and to be as precise as possible. Using this link I see that the value can be accurate up to 10 digits (9 not counting trailing zero) for a value of 0.037037037. This is ok for my application, however anything less is not.

Trying this in MATLAB:

>> single(1/27)
ans =
   0.0370370

This only yields 7 digits of precision, which I can not use.

I would assume the single() function would store the value in IEEE-754 notation - but I don't know how to see the underlying bits in MATLAB.

What's more confusing is the following:

>> format long
>> sprintf('%.32f',single(1/27))
ans =
    0.03703703731298446700000000000000

Explicitly printing out more digits shows that there are in fact more digits being stored in the single. The actual value however, should be 0.037037037312984466552734375.

Is there any insight into how singles are being stored here? Is MATLAB cutting off digits in the first snippet? Why does MATLAB arbitrarily round up at the 18th digit?

In the end, I would like to be able to perform computations on a value closer to the output of the second snippet.

Thank you.

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

James Tursa 2019-4-17

编辑：James Tursa 2019-4-17

Regardless of the binary->decimal conversion you see displayed on the screen, MATLAB will store 1/27 in IEEE single precision as precise as possible. See my comments below.

"This only yields 7 digits of precision, which I can not use."

This is just a conversion display issue, not a bit pattern storage issue.

"I don't know how to see the underlying bits in MATLAB."

Use num2hex() function, or use format hex

"Is there any insight into how singles are being stored here?"

Stored as regular IEEE single floating point

"Is MATLAB cutting off digits in the first snippet?"

Only for the display. The underlying bit pattern storage is what you expect.

"Why does MATLAB arbitrarily round up at the 18th digit?"

It's not arbitrary. The library code used for the binary->decimal conversion simply takes the conversion only as far as needed so that a reverse conversion will reproduce the original floating point bit pattern. That has changed in recent Windows MATLAB versions so that now a full conversion is done (but not all of those extended decimal digits will contribute in a reverse conversion).

"In the end, I would like to be able to perform computations on a value closer to the output of the second snippet."

Your wish is granted. This is already being done in your version of MATLAB.

请先登录，再进行评论。

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

Answer 1

Walter Roberson 2019-4-17

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/457015-representing-fractions-in-single-precision-floating-point#answer_371100

I cannot tell at the moment whether you are using Windows or Linux. Either way, sprintf and fprintf truncate the output of values early for those two operating systems, with the situation being much worse on Windows. (The display is handled by underlying operating system libraries.) On Mac, the full value can be displayed using the sprintf() that you are using.

The fault is in the conversion for display. You can look in the File Exchange for num2strexact https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

You can also num2hex(single(1/27)) . If you also use num2hex() on single() of that output you get from sprintf() you will see that they are encoded into the same bit pattern -- so that string of digits is long enough to uniquely specify the trailing bits.

4 个评论
显示 2更早的评论隐藏 2更早的评论

James Tursa 2019-4-17

编辑：James Tursa 2019-4-17

在 MATLAB Online 中打开

"I cannot tell at the moment whether you are using Windows or Linux"

It was my understanding that only earlier versions of MATLAB on Windows had this display truncation issue (at least I can't recall anyone reporting this issue for a Linux system). Recent versions of MATLAB on Windows have changed the library code behind the binary->decimal conversion and now behave like their Linux counterparts have been for years. E.g.,

>> version
ans =
    '9.5.0.944444 (R2018b)'
>> computer
ans =
    'PCWIN64'
>> format long
>> sprintf('%.32f',single(1/27))
ans =
    '0.03703703731298446655273437500000'
>> num2hex(single(1/27))
ans =
    '3d17b426'

But, regardless of what extended decimal value is displayed on the screen, the underlying IEEE single floating point bit pattern is exactly the same in both MATLAB versions. E.g.,

>> version
ans =
9.0.0.370719 (R2016a)
>> computer
ans =
PCWIN64
>> format long
>> sprintf('%.32f',single(1/27))
ans =
0.03703703731298446700000000000000  <-- The truncated conversion for display
>> num2hex(single(1/27))
ans =
3d17b426  <-- The exact same underlying bit pattern as above

That being said, the number of decimal digits that prints out is sufficient to reproduce the floating point bit pattern when read back in. E.g.,

>> num2hex(single(0.037037037312984467))
ans =
3d17b426

Or, explicitly,

>> single(0.037037037312984467) == single(0.037037037312984466552734375)
ans =
     1

Walter Roberson 2019-4-17

single(1/27) returns a binary value that has all of the necessary information. However, the default display routine display() calls disp(), and disp() looks up the "format" in effect and decides how to output. Unfortunately, none of the available format() are full precision enough to nail down the last bit, not even "format long g". And unfortunately there is no ability to define a custom "format". So... to get enough bits to be sure, you need to do your own sprintf() or fprintf()

Phil Ring 2019-4-17