MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: ((a&&b)||c)==((a||c)&&(b||c)) is not true

  • To: mathgroup at
  • Subject: [mg62063] Re: ((a&&b)||c)==((a||c)&&(b||c)) is not true
  • From: Richard Fateman <fateman at>
  • Date: Thu, 10 Nov 2005 02:51:06 -0500 (EST)
  • Organization: University of California, Berkeley
  • References: <> <dksig6$k6l$>
  • Sender: owner-wri-mathgroup at

A good reason for Mathematica to fail to show that these
are the same, is that they are in some senses different.

These look like logical statements and as such they look like they
are logically identical, but these are actually
programs with short-circuit evaluation.

c[] := (Print[C_called]; True)
a[] := (Print[A_called]; False)
b[] := (Print[B_called]; True)
(a[] && b[]) || c[]
(a[] || c[]) && (b[] || c[])

They are different PROGRAMS.

Similar arguments could be made for arithmetic, but usually
they are not used for program control. If they are used inside
programs, they should not be simplified.

How about
p[]*p[].... which is simplified to p[]^2.

What if p[]:=(count++; 1)

How many times does count get incremented?

So if p[]*p[]  appears in the body of a program, it should
not be simplified.

(another example:    Simplify [ something_simplifies_to_zero[]*hairy_mess[] ]

should we never bother to evaluate hairy_mess[] ???

Mathematica does evaluate it, so far as I can tell.  Is this correct?
Unclear.  if hairy_mess came out Infinity, the result would be indeterminate,
I suppose.  )

  • Prev by Date: Re: Re: Mathematica 1
  • Next by Date: Re: Re: Re: Mathematica 1
  • Previous by thread: Re: ((a&&b)||c)==((a||c)&&(b||c))
  • Next by thread: Re: ((a&&b)||c)==((a||c)&&(b||c))