Edit detail for SandBox Boolean revision 1 of 2

changed:
-
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?

\begin{axiom}
A:=100
A > 0
B > A
C > A
(A > 0) and (B > A) or (C > A)
\end{axiom}

\begin{axiom}
X:=100
X ~= 0
Y ~= 0
X/Y
Y/X
FOO
if X ~= 0 then if Y ~= 0 then X/Y else Y/X else FOO
\end{axiom}

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.



From BillPage Wed Feb 1 18:09:20 -0600 2006
From: Bill Page
Date: Wed, 01 Feb 2006 18:09:20 -0600
Subject: an explanation of the results
Message-ID: <20060201180920-0600@wiki.axiom-developer.org>

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 PostiveInteger 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:
\begin{axiom}
P:Expression Integer
Q:Expression Integer
P+1
P+Q
\end{axiom}

Unfortunately Axiom makes the mistake of actually implementing a
total ordering on Expressions! Personally, I think this is a grave
error. :(

\begin{axiom}
P > Q
\end{axiom}

I would prefer that in the domain Expression, the function '>'
would be allowed to remain unevaluated, in the same way that
'+' is unevaluated.

From unknown Wed Feb 1 20:46:57 -0600 2006
From: unknown
Date: Wed, 01 Feb 2006 20:46:57 -0600
Subject: follow-up comments
Message-ID: <20060201204657-0600@wiki.axiom-developer.org>

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 <something> else if b>-1 then <whatever> else <something else again> 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.

From unknown Wed Jul 5 07:50:48 -0500 2006
From: unknown
Date: Wed, 05 Jul 2006 07:50:48 -0500
Subject: 3>5
Message-ID: <20060705075048-0500@wiki.axiom-developer.org>

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?

axiom
A:=100

(1)

Type: PositiveInteger?

axiom
A > 0

(2)

Type: Boolean

axiom
B > A

(3)

Type: Boolean

axiom
C > A

(4)

Type: Boolean

axiom
(A > 0) and (B > A) or (C > A)

(5)

Type: Boolean

axiom
X:=100

(6)

Type: PositiveInteger?

axiom
X ~= 0

(7)

Type: Boolean

axiom
Y ~= 0

(8)

Type: Boolean

axiom
X/Y

(9)

Type: Fraction Polynomial Integer

axiom
Y/X

(10)

Type: Polynomial Fraction Integer

axiom
FOO

(11)

Type: Variable FOO

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

(12)

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 PostiveInteger? 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:

axiom
P:Expression Integer

Type: Void

axiom
Q:Expression Integer

Type: Void

axiom
P+1

(13)

Type: Expression Integer

axiom
P+Q

(14)

Type: Expression Integer

Unfortunately Axiom makes the mistake of actually implementing a total ordering on Expressions! Personally, I think this is a grave error. :(

axiom
P > Q

(15)

Type: Boolean

I would prefer that in the domain Expression, the function > would be allowed to remain unevaluated, in the same way that + is unevaluated.

follow-up comments --unknown, Wed, 01 Feb 2006 20:46:57 -0600 reply

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.

3>5 --unknown, Wed, 05 Jul 2006 07:50:48 -0500 reply