MATLAB Central Newsreader - Incoerences in MATLAB

Incoerences in MATLAB

Trouble Finders Costa — Thu, 11 Dec 2008 23:37:01 -0500

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.

Dante Valen?a.

Re: Incoerences in MATLAB

Roger Stafford — Thu, 11 Dec 2008 23:59:03 -0500

"Trouble Finders Costa" <valencadante@hotmail.com> wrote in message <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.
>
> Dante Valen?a.

What you are calling an "incoerence" actually represents a failure on the part of many users to understand that Matlab uses a binary number system. It has no way to express such values as 0.01 and 0.00001 exactly and must necessarily make very small round off errors in the above calculations. This has been discussed ad infinitum in previous threads. It is a common characteristic of any computing system that uses binary number fractions, just as a failure to be able to express 1/3 exactly is a shortcoming of decimal machines.

Roger Stafford

Re: Incoerences in MATLAB

NZTideMan — Fri, 12 Dec 2008 00:00:33 -0500

On Dec 12, 12:37=A0pm, "Trouble Finders Costa"
<valencada...@hotmail.com> wrote:
> I have discovered some incoerences and troubles in some commands of MATLA=
B. 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 perce=
ption 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 genera=
ted in MATLAB.
>
> Another problem, a trouble, has to do with the question of numerical prec=
ision. Try the following commands:
> time =3D 0; time_increment =3D 0.01; n =3D (a number of your choice);
> for i =3D 1:n
> =A0 =A0 time =3D time =A0+ 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 pr=
oblem for values of "time_increment" less than 0.1
>
> Thank you for your attention.
>
> Dante Valen?a.

What do you mean by "incoerence"? You've written it 3 times, so it
cannot be a spelling mistake, but it is not an English word. I
suspect it is a malapropism, but I'm not sure which word you're
getting at.
"incoherence", means a nonsense, but the fact that 10/0.00001 is not
the same as 1000000 in floating point arithmetic is not a nonsense.
The principle is well known and has been commented on many times in
this forum.

That these matters cause you headaches is a shame, but perhaps they
would cause you less concern if you learned from your mistakes and in
future refrained from trying to use floating point numbers as if they
were integers.

Re: Incoerences in MATLAB

Steven Lord — Fri, 12 Dec 2008 15:42:59 -0500

"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

Re: IncoHerences in MATLAB

Trouble Finders Costa — Fri, 12 Dec 2008 23:24:01 -0500

NZTideMan <mulgor@gmail.com> wrote in message <cfb60b8d-f7ec-4606-a52f-60fa9dd60c33@r15g2000prh.googlegroups.com>...
> On Dec 12, 12:37=A0pm, "Trouble Finders Costa"
> <valencada...@hotmail.com> wrote:
> > I have discovered some incoerences and troubles in some commands of MATLA=
> B. 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 perce=
> ption 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 genera=
> ted in MATLAB.
> >
> > Another problem, a trouble, has to do with the question of numerical prec=
> ision. Try the following commands:
> > time =3D 0; time_increment =3D 0.01; n =3D (a number of your choice);
> > for i =3D 1:n
> > =A0 =A0 time =3D time =A0+ 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 pr=
> oblem for values of "time_increment" less than 0.1
> >
> > Thank you for your attention.
> >
> > Dante Valen?a.
>
> What do you mean by "incoerence"? You've written it 3 times, so it
> cannot be a spelling mistake, but it is not an English word. I
> suspect it is a malapropism, but I'm not sure which word you're
> getting at.
> "incoherence", means a nonsense, but the fact that 10/0.00001 is not
> the same as 1000000 in floating point arithmetic is not a nonsense.
> The principle is well known and has been commented on many times in
> this forum.
>
> That these matters cause you headaches is a shame, but perhaps they
> would cause you less concern if you learned from your mistakes and in
> future refrained from trying to use floating point numbers as if they
> were integers.

Thank you. I was having in mind the word "incoer?ncia" when I wrote "incoerence". I will try to improve my English, it's not my first language. Is it yours?