[Newbie] problem with conditional expression

Using conventional syntax like "if .. then  " just won't work, except in
trivial cases, in my opinion.

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.
2. f(x) is definitely not greater than 0.
3. it is not (yet) determined if f(x) is greater than 0 or not but might be
determined later.
4. is is sometimes <= and sometimes >, depending on global values not
mentioned.
5. the condition can be reduced to a simpler relation, g(x)>0 given partial
information on x.
6. f(x) may cause an error for particular values of x  (e.g. divide by zero)
when evaluated
7. f(x) has (other) side effects when evaluated

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


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


> -----Original Message-----
> From: maxima-bounces at math.utexas.edu 
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Robert Dodier
> Sent: Tuesday, March 20, 2007 9:06 PM
> To: Stavros Macrakis
> Cc: maxima at math.utexas.edu
> Subject: Re: [Maxima] [Newbie] problem with conditional expression
> 
> On 3/16/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> 
> > I really do understand the motivation for manipulable conditional
> > expressions -- I've been advocating them for years (in 
> fact, I think I
> > was the first to advocate them on this list).  I just don't 
> think they
> > should be the same thing as programming conditionals, because they
> > will lead to perverse results, e.g.
> >
> >       block([],
> >                  if x>3 then return(3),
> >                  5)
> >
> > always returns 5 (assuming x is undefined) with no 
> indication anything
> > was wrong.
> 
> This is a good example of the general principle I've been pushing:
> attempting to prevent stupidity also prevents cleverness.
> Cleverness is (among other things) being able to extrapolate from
> known examples and predict the result of ones that haven't been
> tried before. If Maxima handles partial evaluation of arithmetic and
> other basic stuff without trouble, one would expect that Maxima is
> happy with partial evaluation of conditionals as well. That's not a
> speculation on my part: the message from Hugo Coolens is only
> the most recent of various messages from people who didn't
> expect Maxima to reject a partially evaluated conditional.
> 
> > In fact, in general, I would like to be able to perform *partial
> > evaluation* on programs, but I don't want to do that by default.
> > Partial evaluation would make
> >
> >       assume(zzz>3)
> >
> >       for i thru zzz do p:p+i
> >
> > return something like
> >
> >       (p:p+6,
> >       for i from 4 thru zzz do p:p+1)
> >
> > Very nice, but not something I want from my default evaluator.
> 
> Neat. I'd like to see that too. That's exactly what I would expect to
> see by extrapolating from the way Maxima handles arithmetic:
> everything is an expression, and Maxima is happy with partial 
> evaluation.
> 
> FWIW
> Robert
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>