# Why does Equal["string", False] not evaluate to False?

Why does Equal["string", False] not evaluate to False? I would have thought Mathematica could prove that these two things are not equal.

• I would think that Mathematica is unable to compare a string with a boolean; it's non-sensical. Does this usually work when comparing distinct types of variables? Commented Jun 1, 2014 at 3:31

I think it is because Equal treats symbols as having an indeterminate value, but as @M_goldberg points out this isn't the whole story.

Equal["foo", foo]
(* "foo" == foo *)


This is true when one side is numeric (but not a number per se) and the other is a string:

Equal["foo", GoldenRatio]
(* "foo" == GoldenRatio *)

Equal["foo", Sqrt[2]]  (* Sqrt can be overridden *)
(* "foo" == Sqrt[2] *)

Equal[Sqrt, Sqrt[2]]
(* Sqrt == Sqrt[2] *)


Equal also chokes on unevaluated, nonnumeric function expressions, including nonsense such as this:

Equal[2, 2[2]]
(* 2 == 2[2] *)


Equal will evaluate if both sides are numeric; also if both sides are determinate, such as comparing a string and a number. It also evaluates to True if the symbols are the same, or if one is True and the other is False. (There may be other exceptions to this rule. Thanks to @m_goldberg for point out these examples.)

Equal["foo", N@Sqrt[2]]
(* False *)

Equal[True, False]
(* False *)

Equal[x, x]
(* True *)


Override Sqrt:

Block[{Sqrt = "foo" &},
Equal["foo", Sqrt[2]]
]
(* True *)

• Interesting. What would be the definition for "determinate"?
– eldo
Commented May 31, 2014 at 20:55
• I suppose String or one of the number types. I don't think they have a name. It's not, for example, "atomic." Commented May 31, 2014 at 21:23
• It can't be as simple as "Equal treats symbols as having an indeterminate value". Consider, Equal[False, #] & /@ {True, False} which returns {False, True}. Further, Equal clearly calls on SameQ and returns True if SameQ does; i.e., Equal[x, x] is always True for any x, including symbols. Commented May 31, 2014 at 21:51
• Equal also considers True and False to be comparable with each other. As far as I can tell, it always remains unevaluated when the comparands are not in the same category, but what it considers a category is unclear. However it does seem that strings are in the same category as (unassigned) symbols as far as Equal is concerned, even if other functions treat them as distinct. x == x and "x" == "x" both give True. It's perhaps not as simple as falling through to SameQ, as the example in my comment under the other answer shows. Commented May 31, 2014 at 21:53
• "foo" == 1 giving False while False == 1 remains unevaluated is a puzzling case, however. Commented May 31, 2014 at 21:58

You have to use "===" like

 "string" === False


Or

SameQ["string",False]

• I think OP probably knows this. The question is, why doesn't Equal give the same result? SameQ doesn't express a mathematical relation. Commented May 31, 2014 at 15:11
• @OleksandrR. Quite frankly: I don't know, all the more so since "string"==1 returns False.
– eldo
Commented May 31, 2014 at 15:36
• Indeed, it's a puzzling inconsistency and IMO a good question. The answer seems to be something to do with strings being treated as symbols in some contexts but not others. For example, Solve can't solve with respect to strings, but Assuming["string" == False, Refine["string" == False]] works the same with a string as it would with any other symbol. Commented May 31, 2014 at 16:37
• @OleksandrR. FWIW: Assuming["string" == False, Refine["string" == False]] calls PolynomialReduce[-"string" + False, {-"string" + False}, {False}, MonomialOrder -> DegreeReverseLexicographic], Commented Jun 1, 2014 at 0:19