Re: ((a&&b)||c)==((a||c)&&(b||c)) is not true
- To: mathgroup at smc.vnet.net
- Subject: [mg62063] Re: ((a&&b)||c)==((a||c)&&(b||c)) is not true
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Thu, 10 Nov 2005 02:51:06 -0500 (EST)
- Organization: University of California, Berkeley
- References: <200511090845.DAA17387@smc.vnet.net> <email@example.com>
- Sender: owner-wri-mathgroup at wolfram.com
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.
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:
Next by thread: