[Axiom-developer] Re: EXPR POLY INT

[Martin Rubey]

William Sit writes:
 > Hi Martin:
 > 
 > Your explanation on EXPR POLY INT is perfect.

thanks!
 
 > > (1) provide a possibility to get the "variable free" domain of a domain, 
 > > i.e.,
 > > 
 > > POLY INT, UP(x,POLY INT) both should yield INT
 > 
 > Two comments: 
 > 
 > (1) Actually, there is a more general request for ages: that is, each
 > CONSTRUCTOR in Axiom should provide the means to return ALL the parameters. 
 > This
 > would have to be built like OutputForm form the bottom up because of nesting.
 > Lots of editing and a total rebuilt. Currently, when writing a constructor,
 > there is no way one can "descend" inside its parameters other than finding 
 > their
 > categorical property or attributes.

Hm, I don't quite understand why this would be more general? What I think what
is needed is a function that takes a domain as argument and has a domain as
value, which is related to the first domain in the sense that the resulting
domain is no longer RetractableTo Symbol.

 > (2) Note UP(x, POLY INT) is valid (in the interpreter) but not
 > POLY UP(x, INT) probably for the same reason as EXPR POLY INT. Now this 
 > should
 > be!
 > 
 >   )clear all
 >   a:POLY INT :=x
 >   b:UP('x,INT):='x
 >   differentiate(b,x)
 >   differentiate(b,a)
 >   b/a

Uh, ugly. An excellent example though!

 > > (2) make the coercion to EXPR smarter and swallow all variables...
 > > 
 > > I'm very unsure wether we should prefer (1) or (2), mainly because I still
 > > don't understand the philosophy behind EXPR. 
 > 
 > Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may be an
 > easier target to "fix".

Yes. In fact, there is another possibility to consider. In (2) I suggested that
all the variables in EXPR POLY INT should belong to EXPR. In fact, this was an
accident. What I meant to say is

 (3) make the coercion to EXPR smarter and let its argument domain swallow as
     many variables as possible.

I think that this would be more sound. However, my feeling is that (1) is the
best way.

 > > Very briefly: I think we could
 > > characterize EXPR R by saying that it is the space of functions whose 
 > > variables
 > > are allowed to take values in R or EXPR R. However, this is not quite 
 > > complete:
 > > In which domain are the numbers appearing in the expression?
 > > 
 > > For example
 > > 
 > > (7) -> 2.0*x^2*log(2*x)
 > > 
 > >              2
 > >    (7)  2.0 x log(2.0 x)
 > >                                                        Type: Expression 
 > > Float
 > > 
 > > which is good, I believe. (Note that the square stayed square, not power 
 > > 2.0)
 > 
 > But notice that the 2 in 2*x has to be coerced to Float even though Float has
 > RetractableTo INT.

Hm? The above was an (unfortunately trivial) example to show that not all
numbers in EXPR FLOAT are FLOAT, or, more generally, not all coefficients in
EXPR R are from R. In fact, it seems as though exactly the powers are
not. More precisely, they cannot be:

(6) -> x^2.1

         2 10+-+
   (6)  x   \|x
                                                       Type: Expression Float
The following I'd consider as a bug:

(10) -> (x^%pi)::EXPR FLOAT

          3 6701487259+-+948881364
   (10)  x           \|x
                                                       Type: Expression Float

 > > Are there domains with OrderedSet and IntegralDomain which are not
 > > RetractableTo Integer?

 > An integral domain of characteristic zero is always retractable to integer. 
 > On
 > the other hand, one of characteristic non-zero will contain a prime field 
 > which
 > is not an ordered set in Axiom (PrimeField has ContractableTo Integer and
 > RetractableTo(%), not RetractableTo Integer).

Yes, but could you give an example? This would be great!

Martin