Edit detail for SandBox Boolean revision 2 of 2

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?

(1) -> 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 
      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.

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.

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:

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