Accuracy of linspace using low integers...

Matlab Maci64 R2012a

This bothers me greatly. I am creating an evenly spaced array on the fly for several particles that I integrate using ode45. I then place the answer on an interpolated timeline so that i can easily align the particles for animations, etc...

After having collected a large data set, I noticed the following, linspace is not accurate, even when it really should be.

try this:

linspace(0,1,401)'

then

linspace(0,10,401)'

This is a problem as I tried using unique to help me determine the final number of interpolated steps I had generated using the solver, only to find that there were several values on my timeline which differed by 1e-15.

Why can't linspace behave? When dealing with fractions of low integers, it really should not introduce artifacts in the numbers. Of course, I can solve my problem in a number of other manners, but still, linspace should generate artifacts, or perhaps it should have an added option to place the numbers within a certain accuracy?

-Kevin Mcilhany

Answer 1

[Jan]

Welcome to the world of floating point numerics with limited precision. Please read one of the most frequently asked questions: FAQ: Why is 0.3-0.2-0.1 ~= 0

So linspace is behaving exactly as expected, but decimal numbers cannot be converted to the binary format without a distinct lack of accuracy.

Answer 2

[Matt J]

Never mind linspace. What about this:

>> format long; 
>> 39.8

ans =

    39.799999999999997

or this,

>> 9.8

ans =

     9.800000000000001

[Kevin]

Exactly! So instead, I use str2num and sprintf and I waste cpu cycles. Mathworks really needs to work on long format.

[Matt J]

I don't think it's an issue with long format. Compare,

>> 39.8-39.7

ans =

     0.099999999999994

but,

>> 0.2-0.1

ans =

     0.100000000000000