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

fricas

A > 0

**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 >
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(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 >
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(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

fricas

X ~= 0

**Type: **Boolean

fricas

Y ~= 0

**Type: **Boolean

fricas

X/Y

**Type: **Fraction(Polynomial(Integer))

fricas

Y/X

**Type: **Polynomial(Fraction(Integer))

fricas

FOO

**Type: **Variable(FOO)

fricas

if X ~= 0 then if Y ~= 0 then X/Y else Y/X else FOO

**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.

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

**Type: **Expression(Integer)

fricas

P+Q

**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.

Just to give this question some context, my interest in this topic stems largely from working with integrals, functions defined piecewise, roots of equations, etc which have different values or exist or don't exist depending on some parameters.

So if a integration function returns something like "if a>0 then if b>0 then else if b>-1 then else else ...", I'd like for a user to be able to simplify it by giving certain values to some of the parameters in question and re-evaluating it. All of the branches which are not chosen should go away.

There's more, but hopefully that gives some idea of what I'm getting at. Best, Robert Dodier.

an explanation of the results--Bill Page, Wed, 01 Feb 2006 18:09:20 -0600 reply