Why does linspace deliver unequal spacing?

I thought linspace was supposed to deliver a vector with perfectly even spacing, but there seems to be a slight difference in spacing, for example:

XGlobal = sort(rand(1,100))*100 - 50;
XRegular=linspace(min(XGlobal),max(XGlobal),27);
sprintf('%.20f\n', unique(diff(XRegular)))

ans =

3.83868769397494700000
3.83868769397495410000
3.83868769397495770000
3.83868769397496120000
3.83868769397497540000

You can see the last few digits differ. That means that, for example, interp2 with cubic interpolation won't work because it requires evenly spaced vectors. What is the workaround?

Answer 1

[the cyclist]

This is a result of computing in floating point arithmetic. Here is one of many possible starting points to read about this.

Did you actually use interp2, and it failed because of this, or was that more of a theoretical statement you made?

[K E]

The original reason to look in to this is that interp2 would not use cubic interpolation since the input vectors is not perfectly evenly spaced, ie:

XGlobal = sort(rand(1,100))*100 - 50;
YGlobal = sort(rand(1,70))*100 - 50 ;

XRegular=linspace(min(XGlobal),max(XGlobal),27);
YRegular=linspace(min(YGlobal),max(YGlobal),9);
[XRegularMesh,YRegularMesh]=meshgrid(XRegular,YRegular);
XValue = rand(size(XRegularMesh)); % diff(XRegular);

XPointOrigin=0; YPointOrigin=0;
dx=interp2(XRegular,YRegular,XValue,XPointOrigin,YPointOrigin,'cubic');

Warning: The 'cubic' method requires the grid to have a uniform spacing. Switching the method from 'cubic' to 'spline' because this condition is not met.

[the cyclist]

Hm. What version of MATLAB are you using? I just executed the code just fine. (Notice that I added a value for YPointOrigin.)

XGlobal = sort(rand(1,100))*100 - 50;
YGlobal = sort(rand(1,70))*100 - 50 ;
XRegular=linspace(min(XGlobal),max(XGlobal),27);
YRegular=linspace(min(YGlobal),max(YGlobal),9);
[XRegularMesh,YRegularMesh]=meshgrid(XRegular,YRegular);
XValue = rand(size(XRegularMesh)); % diff(XRegular);
XPointOrigin=0;
YPointOrigin=0;
dx=interp2(XRegular,YRegular,XValue,XPointOrigin,YPointOrigin,'cubic');

[K E]

R2015a. Sorry for missing YPointOrigin, corrected now.

[the cyclist]

I forgot I am using the R2015b pre-release. That version does not throw the warning. R2015a does throw the warning for me, too.

This suggests to me that this might be a listed bug. You could try searching the bug listing online for some recourse.

[K E]

Not listed in bug reports but upgrading to R2015b might be the workaround I need!

Answer 2

[Walter Roberson]

Consider for example, diff((1:3)/3,2) = 5.55111512312578e-17 indicating that (2/3 - 1/3) is not exactly equal to (3/3 - 2/3). And

cumsum(1/3*ones(1,10)) - (1:10)/3

is non-zero in positions 5, 6, and 7, indicating that adding 1/3 five times does not give the same result as if you had calculated 5/3 directly.

linspace has to choose one way of calculating the values. Whichever way it chooses is going to be "wrong" by some measure. If it makes the intervals exactly equal then there must be cumulative error. Do you want the "add 1/3 five times" value where the intervals are equal, or do you want the "5/3" value where the values are more precise but the intervals might not be exactly the same?

[K E]

Thanks. I have come to see that the underlying issue isn't that linspace is slightly unevenly spaced, but that Matlab functions like interp2's cubic option that require 'evenly' spaced inputs should tolerate very small amounts of unevenness.

[Mark Brandon]

I agree with this conclusion. I have found, like the author above, that inter2, and also griddedInterpolant, tend to throw the following error for very very small differences in grid spacing:

Warning: The 'cubic' method requires the grid to have a uniform spacing.

Switching the method from 'cubic' to 'spline' because this condition is not met.

In fact, I have yet to find a reliable way to generate grid vectors that place the uniform spacing test. These routines need to loosen up the tolerance a bit!!!

[Walter Roberson]

Over sufficiently large ranges with sufficiently precise steps, it is not possible to generate exactly uniform spacing, due to how double precision numbers are stored. If your range crosses a power-of-2 boundary, then you must lose a bit of precision. There is no real way around this except to deliberately work on ranges based upon powers of two instead of on ranges based on decimal -- for example, work from 1024 to 2047 instead of 1000 to 2000.