Mathematica Stack Exchange is a question and answer site for users of Mathematica. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Per this chat discussion and this previous question where I encountered the strange behaviour:

Simplify[1]          ==> 1       
And[0, 1]            ==> 0 && 1
Simplify[And[2, 3]]  ==> 2 && 3
Simplify[Not[0]]     ==> !0
FullSimplify[Not[0]] ==> True   (* expected !0, thanks Jens *)
Simplify[And[0, 1]]  ==> False   (* expected 0 && 1 *)
Simplify[And[1, 2]]  ==> 2       (* expected 1 && 2 *)
Simplify[Or[0, 1]]   ==> True    (* expected 0 || 1 *)

Simplify and Fullsimplify assume 0 -> False, 1 -> True in some logical expressions. Only Or and And are affected but not Not. This is certainly undocumented (or underdocumented), and I would say rather inconsistent. Please decide on whether it is a bug or not.

Present in versions 8 and 9 but not in version 7 (or before).

share|improve this question
Simplify@And[6, 4] doesn't "simplify" – Dr. belisarius Feb 16 '13 at 19:49
@belisarius It seems to consider 1 == True, 0 == False, but the rest of the integers are just numbers. It's not like in C where 2 would be interpreted as "true" too. This is why 1 && 2 --> 2 and not True. It's like True && 2 or True && expr. – Szabolcs Feb 16 '13 at 19:59
If not a bug, it certainly sounds like a "mis-feature". Surely this behavior was bound to cause someone problems sooner or later, especially being undocumented... – Oleksandr R. Feb 16 '13 at 20:04
Could be that some sort of inverse of Boole got into the default TransformationFunctions? – Szabolcs Feb 16 '13 at 20:09
up vote 6 down vote accepted

This happens because Simplify converts the expression to a BooleanFunction representation. Checking the documentation for BooleanFunction you find that:

Elements of both inputs and outputs can be specified either as True and False or as 1 and 0.

share|improve this answer
Wow. This is still scary. But then why does it not return True for Simplify[Not[0]]? – István Zachar Feb 16 '13 at 22:01
@IstvánZachar, looking at the Trace output, it seems that Not[0] doesn't get converted to a BooleanFunction. With the And[1,2] example there were heaps of calls to functions in System`BooleanDump and DiscreteMath`DecisionDiagram contexts, causing the conversion I mentioned. There was none of that for Not[0]. I agree this is scary, it makes for very inconsistent behaviour. – Simon Woods Feb 16 '13 at 22:21
@IstvánZachar But FullSimplify[Not[0]] does return True -- "fortunately." Maybe better use FullSimplify for more consistency. – Jens Feb 16 '13 at 22:57
Sounds like the final outcome may not be intentional, just a side effect of how BooleanFunction works. @István Perhaps it worth letting support know about it in case it wasn't intentional. This sort of undocumented behaviour is not what one would hope to bump into. – Szabolcs Feb 17 '13 at 0:26

Technical Support responded:

"[Developers] mentioned to me that indeed it is the case that BooleanFunction treats 1 as True and 0 as False, and these "simplifications" occur only when the expression is converted to BooleanFunction format.

If any changes to the documentation or these boolean operators I will certainly let you know."

From this I assume that this is known and it is the expected behaviour. I also assume, that if anything changes in the future that most likely will be the Documentation and not the behaviour.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.