Path: news.mathworks.com!not-for-mail
From: "Steven Lord" <slord@mathworks.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Incoerences in MATLAB
Date: Fri, 12 Dec 2008 10:42:59 -0500
Organization: The MathWorks, Inc.
Lines: 50
Message-ID: <ghu0q3$6mv$1@fred.mathworks.com>
References: <ghs86t$528$1@fred.mathworks.com>
Reply-To: "Steven Lord" <slord@mathworks.com>
NNTP-Posting-Host: lords.dhcp.mathworks.com
X-Trace: fred.mathworks.com 1229096579 6879 144.212.105.187 (12 Dec 2008 15:42:59 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Fri, 12 Dec 2008 15:42:59 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Xref: news.mathworks.com comp.soft-sys.matlab:506590



"Trouble Finders Costa" <valencadante@hotmail.com> wrote in message 
news:ghs86t$528$1@fred.mathworks.com...
>I have discovered some incoerences and troubles in some commands of MATLAB. 
>These problems caused me headaches by the time I have faced them for the 
>first time, because of the loss of several minutes in work until the 
>perception of the problem.
>
> One of this problems, an incoerence, is: try if [125000:125000:10/0.00001] 
> and [125000:125000:1000000] are vectors of the same dimension when 
> generated in MATLAB.
>
> Another problem, a trouble, has to do with the question of numerical 
> precision. Try the following commands:
> time = 0; time_increment = 0.01; n = (a number of your choice);
> for i = 1:n
>    time = time  + time_increment;
> end
>
> You will notice that, for large values of "n", some decimal numbers will 
> appear after the second one. This shouldn't happen. I have observed this 
> problem for values of "time_increment" less than 0.1
>
> Thank you for your attention.

Welcome to the world of floating point arithmetic.  Read this document for 
an explanation of these two phenomena.

http://www.mathworks.com/company/newsletters/news_notes/pdf/Fall96Cleve.pdf

Note that these "troubles" are not limited to MATLAB, but are present in all 
arithmetic performed in finite precision.  Take a pencil and paper and 
compute x = 1/3 to any finite number of decimal places you want.  Now 
compute y = 3*x (make sure to use the finite-precision representation of x 
you calculated previously; don't say (1/3) times 3 is 1.)  y will not be 
exactly 1; roundoff error in your computation of x to a finite number of 
decimal places will make it 0.999...999 for some number of 9's.

Similarly, neither 0.00001 nor 0.01 can be exactly represented in binary, so 
in your first example the upper limit of your first colon expression is not 
exactly 10 divided by (one times ten to the -5th power)  and so the division 
does not result in exactly 1e6.  Similarly, adding together the IEEE double 
precision representation of 0.01 multiple times is not exactly the same as 
adding one one-hundredth together multiple times.

-- 
Steve Lord
slord@mathworks.com