Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Possible bug when generating vectors with a fixed step

Subject: Possible bug when generating vectors with a fixed step

From: Bogdan Cristea

Date: 10 Jan, 2010 18:40:21

Message: 1 of 7

The following code gives the wrong result:

x = 0:0.1:5;
find(x==1.4)

The output of the find function is an empty matrix. Should be this considered as a bug ?

Subject: Possible bug when generating vectors with a fixed step

From: Jan Simon

Date: 10 Jan, 2010 19:28:03

Message: 2 of 7

Dear Bogdan!

> The following code gives the wrong result:
> x = 0:0.1:5;
> find(x==1.4)
> The output of the find function is an empty matrix. Should be this considered as a bug ?

Have you read the FAQ as suugested e.g. on the MathWorks web interface of this newsgroup: "Check if your question is answered in the comp.soft-sys.matlab FAQ" ?
There you find:
http://matlabwiki.mathworks.com/MATLAB_FAQ#Why_is_0.3-0.2-0.1_not_equal_to_zero_.28or_similar.29.3F

So this is not a bug, but the typical, expected and intented behaviour of floating point numbers.

Kind regards, welcome to this newsgroup, Jan

Subject: Possible bug when generating vectors with a fixed step

From: Bogdan Cristea

Date: 11 Jan, 2010 06:26:03

Message: 3 of 7

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <hid9o3$e29$1@fred.mathworks.com>...
> Dear Bogdan!
>
> > The following code gives the wrong result:
> > x = 0:0.1:5;
> > find(x==1.4)
> > The output of the find function is an empty matrix. Should be this considered as a bug ?
>
> Have you read the FAQ as suugested e.g. on the MathWorks web interface of this newsgroup: "Check if your question is answered in the comp.soft-sys.matlab FAQ" ?
> There you find:
> http://matlabwiki.mathworks.com/MATLAB_FAQ#Why_is_0.3-0.2-0.1_not_equal_to_zero_.28or_similar.29.3F
>
> So this is not a bug, but the typical, expected and intented behaviour of floating point numbers.
>
> Kind regards, welcome to this newsgroup, Jan

Yes, you have right, I have forgotten about how the floating point numbers are represented in a PC.
Nevertheless, in a high level language, the tolerance when comparing numbers could be taken into account.

Subject: Possible bug when generating vectors with a fixed step

From: Matt J

Date: 11 Jan, 2010 08:02:04

Message: 4 of 7

"Bogdan Cristea" <cristeab@gmail.com> wrote in message <hieg9r$ra3$1@fred.mathworks.com>...

> Yes, you have right, I have forgotten about how the floating point numbers are represented in a PC.
> Nevertheless, in a high level language, the tolerance when comparing numbers could be taken into account.
===============

It can be taken into account, but not by the comparison operator a==b, because the tolerance you would want depends on the context in which it is used.

However, this FEX submission does something along the lines of what you are talking about:

http://www.mathworks.com/matlabcentral/fileexchange/23294-ismemberf

Subject: Possible bug when generating vectors with a fixed step

From: Jan Simon

Date: 11 Jan, 2010 09:20:20

Message: 5 of 7

Dear Bogdan!

> Nevertheless, in a high level language, the tolerance when comparing numbers could be taken into account.

Correct! It *must* be taken into account. Nevertheless, an exact working operator for comparing floating point numbers is needed also.
Besides the excellent ismemberf of Bruno, you can manage the tolerance manually also, e.g. for an absolute tolerance:
  find(abs(x - 0.4) < 10 * eps)
or for a relative tolerance (needed e.g. if working with very small values):
  find(abs(x - 0.000004) ./ max(x, 0.000004) < 0.01)

Even a high level language as Matlab needs a well defined set of low level functions.

Good luck, Jan

Subject: Possible bug when generating vectors with a fixed step

From: Derek O'Connor

Date: 11 Jan, 2010 10:17:02

Message: 6 of 7

"Bogdan Cristea" <cristeab@gmail.com> wrote in message <hid6ul$i6c$1@fred.mathworks.com>...
> The following code gives the wrong result:
>
> x = 0:0.1:5;
> find(x==1.4)
>
> The output of the find function is an empty matrix. Should be this considered as a bug ?

--------------------------------

The real and more general problem is dividing an interval [a,b]
into steps whose length is not representable in IEEE floating
point binary arithmetic. In your example a=0, b=5 are
representable, but the step=0.1 is not representable.

What is so special about 0.1 or 0.01? In most problems you are
free to choose the step, within limits, so why not choose a
representable step, such as 1/8, 1/32, etc.

If you must use 0.1, 0.01, etc., then I suggest you wait until
Intel and AMD bring out processors that implement the IEEE
standard for decimal arithmetic. Until then you are stuck with
binary arithmetic.

Software solutions using tolerances etc. are messy,
error-prone, and time-consuming.

The Patriot Missile disaster in which 28 soldiers were killed,
was caused by counting time in tenths of a second.

Derek O'Connor

Subject: Possible bug when generating vectors with a fixed step

From: Steven Lord

Date: 11 Jan, 2010 15:35:30

Message: 7 of 7


"Bogdan Cristea" <cristeab@gmail.com> wrote in message
news:hieg9r$ra3$1@fred.mathworks.com...
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
> <hid9o3$e29$1@fred.mathworks.com>...
>> Dear Bogdan!
>>
>> > The following code gives the wrong result: x = 0:0.1:5;
>> > find(x==1.4)
>> > The output of the find function is an empty matrix. Should be this
>> > considered as a bug ?
>>
>> Have you read the FAQ as suugested e.g. on the MathWorks web interface of
>> this newsgroup: "Check if your question is answered in the
>> comp.soft-sys.matlab FAQ" ?
>> There you find:
>> http://matlabwiki.mathworks.com/MATLAB_FAQ#Why_is_0.3-0.2-0.1_not_equal_to_zero_.28or_similar.29.3F
>>
>> So this is not a bug, but the typical, expected and intented behaviour of
>> floating point numbers.
>>
>> Kind regards, welcome to this newsgroup, Jan
>
> Yes, you have right, I have forgotten about how the floating point numbers
> are represented in a PC. Nevertheless, in a high level language, the
> tolerance when comparing numbers could be taken into account.

That would eliminate one instance of this type of confusion, but more would
be lurking in the wings waiting for their time in the spotlight.

y = floor(0.3/0.1)

If you were to perform this computation in exact arithmetic, the answer is
obviously 3. But since 0.1 and 0.3 are not exactly representable as double
(the cause of the problem in your initial post) the actual answer is y = 2.

z1 = 1;
z2 = 1+1e-20;
z3 = z2-z1

Again, in exact arithmetic, z3 is 1e-20. In double-precision floating point
arithmetic, the correct answer is z3 = 0, because z2 is exactly 1.

Borrowing an example from Cleve's article linked in the FAQ entry above:

y = 4/3;
x = y-1;
z = 3*x;
epsilon = 1-z % not 0

I could come up with MANY examples like this, probably one for just about
every function in MATLAB, where the answer that may seem obvious (from our
experience with exact arithmetic) is not what MATLAB returns. None of the
above are bugs.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us