0

When I create a simple array from 0 to 0.6 with 0.1 spacing, the values are not precise. There is an error in some of them on the order of 10^-17. I've managed to work around by creating an array from 1 to 6, then dividing by 10, but I'm looking to understand why this happens so I can avoid similar precision errors in the future. 

X = 0:0.1:0.6;    
X == [0 0.1 0.2 0.3 0.4 0.5 0.6]
  ans =
  1     1     1     1     0     1     1
X(5) - 0.4
  ans = -5.5511e-17

 X = (0:1:6)/10;   
X == [0 0.1 0.2 0.3 0.4 0.5 0.6]
  ans =
  1     1     1     1     1     1     1
X(5) - 0.4
  ans = 0
Helos35
  • 121
  • 1
  • 13
  • This is just normal behaviour for floating point values, since they have finite precision. You'll need to understand the limitations of floating point if you plan to write any kind of numerical code. – Paul R Feb 04 '15 at 14:34
  • [Here](http://www.mathworks.com/videos/working-with-arrays-in-matlab-69022.html) is a tutorial on working with arrays in Matlab, it would probably shed some light on your issue. – CalebB Feb 04 '15 at 14:36

1 Answers1

0

This problem can not really be avoided since any computer will always suffer from machine precision: since decimal numbers are stored internally as a binary number, you will always have a finite precision. This means there is a minimum step size between any 2 consecutive numbers. You can find this precision (or smallest step size) using the eps command. For further information, see also the Wikipedia entry on machine precision.

Wouter Kuijsters
  • 840
  • 6
  • 20
  • However, I would say this exact case is weird. One could think that there would be safety mechanisms for these things, in matlab. Especially since `X = [0 0.1 0.2 0.3 0.4 0.5 0.6], X == [0 0.1 0.2 0.3 0.4 0.5 0.6]` returns the expected answer. Also, it seems that `X=0:0.1:0.6` does not work exactly the same way as `X=[0,0.1.0.2,0.3,0.4,0.5,0.6]`. So the conclusion should then be thatthe machine epsilon is not the only culprit here, but also the implementation of the `0:a:b` operation. – patrik Feb 05 '15 at 07:49
  • Since the operation is reproducable on my machine as well (windows 7, 64-bit) I would say that you could maybe send a bug report to mathworks on this. However, keep in mind that exact comparison should not be used on floating point numbers and the error is less then the machine epsilon (smaller than the hard limit so to say). This may mean that they will not do anything about it. – patrik Feb 05 '15 at 07:52