14

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

Community
  • 1
István Zachar
  • 47,032
  • 20
  • 143
  • 291
  • 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
  • 2
    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

2 Answers2

8

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.

Simon Woods
  • 84,945
  • 8
  • 175
  • 324
  • 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
  • 2
    @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
  • 1
    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 00:26
4

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.

István Zachar
  • 47,032
  • 20
  • 143
  • 291