Why do inconsistencies exist with floating-point numbers rounding in sprintf, fprintf, sin etc?

Why do inconsistencies exist with floating-point numbers rounding in sprintf, fprintf, sin etc?

str1 = sprintf('%0.1f ',40.05);
str2 = sprintf('%0.1f ',20.05);
str3 = sprintf('%0.1f ',30.05);
str4 = sprintf('%0.1f ',50.05);
disp([str1 ' ' str2 ' ' str3 ' ' str4]);

The output is:

 40.0 20.1 30.1 50.0

Answer 1

[MathWorks Support Team]

It is a floating-point representation issue. The Symbolic Toolbox functions sym (with the ‘f’) option and vpa are useful for understanding why.

First, use sym with ‘f’ to determine exactly what something like 20.05 or 40.05 becomes when you convert it to double-precision floating point.

 >> sym(20.05,'f')
 ans =
 5643573283048653/281474976710656

Now use vpa to convert that rational number to a decimal fraction with more digits:

 >> vpa(ans,30)
 ans =
 20.0500000000000007105427357601

Repeat those steps with 40.05:

 >> sym(40.05,'f')

 ans =
 2818268204315443/70368744177664

 >> vpa(ans,30)

 ans =
 40.0499999999999971578290569596

You can see that 20.05 gets converted to a floating-point number slightly greater than 20.05, whereas 40.05 gets converted to a floating-point number slightly less than 40.05. The issue is not with any specific function such as sprintf, fprintf, sin etc, in fact it is not a MATLAB-related issue. It stems from the way that the IEEE-754 standard represents floating point numbers (or real numbers) in binary.

[Stephen23]

Nice introduction to the topic of floating point numbers. Any answer to this?:

https://www.mathworks.com/matlabcentral/answers/174643-sprintf-round-off-floating-point-bug

[Namita Vishnubhotla]

Please create a service request with MathWorks technical support for this question. (<mailto:[e-mail] [e-mail]>)