# Simplify assumes Boolean 1 and 0 in logical expressions

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

-
Simplify@And[6, 4] doesn't "simplify" – belisarius has settled 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

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.

-
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 SystemBooleanDump and DiscreteMathDecisionDiagram 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.

-