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>

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

**Re: Help Creating 3D List Line Plot**

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

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