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:
boolean == gives wrong ans

Subject: boolean == gives wrong ans

From: Seth

Date: 2 Nov, 2008 04:57:02

Message: 1 of 4

I am having this problem on two separate machines, both with R2007a installed:

>> X = 0:.1:1
>> .3 == X
ans =
0 0 0 0 0 0 0 0 0 0 0

Clearly the ans should be

0 0 0 1 0 0 0 0 0 0 0

Also, it works fine for all other values (.2 == X, .5 == X, etc)

What could I be doing wrong? Like I said, two computers (Ubuntu 8.04), both of which run MatLab flawlessly, give the same incorrect answer.

Thanks,
Seth

Subject: boolean == gives wrong ans

From: Walter Roberson

Date: 2 Nov, 2008 06:24:56

Message: 2 of 4

Seth wrote:
> I am having this problem on two separate machines, both with R2007a installed:
 
>>> X = 0:.1:1
>>> .3 == X
> ans =
> 0 0 0 0 0 0 0 0 0 0 0

> Clearly the ans should be

> 0 0 0 1 0 0 0 0 0 0 0

> What could I be doing wrong?

The == operator is giving the correct answer. You just aren't asking the question
you think you are.

The == operator tests for *exact* equality, down to the last bit.
You have made an error in believing that the colon operator will generate
bit-for-bit identical multiples of the increment when compare to the
algebraic number.

There is no -exact- binary floating point representation of 0.1,
and when you type in 0.3, you aren't getting -exactly- 3/10 either. Try

format long g;
(0:.1:1) - 0.3

and see whether you get an exact 0 value out at any element.
And then try

sprintf('0.75g', 0.3)

and see whether the value stored internally is -exactly- 3/10 .


It isn't a bug in Matlab. It's a fundamental limitation in the
representation of numbers in *any* finite representation scheme.
No matter -what- representation scheme you come up with, if it
must store numbers in a finite amount of space, there will be
some numbers that will not be exactly representable. Any finite
discrete storage mechanism will be able to store at most a portion
of the countable infinity, but the number of real numbers
is (see Cantor's Diagonalization Argument) the uncountable infinity.
There are an uncountable infinity of real numbers between any two
numbers representable in any finite numeric representation system.

Boiling this down into simpler terms:

  Never Do An Exact Comparison Of Floating Point Numbers

If you want to know if two floating point numbers are equal and
they were produced through even the -slightest- difference in
methods (and that can include hidden compiler optimizations),
then you must assume that even if the two expressions that
produced the numbers were algebraically identical, that the
bit-for-bit representation might differ slightly. So don't compare
for equality: instead, check to see if the difference between
the two numbers is sufficiently small to be negligible.


--
.signature note: I am now avoiding replying to unclear or ambiguous postings.
Please review questions before posting them. Be specific. Use examples of what you mean,
of what you don't mean. Specify boundary conditions, and data classes and value
relationships -- what if we scrambled your data or used -Inf, NaN, or complex(rand,rand)?

Subject: boolean == gives wrong ans

From: NZTideMan

Date: 2 Nov, 2008 09:17:26

Message: 3 of 4

On Nov 2, 7:24=A0pm, Walter Roberson <rober...@hushmail.com> wrote:
> Seth wrote:
> > I am having this problem on two separate machines, both with R2007a ins=
talled:
> >>> X =3D 0:.1:1
> >>> .3 =3D=3D X
> > ans =3D
> > 0 0 0 0 0 0 0 0 0 0 0
> > Clearly the ans should be
> > 0 0 0 1 0 0 0 0 0 0 0
> > What could I be doing wrong?
>
> The =3D=3D operator is giving the correct answer. You just aren't asking =
the question
> you think you are.
>
> The =3D=3D operator tests for *exact* equality, down to the last bit.
> You have made an error in believing that the colon operator will generate
> bit-for-bit identical multiples of the increment when compare to the
> algebraic number.
>
> There is no -exact- binary floating point representation of 0.1,
> and when you type in 0.3, you aren't getting -exactly- 3/10 either. Try
>
> format long g;
> (0:.1:1) - 0.3
>
> and see whether you get an exact 0 value out at any element.
> And then try
>
> sprintf('0.75g', 0.3)
>
> and see whether the value stored internally is -exactly- 3/10 .
>
> It isn't a bug in Matlab. It's a fundamental limitation in the
> representation of numbers in *any* finite representation scheme.
> No matter -what- representation scheme you come up with, if it
> must store numbers in a finite amount of space, there will be
> some numbers that will not be exactly representable. Any finite
> discrete storage mechanism will be able to store at most a portion
> of the countable infinity, but the number of real numbers
> is (see Cantor's Diagonalization Argument) the uncountable infinity.
> There are an uncountable infinity of real numbers between any two
> numbers representable in any finite numeric representation system.
>
> Boiling this down into simpler terms:
>
> =A0 Never Do An Exact Comparison Of Floating Point Numbers
>
> If you want to know if two floating point numbers are equal and
> they were produced through even the -slightest- difference in
> methods (and that can include hidden compiler optimizations),
> then you must assume that even if the two expressions that
> produced the numbers were algebraically identical, that the
> bit-for-bit representation might differ slightly. So don't compare
> for equality: instead, check to see if the difference between
> the two numbers is sufficiently small to be negligible.
>
> --
> .signature note: I am now avoiding replying to unclear or ambiguous posti=
ngs.
> Please review questions before posting them. Be specific. Use examples of=
 what you mean,
> of what you don't mean. Specify boundary conditions, and data classes and=
 value
> relationships -- what if we scrambled your data or used -Inf, NaN, or com=
plex(rand,rand)?

Excellent answer, Walter, but you're feeding strawberries to swine.

Subject: boolean == gives wrong ans

From: Bruno Luong

Date: 2 Nov, 2008 13:15:05

Message: 4 of 4

"Seth" <seth@mech.ubc.ca> wrote in message <gejbuu$itl$1@fred.mathworks.com>...
> I am having this problem on two separate machines, both with R2007a installed:
>
> >> X = 0:.1:1
> >> .3 == X
> ans =
> 0 0 0 0 0 0 0 0 0 0 0
>

Here is a shorter answer. Do this:

X(4)-0.3

Bruno

Tags for this Thread

No tags are associated with 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