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)

Type: PositiveInteger

A > 0

(2)

Type: Boolean

B > A

   There are 4 exposed and 1 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)
                               PositiveInteger
                                 Variable(B)

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.
C > A

   There are 4 exposed and 1 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)
                               PositiveInteger
                                 Variable(C)

      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 4 exposed and 1 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)
                               PositiveInteger
                                 Variable(B)

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.

X:=100

(3)

Type: PositiveInteger

X ~= 0

(4)

Type: Boolean

Y ~= 0

(5)

Type: Boolean

X/Y

(6)

Type: Fraction(Polynomial(Integer))

Y/X

(7)

Type: Polynomial(Fraction(Integer))

FOO

(8)

Type: Variable(FOO)

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.

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:

P:Expression Integer

Type: Void

Q:Expression Integer

Type: Void

P+1

(10)

Type: Expression(Integer)

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. :(

P > Q

   There are 4 exposed and 1 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.

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.