Carl McTague wrote:
> Hi everybody!
......
> behave the same. However, the following is still causing cognitive
> dissonance for me:
>
> (C52) lambda([x], if x>0 then true else false)(a);
>
> MACSYMA was unable to evaluate the predicate:
>
> ** error while printing ERROR message **
> MACSYMA was unable to evaluate the predicate:~%~M
> #0: LAMBDA([x],IF x > 0 THEN TRUE ELSE FALSE)(x=a)
> -- an error. Quitting. To debug this try DEBUGMODE(TRUE);)
This should have printed ... unable to evaluate a>0
>
> as opposed to
>
> lambda([x], x>0)(a) => (x>0)
>
You mean a>0
> I guess what I don't understand is the interplay and between
> evaluation and simplification. Is there an alternate form of "if"
> which would work through the simplification mechanism? So that I
> could write, say
>
> if( x>0, x^2, 0 )
............
Um, it is sort of like this. (It would require some research and
some testing and code reading to say it works EXACTLY like this, but
... there is a concept of a boolean predicate, a function that returns
true or false, in many programming languages. The expression of an
equation as x=y could be interpreted in 2 ways, and in Macsyma the
notation is ambiguously used, e.g.
solve (x^2-1=0,x).
or if (x=3) then ....
To convert the expression x=3 or similar expressions which
are "in-equations" or inequality predicates, you can tell the macsyma
evaluator to try to evaluate as a boolean.
Two ways.
(a) use the expression in an IF...
(b) use IS. Thus is(x>0) will return true, false or unable to
evaluate.
Actually that is a lie since typing prederror:false;
will, assume a is unknown, make
if (a>0) then c else d return if (a>0) then c else d
and
is(a>0) return "unknown".
If this behavior seems mysterious, it is because there are 3 conflicting
concepts.
1. Make a decision based on whatever you can deduce about the variables
involved, using whatever algebra, analysis, etc you can bring to bear.
(i.e. simplify it all)
2. Wait until everything has a value and you can make a decision by
evaluation "at runtime".
3. Don't do anything except the trivial simplification of left and
right sides. The user is just writing down a list of
equations and inequalities and sometime later will do something
with them. Or maybe not.
So the complications involve
boolean eval (I think the program is beval or booleval?)
the external commands
IF
IS
the flag
PREDERROR
the ASSUME facility
possibly
the DECLARE facility
and (if you use them) CONTEXTs.
Offhand, I don't know how ASKSIGN interacts with this. Usually
ASKSIGN is called by user programs specifically to make a
choice in branching like..
if (asksign(b^2-4*a*c)) then ....
A clearer and more authoritative version of this should go into
the manual. Presumably the Macsyma Inc manuals cover this and
should be consulted if possible.
RJF