Creating vectors from 0 to 1, i.e. 0:0.01:1 leads to invisible rounding errors?

Hi,

I came across the following problem while trying to merge two tables with innerjoin:

Whenever I create vectors counting up from 0 to 1 tiny rounding errors seem to creep in, which one can only notice when scaling the vector up i.e. looking at (0:0.01:1)'*100.

Is there a chance I might have screwed up my Matlab settings at some point?

[Stephen23]

This topic comes up very often:

http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F

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/69-why-does-1-2-3-1-3-not-equal-zero#answer_271

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

https://www.mathworks.com/matlabcentral/answers/41536-why-is-2-24-10-22-4-not-equal-to-0

https://www.mathworks.com/matlabcentral/answers/20830-1-0010-does-not-equal-1-0010

etc, etc, etc

Always use a tolerance when comparing floating point values.

Answer 1

[Ahmet Cecen]

Check "eps". Those are numerical artifacts introduced because you are accessing decimal points beyond the accuracy of MATLAB(double precision). Double is guaranteed to be accurate up to 15 significant digits (I think). The errors you see are the 16th or 17th significant digit of the original double you created i.e. 0.01.

This shouldn't effect your computation unless you do multiplication/division at very high orders of magnitude difference.

[John D'Errico]

I would not say that double is guaranteed to be accurate to ANY number of decimal digits.

A double is stored in BINARY form. So the number is represented with a 52 bit binary mantissa, then displayed in decimal form (maybe because people tend not to be able to read binary numbers well.) So there is no guarantee of a certain number of digits. As it turns out, eps for a double

eps
ans =
   2.2204e-16

So you get almost 16 decimal digits.

[Ahmet Cecen]

Yeah, I simplified things a little bit. As a rule of thumb though it is fair to say 15 significant digits in base10 math is the most you can accommodate in double, depending on your operation (something simple enough); as 2^52 is 4.5*e+15.

Answer 2

[Testdriver]

Interesting. This led to quite a bit of frustration when I used tables and innerjoin together with the vectors from above as the key variable in a workaround for a plot. Thanks for the reply.

[Ahmet Cecen]

Always round your numbers (to an appropriate significant digit) if you want to use them as indices or keys in a dataset, just good practice. Better yet, use int64 if at all possible.

[Walter Roberson]

With the one exception that if the data is certain to be drawn from exactly the same source then it is fair to compare it for equality.

For example, although you should not compare a computed value to 0.01 exactly, it is fair to test x == max(x) because the max(x) will be a bitwise identical copy of some element of x.