[Newbie] problem with conditional expression

There is a major difference between program control flow and expression
evaluation.
There is also a large literature on partial evaluation of programs, though
it has faded in popularity.
Koushek Sen has done recent work on "concolic" execution, however.

Evaluating an expression P may do many things in maxima, and then return a
value.  If that value is neither true nor false, and P is used as the
predicate of a conditional IF, then you will have to undo all that
computation in P in order to leave it "unchanged".  Or insist that P is a
"pure function". This is possible but a novelty in Maxima.  And evaluating P
may divide by zero, too. Saying that you treat this the same as P+1 is
obviously not a solution.

You might wish to say this

F(x)=g(x) provided h(x) is true
   
    = m(x) provided r(x) is true.

If h(x) and r(x) are both true,  m(x) and g(x) should be equal...
  If h(x) or r(x) produce non-true, or perhaps fail to terminate, that is
OK, as long as the other one does not.




Evaluating   if (x>0) then return(a)

"partially" presents a problem: either one leaves the control flow to the
next statement, or exits the scope of the program, returning the value of a.
Claiming that the result of the "if" is to just leave the "if" unevaluated,
in place, means you do not return the value of a. Thus you have acted as
though x>0 was false.
Look at case 3 below in this context. 

 

> -----Original Message-----
> From: maxima-bounces at math.utexas.edu 
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Robert Dodier
> Sent: Wednesday, March 21, 2007 7:17 PM
> 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:
> 
> > 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 ?

No. If they could have been defined in terms of "if" I would have used "if".
RJF

> 
> FWIW
> Robert
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>