[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] [#193 Symbolic values (without variables) are not orde

From: wyscc
Subject: [Axiom-developer] [#193 Symbolic values (without variables) are not ordered properly in 'EXPR INT'] Two different orderings mixed up
Date: Wed, 20 Jul 2005 17:48:32 -0500

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:

exp(1)^2 - exp(2)
(exp(1)^2 - exp(2) = 0)::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:

4.0 - %e < 0

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

(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 expresions with symbolic constants by using the term-ordering of the 
underllying representation, and still use the numerical ordering of the domain 


forwarded from

reply via email to

[Prev in Thread] Current Thread [Next in Thread]