

last edited 11 years ago by Bill Page 
1 2  
Editor: Bill Page
Time: 2008/05/21 20:56:56 GMT7 

Note: 
changed: that the 'A' above is of type PostiveInteger and the comparison:: that the 'A' above is of type PositiveInteger and the comparison::
On Wed, 1 Feb 2006 10:29:24 0700 Robert Dodier asked C Y:
How does Axiom handle boolean expressions which don't evaluate to true or false?
Likewise, what happens to if ... then ... else when the condition is a boolean expression which doesn't evaluate to true or false.
Here are some examples. I'll try to use a "package agnostic" notation:
Let A = 100. What does "(A > 0) and (B > A) or (C > A)" evaluate to? Maybe "(B > 100) or (C > 100)" ? Something else? Let X = 100. What does "if (X != 0) then (if (Y != 0) then X/Y else Y/X) else FOO" evaluate to? Maybe "if (Y != 0) then 100/Y else Y/100" ? Something else?
A:=100
(1) 
A > 0
(2) 
B > A
There are 1 exposed and 2 unexposed library operations named > having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse,or issue )display op > to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation.
Cannot find a definition or applicable library operation named > with argument type(s) Variable(B) PositiveInteger
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need. C > A
There are 1 exposed and 2 unexposed library operations named > having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse,or issue )display op > to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation.
Cannot find a definition or applicable library operation named > with argument type(s) Variable(C) PositiveInteger
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need. (A > 0) and (B > A) or (C > A)
There are 1 exposed and 2 unexposed library operations named > having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse,or issue )display op > to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation.
Cannot find a definition or applicable library operation named > with argument type(s) Variable(B) PositiveInteger
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need.
X:=100
(3) 
X ~= 0
(4) 
Y ~= 0
(5) 
X/Y
(6) 
Y/X
(7) 
FOO
(8) 
if X ~= 0 then if Y ~= 0 then X/Y else Y/X else FOO
(9) 
I'm working on beefing up Maxima's handling of boolean and conditional expressions, and just for a point of reference I'm taking a look at what other packages do. If you have some links or references to the Axiom documentation that would be very helpful.
Unlike Maxima, Axiom implements a stronglytyped language. All operators, variables and constants are assigned or assumed to be of a given type (i.e. they must be represented in some domain).
By default Axiom makes the assumption:
A:=100
that the A
above is of type PositiveInteger? and the comparison:
A > 0
is made by the >
function defined by the PositiveInteger?
domain (actually inherited from the Integer domain).
But the comparison:
B > A
is treated differently. Axiom doesn't know anything about
B
. By default it assumes that B
is a variable. Now it
searches for some domain in which it can compare a variable
and an integer. The first domain that it finds in which this
is possible is the domain of polynomials. Both B
and A
aka
100 can be considered to be polynomials. Within the polynomial
domain a function named >
is defined by the standard
ordering of polynomials. In this case B
being a polynomial
of degree 1 is considered "greater" than any constant
(degree 0).
I think it would be fair to argue that this result violates the principle of least surprise for the first time Axiom user!
Besides polynomials Axiom does have a domain allowing unevaluated expressions so you can write, for example:
P:Expression Integer
Q:Expression Integer
P+1
(10) 
P+Q
(11) 
Unfortunately Axiom makes the mistake of actually implementing a total ordering on Expressions! Personally, I think this is a grave error. :(
P > Q
There are 1 exposed and 2 unexposed library operations named > having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse,or issue )display op > to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation.
Cannot find a definition or applicable library operation named > with argument type(s) Expression(Integer) Expression(Integer)
Perhaps you should use "@" to indicate the required return type,or "$" to specify which version of the function you need.
I would prefer that in the domain Expression, the function >
would be allowed to remain unevaluated, in the same way that
+
is unevaluated.
So if a integration function returns something like "if a>0 then if b>0 then
There's more, but hopefully that gives some idea of what I'm getting at. Best, Robert Dodier.