15
$\begingroup$

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

Improve this question
$\endgroup$
4
  • $\begingroup$ Simplify@And[6, 4] doesn't "simplify" $\endgroup$
    – Dr. belisarius
    Commented Feb 16, 2013 at 19:49
  • $\begingroup$ @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. $\endgroup$
    – Szabolcs
    Commented Feb 16, 2013 at 19:59
  • 2
    $\begingroup$ 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... $\endgroup$
    – Oleksandr R.
    Commented Feb 16, 2013 at 20:04
  • $\begingroup$ Could be that some sort of inverse of Boole got into the default TransformationFunctions? $\endgroup$
    – Szabolcs
    Commented Feb 16, 2013 at 20:09

2 Answers 2

Reset to default
9
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Wow. This is still scary. But then why does it not return True for Simplify[Not[0]]? $\endgroup$
    – István Zachar
    Commented Feb 16, 2013 at 22:01
  • 2
    $\begingroup$ @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. $\endgroup$
    – Simon Woods
    Commented Feb 16, 2013 at 22:21
  • $\begingroup$ @IstvánZachar But FullSimplify[Not[0]] does return True -- "fortunately." Maybe better use FullSimplify for more consistency. $\endgroup$
    – Jens
    Commented Feb 16, 2013 at 22:57
  • 1
    $\begingroup$ 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. $\endgroup$
    – Szabolcs
    Commented Feb 17, 2013 at 0:26
5
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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