Hello Stavros,
Thanks for your explanation about the present behavior
of Maxima concerning conditions. I can see how the results
I was getting are consistent with the rules currently
implemented.
I have a couple of comments --
(1) "NOT x # y" yields FALSE for undefined x and y
(whether PREDERROR is TRUE or FALSE). This seems like a bug
-- do you agree? If PREDERROR is TRUE, "x <= y AND x >= y"
yields UNKNOWN as does "NOT (x > y OR x < y)", otherwise,
both of those yield an error. It seems "NOT x # y" should
act the same as those two.
(2) Some of the rules concerning conditions are there to
avoid having to simplify or evaluate 1/0 or other
expressions. What happens if Maxima has a policy that
"There are no bad expressions, every expression evaluates
to something" ? For example in IEEE 754 arithmetic, 1/0
evaluates to floating point infinity and 0/0, to not-a-number.
UNKNOWN is another possibility, and leaving a problematic
expression alone (e.g., leave alone 1/0) is another possibility.
It seems that if we implemented this more relaxed policy,
then unevaluated boolean expressions with AND, OR, and NOT
become possible. What do you think?
(3) Recursive unevaluated conditionals, as in the factorial
definition, do seem problematic. I don't yet see what we
can do there. Somehow we (humans) seem able to use context
to tell just how hard we should try to expand a factorial;
I know that it is just this kind of context sensitivity
which is difficult to automate.
You wrote in part:
> I am not saying all these things are not soluble with some
> appropriate design. What I am saying is that it *does*
> require non-trivial design and implementation, [...]
Great, it is precisely this design that I hope we are
working towards.
Regards,
Robert Dodier
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/