Axiom thinks

axiom

4-%e < 0

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)
NonNegativeInteger

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

and

axiom

4-%pi::EXPR INT < 0

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)
NonNegativeInteger

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

which poses another problem for fixing bug #47 and bug #141

Hi Martin:

You already know the reasons and I think the title of this page is unfair. It is clear that the meaning of the operator `<`

in `EXPR INT`

(or any domain that includes symbolic expressions like `POLY INT`

) is not meant to be an ordering of the ground domain (here `INT`

). In polynomial rings, `<`

is a term-ordering to facilitate polynomial arithmetic and variable elimination methods. If I read `expr.spad`

correctly, when `R`

is an integral domain, `EXPR R`

has `FRAC SMP(R, Kernel EXPR R)`

as its representation (`Rep`

). You can explain better what that means than I (I would much appreciate your writing a page explaining kernels and operators in Axiom). In any case, the ordering is inherited from the `Rep`

and so I believe `%e`

or `exp(1)`

is treated as a symbol. Indeed that may be the reason we have:

axiom

exp(1)^2 - exp(2)

**Type: **Expression(Integer)

axiom

(exp(1)^2 - exp(2) = 0)::Boolean

**Type: **Boolean

The sign of a polynomial expression is the sign of the coefficient of the highest monomial term.

The way that `4-%e < 0`

can be evaluated they way you intend is to substitute a numerical value for `%e`

. So users should be aware that in Axiom, symbolic entries are not the same as their numerical counterpart. What they should do is:

axiom

4.0 - %e < 0

**Type: **Boolean

or

axiom

(4-%e)::(EXPR Float) < 0

**Type: **Boolean

(This is reminescent of FORTRAN: type promotion from INTEGER to REAL). In other words, if one wants to test numerical inequalities involving symbolic constants, one should work in `EXPR Float`

, not `EXPR Integer`

since most symbolic constants are not integers. To provide an automatic type promotion from `EXPR INT`

to `EXPR Float`

would interfere with the ordering in polynomial expressions, unless a symbolic constant can be distinguished from a polynomial variable. We cannot overload the operator `<`

for two distinct orderings in the same domain. I think the suggestion I posted in #47 of a `SymbolicFloat`

domain may be worth exploring. In `SymbolicFloat`

, we can retain symbolic manipulation of expressions with symbolic constants by using the term-ordering of the underlying representation, and still use the numerical ordering of the domain `SymbolicFloat`

.

William

The same problem exists in

`AN`

. Although the test for zero in this domain is mathematical, we have

axiom

sqrt(2)<sqrt(3/2)

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)
AlgebraicNumber
AlgebraicNumber

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

Note that the domain `RealClosure`

is designed to handle such things. Also, the test for zero in `RECLOS`

is faster than in `AN`

. So, wouldn't it be appropriate to make `AN`

a wrapper for `RECLOS FRAC INT`

? Of course, the appropriate conversion routines would have to be written, but this would be quite easy.

Martin

Two different orderings mixed up--wyscc, Wed, 20 Jul 2005 17:48:29 -0500 reply