"Gautam Sethi" <gautamsethi@gmail.com> wrote in message
news:9fc57693fa604687a922e79e26746b69@googlegroups.com...
> On Saturday, January 26, 2013 8:53:06 PM UTC5, Roger Stafford wrote:
>> Gautam Sethi <gautamsethi@gmail.com> wrote in message
>> <e0cb6636306e4239a3c6be062decdcea@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 7541985 floatingpoint standard
states:
"It shall be possible to compare floatingpoint 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 floatingpoint
arithmetic.

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