Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2009

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

Search the Archive

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

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

danl at wolfram.com wrote:
>> ?===
>> 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.

It had been pointed out to me that only ComplexInfinity seems to behave 
in this way. I suspect there was a time when we changed 
Infinity==Infinity behavior (and a code change message I have seen seems 
to bear out this suspicion), but I cannot verify that such a change ever 
went into a released version of Mathematica. So I was probably just 
muddying the waters there.

That said, playing with infinities is a tricky business, and considering 
them as equal when their directions agree is itself something of a 
design decision.


> 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.

I guess I should mention that this "problem is at your end" was intended 
as irony. Documentation that uses non-identical meanings of "identical", 
with otherwise virtually identical wording, is in need of some serious 
spanking. I have filed a bug report about this.


Daniel Lichtblau
Wolfram Research


  • Prev by Date: Re: generating submultisets with repeated elements
  • Next by Date: Simple Optimization Problem: Using BinCounts within objective
  • Previous by thread: Re: Re: confused about == vs === in this equality
  • Next by thread: Re: Re: confused about == vs === in this equality