Subject: [Newbie] problem with conditional expression
From: Robert Dodier
Date: Wed, 21 Mar 2007 20:16:49 -0600
On 3/21/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> Using conventional syntax like "if .. then " just won't work, except in
> trivial cases, in my opinion.
Then we should apply it to the trivial cases, and punt on the rest.
Maxima already does that in other contexts. Then the game is
to expand the scope of the known cases. I don't see any problem
with that.
I'm rather puzzled by the following.
> The logic available in such a construction is 2-valued, and symbolic
> execution requires something more.
>
> If f(x)>0 then .... is to be partially evaluated you must provide for the
> possibility that
>
> 1. f(x) is definitely greater than 0.
if f(x) > 0 then foo else bar => foo
> 2. f(x) is definitely not greater than 0.
... => bar
> 3. it is not (yet) determined if f(x) is greater than 0 or not but might be
> determined later.
... => if f(x) > 0 then foo else bar (no change)
> 4. is is sometimes <= and sometimes >, depending on global values not
> mentioned.
Evaluate to a definite result if the current values of the globals
permits it. Otherwise, no change.
> 5. the condition can be reduced to a simpler relation, g(x)>0 given partial
> information on x.
... => if g(x) > 0 then foo else bar
> 6. f(x) may cause an error for particular values of x (e.g. divide by zero)
> when evaluated
Take this possibility into account when f(x) + 1 takes it into account.
> 7. f(x) has (other) side effects when evaluated
Take side effects into account when evaluation of f(x) + 1 takes them
into account.
As it happens, at present in boolsimp.lisp, predicates are evaluated
but alternatives (then or else) are only simplified unless the predicate
evaluates to true or false. There is more about this in the comment
header of boolsimp.lisp.
> (and perhaps other alternatives).
>
> Thus if you insist on partial evaluation, you might need to expand the "if"
> into a 7-way branch. Or more.
I'm not convinced any additional branches are needed, but if they
are, then I don't see any problem with evaluating if x > 0 then 1 else 0
to however many branches are deemed necessary.
> Alternative syntax (e.g. such as is used in Tilu output) or something else,
> like guarded commands, could make sense. Key words like "incase" and
> "provided/ when" are used by tilu.
> http://www.cs.berkeley.edu/~fateman/tilu.examp2.html
Is there a way to define incase and provided/when without using if ?
FWIW
Robert