[Newbie] problem with conditional expression

 

> -----Original Message-----
> From: maxima-bounces at math.utexas.edu 
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Robert Dodier
> Sent: Thursday, March 22, 2007 8:28 AM
> To: fateman at cs.berkeley.edu
> Cc: Stavros Macrakis; maxima at math.utexas.edu
> Subject: Re: [Maxima] [Newbie] problem with conditional expression
> 
> On 3/21/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> 
> > There is a major difference between program control flow 
> and expression
> > evaluation.
> 
> All well and good. With this in mind let's return to our 
> canonical example.
> Why should
> 
>     plot2d (if x > 0 then 1 else 0, [x, -1, 1]);
> 
> trigger an error?

This presumably has to do with the evaluation of the first argument to
plot2d. Either it has to be delayed or not, depending on the mind-set of the
user. Since the program cannot read minds sufficiently well, it sometimes
does not do what the user wants.

If we intend for the first argument to plot2d to always be a function of 1
arg, then we could require this:

Plot2d(lambda([x],if x>0 then 1 else 0),[x,-1,1]);    which works fine.

I think romberg is set up to use functions this way.

As far as I'm concerned, this is orthogonal to partial evaluation.
Other operators on functions  (other than plot)  include sum, product,
integrate.  At least in principle.


> 
> > Saying that you treat this the same as P+1 is
> > obviously not a solution.
> 
> Obviously not. The point is even simplifying arithmetic expressions
> can have side effects. Yet that doesn't seem to stop us from allowing
> Maxima to simplify arithmetic. It needn't stop us from simplifying
> or evaluating conditional expressions.

It does when the result is some kind of quantum juxtaposition of returning
from a function or not.
That does not happen when you do arithmetic.  [arguably a potential division
by zero is similar, though].

> 
> > > > 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 ?
> >
> > No. If they could have been defined in terms of "if" I 
> would have used "if".
> 
> Really? The only discussion of provided/when on that page says
> "In particular it requires checking if a*b^2<0 or ..."

There is a difference between the English "if" and the English "or"  and the
operations in Maxima.
The answer is given as a "provided" form, and must be carried along that way
indefinitely or
 at least until one of the "when" clauses becomes true. The conditions are
not supposed to be re-evaluated as programming instructions.

By the way, consider this partial evaluation...
   If (f(x)) then if g(x) then if h(x) ....  )

Do you require that "if g(x) ...."  be simplified above, by the assumption
that f(x) is true?

In particular
    if f(x) then if not(f(x)) then h(x) else g(x) else r(x)
Could be

    if f(x) then g(x) else r(x)

Etc   (assuming I've gotten that right...).  Except for simple geometric
predicates,this is heavy going. And even for those, I suspect only Maple
handles that, and only for regions divided by straight lines or planes.

> 
> There's no discussion of incase.

I suspect we replaced incase with when.
See
http://mailgate.dada.net/sci/sci.math.symbolic/msg05772.html

For an example, though.
RJF