login  home  contents  what's new  discussion  bug reports help  links  subscribe  changes  refresh  edit

# Edit detail for SandBox Boolean revision 2 of 2

 1 2 Editor: Bill Page Time: 2008/05/21 20:56:56 GMT-7 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?


fricas
A:=100 (1)
Type: PositiveInteger?
fricas
A > 0 (2)
Type: Boolean
fricas
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 >
package-calling 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 package-calling 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 >
package-calling 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. fricas X:=100 (3) Type: PositiveInteger? fricas X ~= 0 (4) Type: Boolean fricas Y ~= 0 (5) Type: Boolean fricas X/Y (6) Type: Fraction(Polynomial(Integer)) fricas Y/X (7) Type: Polynomial(Fraction(Integer)) fricas FOO (8) Type: Variable(FOO) fricas if X ~= 0 then if Y ~= 0 then X/Y else Y/X else FOO (9) Type: Fraction(Polynomial(Integer)) 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. an explanation of the results --Bill Page, Wed, 01 Feb 2006 18:09:20 -0600 reply In general, Axiom does not have any representation (domain) for unevaluated Boolean expressions and conditions. Unlike Maxima, Axiom implements a strongly-typed 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: fricas P:Expression Integer Type: Void fricas Q:Expression Integer Type: Void fricas P+1 (10) Type: Expression(Integer) fricas P+Q (11) Type: Expression(Integer) Unfortunately Axiom makes the mistake of actually implementing a total ordering on Expressions! Personally, I think this is a grave error. :( fricas 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 package-calling 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.