Unexpected result for arithmetic operation

Dear all,

I am having some difficulty with what appears to be a bug. Consider the following simple code:

clear;clc;clf;
td=[0.01 0.20:0.20:1.0]; 
tbinw=0.05;
ibt=ceil(td./tbinw);
tdc=ibt.*tbinw-(tbinw/2.0);

When this is executed, the result for the vector tdc is

tdc =

    0.0250    0.1750    0.3750    0.6250    0.7750    0.9750

However, when I test whether the 2nd element of tdc is 0.175, the result is false. Apparently, tdc(2)-0.175 = 2.7756e-17. However, this precision problem does not arise for any of the other elements in tdc.I am wondering why this is the case. This behaviour leads to an error in a subsequent part of my code. I am using a student version of Matlab R2013a.

[Stephen23]

"I am having some difficulty with what appears to be a bug."

Nope, not a bug. You are just the one millionth beginner that has to start learning about floating point numbers.

"I am wondering why this is the case."

You are using a computer which stores values as binary floating point numbers. In exactly the same way that you cannot write 1/3 exactly using a finite decimal fraction, it is impossible to store 0.175 exactly using a finite binary floating point number. So although you might think that you have 0.175, in fact the real value stored in computer memory is slightly different from this.

The simplest solution for your code is to compare an absolute difference and a tolerance.

What you see printed in the command window is the closest representation to 5 or 16 significant digits, depending on your current format setting. To see the "real" value download James Tursa's FEX submission:

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

Use James Tursa's num2strexact and you will see that that number does not really have the exact value 0.175. All you are looking at is a representation of those floating point numbers displayed in the command window, to the precision defined by your format setting. Just because you see 0.175 displayed tells you nothing about the "real" floating point number's value.

Note that you can change how the value is displayed by changing the format.

You need to learn about the limits of floating point numbers. Start by reading these:

https://www.mathworks.com/matlabcentral/answers/57444-faq-why-is-0-3-0-2-0-1-not-equal-to-zero

https://www.mathworks.com/matlabcentral/answers/316889-why-two-equal-numbers-are-not-equal

http://www.mathworks.com/matlabcentral/answers/102419-how-do-i-determine-if-the-error-in-my-answer-is-the-result-of-round-off-error-or-a-bug

http://www.mathworks.com/matlabcentral/answers/140656-about-numerical-difficulty-of-equality-comparison-operation-between-two-double-real-numbers-in-matlab

https://www.mathworks.com/matlabcentral/answers/320473-we-found-a-possible-bug-in-our-matlab

https://www.mathworks.com/matlabcentral/answers/376108-is-this-a-bug-in-max-x

This is worth reading as well:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

http://faculty.tarleton.edu/agapie/documents/cs_343_arch/papers/1991_Goldberg_FloatingPoint.pdf

[Philip Borghesani]

Point of discussion here. Do you think matlab code adviser should warn for any code that uses an inexact floating point increment value for a range? I have made the suggestion in the past but have not pushed it.

[Walter Roberson]

Philip,

My suspicion is that it would be more trouble to people than it is worth to warn about that.

In some development environments, the organizational standards are that there can be no mlint warnings in code. Adding a warning for this could potentially require that quite a bit of code be rewritten. But MATLAB does not really provide any convenient function that might do any better. It is also not clear what "better" would even mean for this.

I can see one potential meaning: MATLAB could provide a "decimal colon" operator. For the sake of discussion I will denote it as ! . The working would be that in the form A!B!C where A and B and C are written as literal decimal constants, that A+k*B for integer k, evaluated in decimal, would exactly equal to what you would get if you had written that value literally -- at least unless not possible due to loss of precision.

Example:

T = .01!.17!2

would be such that

T - [0.01 0.18 0.35 0.52 0.69 0.86 1.03 1.2 1.37 1.54 1.71 1.88]

would be all exactly 0

Now, perhaps this would work out as finding the maximum number of decimal places in the literal constants A and B and effectively multiplying through the constants before evaluation and dividing the result by 10 to the appropriate power, like

T = (round(.01*10^2):round(0.17*10^2):round(2*10^2))/10^2

That worked out in my small test, but one thing I do not know is whether it is guaranteed that for any literal decimal value of the form A.B..Z if that will be bitwise identical to AB..Z/10^(length(B..Z)) . I have not found any exceptions in my tests; e.g., 0.814723686393179 - 814723686393179/10^15 is 0 but that is not the same as a guarantee.

Plausibly someone could write a function for this that worked on character vectors or string values, like

decimalcolon('.01', '.17', '2')

but if Mathworks were going to be adding a mlint warning then it would be better if there were a hook in the editor that could rewrite code such as .01:.17:2 to something suitable.

I do not at the moment have good ideas as to what the meaning of such an operator should be if the operands are expressed in numeric form but are not constants. For example,

dt = 0.17;
T = .01 ! dx ! 2

It would be unlikely that the user would be expecting that to be the same as

T = .01 ! 0.1700000000000000122124532708767219446599483489990234375 ! 2

Answer 1

[Karthik Nagarajan]

I think I have found the answer:

https://www.mathworks.com/help/matlab/ref/eq.html#bt2klek-3