confused about == vs === in this equality
in [Mathematica]
|
From: Drago Ganic on 13 Oct 2009 23:18 Hi Andrzej, Sorry for my late reply, I was not able to respond before. Let's do not be concerned about the distinction (if any) between Missing and Null, and assume that they both represent missing "values". I do agree with you that Mathematica handles Indeterminate "values" well, but would stress that Indeterminate is, as currently designed, applicable only to >>numbers<<. On the other hand, any data type (strings, graphics, images, music, notebooks,) can be Missing. So, Missing should behave similar to Indeterminate but applicable to any kind of data. Missing data are usually imported in the system (e.g. xxxData[] functions in Mathematica). The point is that any variable of any kind can be missing for various reasons and all the Mathematica functions should handle this fact (not only graphical as is currently the case). The key word is propagation. Like propagation of errors, missing data should propagate in calculations (the erros is infinite !). Hence, the Null/Missing "value" is a generalization of the Indeterminate "value". But the behavior in Mathematica is not same - the Indeterminate "value" propagates through all numerical operations/functions and Missing does not propagate through all functions. This behavior is crucial to missing values. Examples: This is OK: In[1]:= 2 + Indeterminate Out[1]= Indeterminate In[2]:= Sin[Indeterminate] Out[2]= Indeterminate Is this OK?: In[3]:= 2 + Missing[] Out[3]= 2 + Missing[] In[4]:= StringJoin["Hello", Missing[]] During evaluation of In[2]:= StringJoin::string: String expected at position 2 in Hello<>Missing[]. Out[4]= "Hello" <> Missing[] Why is Plus overloaded (for Indeterminate) and not for Missing? Why is StringJoin not overloaded for Missing? The same questions apply to Equal. BR, Drago P.S.: I my posts I make those kind of errors all the time. Do not worry, people read this newsgroup and they parse text quite well :-) -----Original Message----- From: Andrzej Kozlowski [mailto:akoz(a)mimuw.edu.pl] Sent: Friday, October 09, 2009 7:40 AM To: Andrzej Kozlowski Cc: Drago Ganic; mathgroup(a)smc.vnet.net Subject: Re: Re: confused about == vs === in this equality In my post below I wrote "missing" instead of "Missing" and "Intermedite" instead of "Indeterminante" (3 times!) How much more mindless can one get? Andrzej On 9 Oct 2009, at 11:14, Andrzej Kozlowski wrote: > Hi Drago, > > I have to say I am not convinced about Null (I have not thought > about missing). My reason is simply this: in the case of > Intermediate it is easy to construct two completely unrelated > expressions which will evalute to Intermediate. Having > Intermediate==Intermediate evaluate to True would lead to equality > between these expressions also evaluating to True. Conceivably this > could be "hidden" within some complicated computation and result in > a totally misleading final result. > > On the other hand I don't know of anything but Null that *evaluates" > to Null. If you can produce two obviously unrelated expressions both > of which evaluate to Null then indeed I will agree with you. As it > is I think the current situation is just fine. > > Andrzej > > > On 8 Oct 2009, at 20:50, Drago Ganic wrote: > >> Hi Andrzej, >> there is one function (Missing) and one symbol (Null) which >> >>should<< >> behave the same as Indetereminate and ComplexInfinity but >> unfortunatly does >> not. >> >> In[1]:= Null == Null >> Out[1]= True >> >> In[2]:= Missing[] == Missing[] >> Out[2]= True >> >> Null is Mathematica legacy which has basically the same meaning as >> Missing[] >> (or maybe Missing["Nonexistent"]). Missing incorporates >> Indetereminate via >> Missing["Indeterminate"]. >> All of those (Indetereminate & ComplexInfinity for numeric data and >> Null/Missing for any kind of data), are so called "null values" in >> database >> systems and for them the Equal and other logical connectivities >> (And, Or, >> Not, etc.) are overloaded. Unfortunatly this is not the case in >> Mathematica. >> >> Greetings from Croatia, >> Drago Ganic >> >> "Andrzej Kozlowski" <akoz(a)mimuw.edu.pl> wrote in message >> news:hacmoa$sko$1(a)smc.vnet.net... >>> I amy be taking a bit of a risk here, but I would guess that >>> ComplexInfinity and Indeterminate are the only symbols in >>> Mathematica >>> with this property, that is we get: >>> >>> a=ComplexInfinity >>> >>> TrueQ[Unevaluated[x == x] /. x -> a] >>> >>> False >>> >>> a = Indeterminate; >>> >>> TrueQ[Unevaluated[x == x] /. x -> a] >>> >>> False >>> >>> I believe that there are no other symbols for which this happens (?) >>> (If I am right and it is the only one that there is no need to be >>> seriously concerned or, as you say, "careful" about this issue.) >>> >>> Why does and Indeterminate and ComplexInfinity behave in this way? >>> Of >>> course this is a matter of design and not (for example) >>> mathematics so >>> the question really is, is this a reasonable and useful thing rather >>> than if it is right. I guess it is pretty clear that since >>> Indeterminate refers to a magnitude that cannot be determined, you >>> would not really want to assert that two expressions, both of which >>> evaluate to Indeterminate, are in any sense equal. For example it >>> would seem very strange if >>> >>> Infinity - Infinity == Infinity/Infinity >>> >>> returned True (as would have to be the case if >>> Indeterminate==Indeterminate returned True). Similar considerations >>> perhaps apply to ComplexInfinity, which refers to a complex quantity >>> with infinite magnitude but with an indeterminate argument. >>> (However, >>> I am less convinced of that in the case of ComplexInfinty than in >>> the >>> case of Indeterminate, because ComplexInfinity has a natural >>> interpretation as a unique point on the Riemann sphere). >>> >>> (Of course === asks quite a different question and there is no doubt >>> that when you have identical expressions on both sides of === the >>> answer should always be True.) >>> >>> Andrzej Kozlowski >>> >>> >>> >>> >>> >>> >>> On 4 Oct 2009, at 18:35, Nasser Abbasi 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 >>>> >>>> >>>> __________ Information from ESET NOD32 Antivirus, version of virus >>>> signature database 4478 (20091003) __________ >>>> >>>> The message was checked by ESET NOD32 Antivirus. >>>> >>>> http://www.eset.com >>>> >>>> >>>> >>>> >>> >>> >> >> >
From: Andrzej Kozlowski on 14 Oct 2009 07:56
Hi Drago, I do not disagree with you about Missing[], but I have to admit I can't take this issue seriously. The only thing I really care about is if this behavior could ever cause any problem or inconvenience to a user and you have not suggested any such way. In the case of Indeterminate I think I can imagine ways in which behavior other than the current one would be troublesome. Some functions in Mathematica, such as Solve, after finding a solution of an equation perform verification. If Indeterminate == Indeterminate returned True you could get into a situation where both sides of an equation returned Indeterminate but Solve would consider the equation as verified. That could certainly be seriously misleading. Alternatively, if Indeterminate==Indeterminate returned False, the solution would be rejected without your knowing exactly why. The current approach avoids both problems. Here is an example: Solve[x*(x + 1 + 1/x) == x*(x + 2 + 1/x), x, VerifySolutions -> True] Solve::verif:Potential solution {x->0} (possibly discarded by verifier) should be checked by hand. May require use of limits. >> {} Using VerifySolutions -> False we get: Solve[x*(x + 1 + 1/x) == x*(x + 2 + 1/x), x, VerifySolutions -> False] {{x->0}} which, depending on the situation, may or may not be what one wants. In any case, it seems better to know. So if you can produce an example of this kind for Missing I may change my mind, but as it is, I think your point may be correct but unimportant. Andrzej On 14 Oct 2009, at 04:40, Drago Ganic wrote: > Hi Andrzej, > > Sorry for my late reply, I was not able to respond before. > > Let's do not be concerned about the distinction (if any) between > Missing and > Null, and assume that they both represent missing "values". > > I do agree with you that Mathematica handles Indeterminate "values" well, > but would > stress that Indeterminate is, as currently designed, applicable only > to >>> numbers<<. On the other hand, any data type (strings, graphics, >>> images, > music, notebooks,) can be Missing. So, Missing should behave similar > to > Indeterminate but applicable to any kind of data. > > Missing data are usually imported in the system (e.g. xxxData[] > functions in > Mathematica). The point is that any variable of any kind can be > missing for > various reasons and all the Mathematica functions should handle this fact > (not only > graphical as is currently the case). The key word is propagation. Like > propagation of errors, missing data should propagate in calculations > (the > erros is infinite !). > > Hence, the Null/Missing "value" is a generalization of the > Indeterminate > "value". But the behavior in Mathematica is not same - the Indeterminate > "value" > propagates through all numerical operations/functions and Missing > does not > propagate through all functions. This behavior is crucial to missing > values. > > Examples: > > This is OK: > > In[1]:= 2 + Indeterminate > Out[1]= Indeterminate > > In[2]:= Sin[Indeterminate] > Out[2]= Indeterminate > > Is this OK?: > In[3]:= 2 + Missing[] > Out[3]= 2 + Missing[] > > In[4]:= StringJoin["Hello", Missing[]] > During evaluation of In[2]:= StringJoin::string: String expected at > position > 2 in Hello<>Missing[]. > Out[4]= "Hello" <> Missing[] > > Why is Plus overloaded (for Indeterminate) and not for Missing? Why is > StringJoin not overloaded for Missing? The same questions apply to > Equal. > > > BR, > Drago > > P.S.: I my posts I make those kind of errors all the time. Do not > worry, > people read this newsgroup and they parse text quite well :-) > > > -----Original Message----- > From: Andrzej Kozlowski [mailto:akoz(a)mimuw.edu.pl] > Sent: Friday, October 09, 2009 7:40 AM > To: Andrzej Kozlowski > Cc: Drago Ganic; mathgroup(a)smc.vnet.net > Subject: Re: Re: confused about == vs === in this equality > > In my post below I wrote "missing" instead of "Missing" and > "Intermedite" instead of "Indeterminante" (3 times!) How much more > mindless can one get? > > Andrzej > > > On 9 Oct 2009, at 11:14, Andrzej Kozlowski wrote: > >> Hi Drago, >> >> I have to say I am not convinced about Null (I have not thought >> about missing). My reason is simply this: in the case of >> Intermediate it is easy to construct two completely unrelated >> expressions which will evalute to Intermediate. Having >> Intermediate==Intermediate evaluate to True would lead to equality >> between these expressions also evaluating to True. Conceivably this >> could be "hidden" within some complicated computation and result in >> a totally misleading final result. >> >> On the other hand I don't know of anything but Null that *evaluates" >> to Null. If you can produce two obviously unrelated expressions both >> of which evaluate to Null then indeed I will agree with you. As it >> is I think the current situation is just fine. >> >> Andrzej >> >> >> On 8 Oct 2009, at 20:50, Drago Ganic wrote: >> >>> Hi Andrzej, >>> there is one function (Missing) and one symbol (Null) which >>>>> should<< >>> behave the same as Indetereminate and ComplexInfinity but >>> unfortunatly does >>> not. >>> >>> In[1]:= Null == Null >>> Out[1]= True >>> >>> In[2]:= Missing[] == Missing[] >>> Out[2]= True >>> >>> Null is Mathematica legacy which has basically the same meaning as >>> Missing[] >>> (or maybe Missing["Nonexistent"]). Missing incorporates >>> Indetereminate via >>> Missing["Indeterminate"]. >>> All of those (Indetereminate & ComplexInfinity for numeric data and >>> Null/Missing for any kind of data), are so called "null values" in >>> database >>> systems and for them the Equal and other logical connectivities >>> (And, Or, >>> Not, etc.) are overloaded. Unfortunatly this is not the case in >>> Mathematica. >>> >>> Greetings from Croatia, >>> Drago Ganic >>> >>> "Andrzej Kozlowski" <akoz(a)mimuw.edu.pl> wrote in message >>> news:hacmoa$sko$1(a)smc.vnet.net... >>>> I amy be taking a bit of a risk here, but I would guess that >>>> ComplexInfinity and Indeterminate are the only symbols in >>>> Mathematica >>>> with this property, that is we get: >>>> >>>> a=ComplexInfinity >>>> >>>> TrueQ[Unevaluated[x == x] /. x -> a] >>>> >>>> False >>>> >>>> a = Indeterminate; >>>> >>>> TrueQ[Unevaluated[x == x] /. x -> a] >>>> >>>> False >>>> >>>> I believe that there are no other symbols for which this happens >>>> (?) >>>> (If I am right and it is the only one that there is no need to be >>>> seriously concerned or, as you say, "careful" about this issue.) >>>> >>>> Why does and Indeterminate and ComplexInfinity behave in this way? >>>> Of >>>> course this is a matter of design and not (for example) >>>> mathematics so >>>> the question really is, is this a reasonable and useful thing >>>> rather >>>> than if it is right. I guess it is pretty clear that since >>>> Indeterminate refers to a magnitude that cannot be determined, you >>>> would not really want to assert that two expressions, both of which >>>> evaluate to Indeterminate, are in any sense equal. For example it >>>> would seem very strange if >>>> >>>> Infinity - Infinity == Infinity/Infinity >>>> >>>> returned True (as would have to be the case if >>>> Indeterminate==Indeterminate returned True). Similar considerations >>>> perhaps apply to ComplexInfinity, which refers to a complex >>>> quantity >>>> with infinite magnitude but with an indeterminate argument. >>>> (However, >>>> I am less convinced of that in the case of ComplexInfinty than in >>>> the >>>> case of Indeterminate, because ComplexInfinity has a natural >>>> interpretation as a unique point on the Riemann sphere). >>>> >>>> (Of course === asks quite a different question and there is no >>>> doubt >>>> that when you have identical expressions on both sides of === the >>>> answer should always be True.) >>>> >>>> Andrzej Kozlowski >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 4 Oct 2009, at 18:35, Nasser Abbasi 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 >>>>> >>>>> >>>>> __________ Information from ESET NOD32 Antivirus, version of virus >>>>> signature database 4478 (20091003) __________ >>>>> >>>>> The message was checked by ESET NOD32 Antivirus. >>>>> >>>>> http://www.eset.com >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > |