Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: confused about == vs === in this equality

• To: mathgroup at smc.vnet.net
• Subject: [mg103750] Re: [mg103732] confused about == vs === in this equality
• From: danl at wolfram.com
• Date: Mon, 5 Oct 2009 07:36:22 -0400 (EDT)
• References: <20091003104738.LCJ3I.416659.imail@eastrmwml34>

> ?===
> lhs===rhs yields True if the expression lhs is identical to rhs, and
> yields
> False otherwise.
>
> ?==
> lhs==rhs returns True if lhs and rhs are identical.
>
> But looking at this example:
>
> a = ComplexInfinity;
>  If[a == ComplexInfinity, Print["YES"]]
>
> Expecting it would print "YES", but it does not. it just returns the whole
> thing unevaluated? But
>
> If[a === ComplexInfinity, Print["YES"]]
>
> does return YES.
>
> I guess I am a little confused about the "expression" bit in the
> definition.
>
> So, when using the 3"=", it is looking at the _value_ of the expression,
> but
> when using the 2"=", it is looking at the expression _as it is_, i.e.
> without evaluating it?  Is this the difference?  I've always used the 2"="
> for equality, now I have to be more careful which to use.
>
> --Nasser

First some background. Usually SameQ (===) is more stringent than Equal
(==). That is to say, things might pass the Equal test but fail the SameQ
test. Here are some examples.

In[62]:= 2 == 2.0
Out[62]= True

In[63]:= 2 === 2.0
Out[63]= False

In[64]:= Sin[2]^2 + Cos[2]^2 == 1
Out[64]= True

In[66]:= Sin[2]^2 + Cos[2]^2 === 1
Out[66]= False

In[68]:= GoldenRatio == 1/2 + Sqrt[5]/2
Out[68]= True

In[69]:= GoldenRatio === 1/2 + Sqrt[5]/2
Out[69]= False

There are exceptions, and DirectedInfinity[] (the InputForm of
ComplexInfinity) is one such. In this case it is SameQ, but not Equal, to
itself. To try to make sense of this, consider instead Indeterminate. I
think it is uncontroversial that Indeterminate should not be deemed Equal
to itself. But it is the same expression as itself, therefore SameQ to
itself.

The decision, which I believe only goes back a few versions, was to also
treat infinities in that way. From a mathematical point of view this makes
sense, and it may well be useful in the innards of some Limit code in
avoiding what would be incorrect cancellations. (Though I have worked on
that code, I do not recall all specifics, but I think we always carefully
guarded against this.)

This has its shortcomings. For example, it is not uncommon to check
whether precision is finite, and handle infinite precision input
differently from finite. At one time I had to change code that had
constructs like
If [prec==Infinity,...]
to use SameQ instead of Equal.

My point being, as a design decision this is something of a question call.
I think the choice we made is the better one, but I realize there are
arguments against it, and there are examples where it can cause trouble if
one is not aware of the issue (or has inconveniently forgotten the lurking
"gotcha").

Let me address, finally, your reading of the documentation. I can only
conclude that the problem is at your end: clearly you cannot tell the
difference between "identical" and "identical". I'll report this as a
documentation bug of some sort.


Daniel Lichtblau
Wolfram Research

• Follow-Ups:
  • Re: Re: confused about == vs === in this equality
    • From: Daniel Lichtblau <danl@wolfram.com>
  • Re: Re: confused about == vs === in this equality
    • From: Andrzej Kozlowski <akoz@mimuw.edu.pl>