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:
What am I missing here?

Subject: What am I missing here?

From: Gautam Sethi

Date: 27 Jan, 2013 00:13:27

Message: 1 of 6

Folks, this is driving me nuts! Can someone explain what may be going on?

>> X = [0 .1 .2 .3 .4]

X =

         0 0.1000 0.2000 0.3000 0.4000

>> X(4) == .3

ans =

     1

>> Y = [0:.1:.4]

Y =

         0 0.1000 0.2000 0.3000 0.4000

>> Y(4) == .3

ans =

     0

>> intersect(X,Y)

ans =

         0 0.1000 0.2000 0.4000

>> X(2) == .1

ans =

     1

>> Y(2) == .1

ans =

     1

Subject: What am I missing here?

From: Gautam Sethi

Date: 27 Jan, 2013 00:18:42

Message: 2 of 6

On Saturday, January 26, 2013 7:13:27 PM UTC-5, Gautam Sethi wrote:
> Folks, this is driving me nuts! Can someone explain what may be going on?
>
>
>
> >> X = [0 .1 .2 .3 .4]
>
>
>
> X =
>
>
>
> 0 0.1000 0.2000 0.3000 0.4000
>
>
>
> >> X(4) == .3
>
>
>
> ans =
>
>
>
> 1
>
>
>
> >> Y = [0:.1:.4]
>
>
>
> Y =
>
>
>
> 0 0.1000 0.2000 0.3000 0.4000
>
>
>
> >> Y(4) == .3
>
>
>
> ans =
>
>
>
> 0
>
>
>
> >> intersect(X,Y)
>
>
>
> ans =
>
>
>
> 0 0.1000 0.2000 0.4000
>
>
>
> >> X(2) == .1
>
>
>
> ans =
>
>
>
> 1
>
>
>
> >> Y(2) == .1
>
>
>
> ans =
>
>
>
> 1

Even more bizarre:

>> intersect(X,round(Y*10)/10)

ans =

         0 0.1000 0.2000 0.3000 0.4000

Subject: What am I missing here?

From: Roger Stafford

Date: 27 Jan, 2013 01:53:06

Message: 3 of 6

Gautam Sethi <gautamsethi@gmail.com> wrote in message <e0cb6636-306e-4239-a3c6-be062decdcea@googlegroups.com>...
> Folks, this is driving me nuts! Can someone explain what may be going on? ......
- - - - - - - - -
  Welcome to the world of binary arithmetic, which is what your computer is using. It cannot get an exact result for .1, .2, .3, and .4, just as your decimal calculator cannot get an exact result for 1/3. All of your findings stem from that and the different roundings that are a consequence. Remember that the "==" and 'intersect' operations expect exact equality right down to the smallest bit.

Roger Stafford

Subject: What am I missing here?

From: Gautam Sethi

Date: 27 Jan, 2013 03:17:11

Message: 4 of 6

On Saturday, January 26, 2013 8:53:06 PM UTC-5, Roger Stafford wrote:
> Gautam Sethi <gautamsethi@gmail.com> wrote in message <e0cb6636-306e-4239-a3c6-be062decdcea@googlegroups.com>...
>
> > Folks, this is driving me nuts! Can someone explain what may be going on? ......
>
> - - - - - - - - -
>
> Welcome to the world of binary arithmetic, which is what your computer is using. It cannot get an exact result for .1, .2, .3, and .4, just as your decimal calculator cannot get an exact result for 1/3. All of your findings stem from that and the different roundings that are a consequence. Remember that the "==" and 'intersect' operations expect exact equality right down to the smallest bit.
>
>
>
> Roger Stafford

Sure, but why pick on poor .3? Why do I not see the same issue for .2 or .4 or the other numbers? And if this really the root of the issue, shouldn't the operator == be equivalent to <= eps or something similar?

Subject: What am I missing here?

From: Roger Stafford

Date: 27 Jan, 2013 06:50:08

Message: 5 of 6

Gautam Sethi <gautamsethi@gmail.com> wrote in message <9fc57693-fa60-4687-a922-e79e26746b69@googlegroups.com>...
> Sure, but why pick on poor .3? Why do I not see the same issue for .2 or .4 or the other numbers? And if this really the root of the issue, shouldn't the operator == be equivalent to <= eps or something similar?
- - - - - - - - -
  When you write X = [0 .1 .2 .3 .4] as compared with Y = 0:.1:.4 some of the corresponding elements may come out the same and some different depending on the arithmetic processes involved in the colon operation as opposed to expressing the number directly. Therefore some of them will satisfy the logical equality and some not. However in no case are these four ideal nonzero decimal fractions represented exactly. I suggest you use "format hex" to show the results of both X and Y to see directly those differences and/or similarities.

  As to why Mathworks doesn't make an automatic allowance for these small differences in the logical equality operation, it is undoubtedly because the matlab compiler has no way of knowing what kind of error tolerances the user wants to allow and what differences might be significant in the results. Hence they leave such matters to the user to set up.

  The important lesson to learn here is that the logical equality operation and other operations that require exactness should not be used on floating point values that are subject to round-off error.

Roger Stafford

Subject: What am I missing here?

From: Steven_Lord

Date: 28 Jan, 2013 16:03:41

Message: 6 of 6



"Gautam Sethi" <gautamsethi@gmail.com> wrote in message
news:9fc57693-fa60-4687-a922-e79e26746b69@googlegroups.com...
> On Saturday, January 26, 2013 8:53:06 PM UTC-5, Roger Stafford wrote:
>> Gautam Sethi <gautamsethi@gmail.com> wrote in message
>> <e0cb6636-306e-4239-a3c6-be062decdcea@googlegroups.com>...
>>
>> > Folks, this is driving me nuts! Can someone explain what may be going
>> > on? ......
>>
>> - - - - - - - - -
>>
>> Welcome to the world of binary arithmetic, which is what your computer
>> is using. It cannot get an exact result for .1, .2, .3, and .4, just as
>> your decimal calculator cannot get an exact result for 1/3. All of your
>> findings stem from that and the different roundings that are a
>> consequence. Remember that the "==" and 'intersect' operations expect
>> exact equality right down to the smallest bit.
>>
>>
>>
>> Roger Stafford
>
> Sure, but why pick on poor .3?

We don't "pick on" poor 0.3 any more than decimal calculations "pick on" 2/3
(which when rounded is 0.6666 ... *snip arbitrary number of 6's* ... 67.)

> Why do I not see the same issue for .2 or .4 or the other numbers?

Because the way we calculate the result of the colon operator happens to
work out that the roundoff error results in the exact double precision
representation of 0.2 and 0.4.

For more information, see question 1 in the Math/Algorithms section of the
newsgroup FAQ and the references it includes (particularly the Cleve's
Corner article.)

http://matlab.wikia.com/wiki/FAQ

> And if this really the root of the issue, shouldn't the operator == be
> equivalent to <= eps or something similar?

No. Assuming neither a nor b are NaN, exactly one of the following relations
should hold:

a == b
a < b
b < a

This is the law of trichotomy.

http://en.wikipedia.org/wiki/Trichotomy_%28mathematics%29

If we made == have a "fudge factor" then trichotomy would break down because
a == b and a < b (or a == b and b < a) could both be true. This could break
user code that assumed trichotomy.

In addition, section 5.7 of the IEEE 754-1985 floating-point standard
states:

"It shall be possible to compare floating-point numbers in all supported
formats, even if the operands' formats differ. Comparisons are exact and
never overflow nor underflow."

To reiterate Roger's statement: welcome to the world of floating-point
arithmetic.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

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