[Date Index]
[Thread Index]
[Author Index]
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**
| |