axiom-developer
[Top][All Lists]

## RE: [Axiom-developer] about Expression Integer

 From: Page, Bill Subject: RE: [Axiom-developer] about Expression Integer Date: Fri, 24 Feb 2006 08:12:16 -0500

Ralf,

On Friday, February 24, 2006 5:12 AM you wrote:
> ...
> Let us take again the view that a polynomial ring "R[x]" (it's
> in quotes since I haven't defined that notation yet) is the
> ring
>
>    P = \bigoplus_{e \in N} R
>
> where N are the non-negative integers.
> Elements in P (the polynomials) are just functions with finite
> support from N to R. So the are nothing else than (infinite)
> sequences of numbers from R where only a finite non-zeros appear.
>

Ignoring for now the details of multivariate polynomials, in
Axiom we would write:

P:=POLY R

where R is some Ring (such as INT).

> Now, let x \in P be such that x(1)=1 and x(e)=0 for e \in
> N\setminus\{1\}.
>
> If you like, you can consider this x to be the "indeterminate"
> or "variable" of P.
>

No, this is not quite complete. There is a function 'coerce'
such that 'coerce(x::Symbol)$P' \in P. Axiom displays both this polynomial and the symbol in the same way except the Type is different. > It is also clear that by construction this x is different > from anything that lives in R. Yes, I agree with this. Except you say "numbers from R" which could be miss-leading if R itself is a polynomial ring or a more general ring (such as Axiom's EXPR INT). > ... > **What is differentiation in P?** > > (That is a bit informal here.) > Given that elements in P have finite support, we can represent > them as finite tuples. > Let a := (a_0, a_1, ..., a_n) \in P, then the (formal) > derivative of a is > > a' = (a_1, 2 a_2, 3 a_3, ..., n a_n) > > (Note that a_0 is missing.) > > If you write a as a formal sum, using the x introduced above, > you get. > > a = \sum_{e=0}^n a_e x^e > a' = \sum_{e=0}^{n-1} a_{e+1} x^e > > just as expected. The defintion of differentiation that concerns me is specified with respect to some symbol, e.g. differentiate:(POLY R, Symbol) -> POLY R If R is a Ring (such as another polynomial ring) which also allows for example 'coerce(x::Symbol)$R' (in Axiom we would
write 'R has PDRING Symbol') then it makes good sense, I think
to define this differentiaton as an extension of the
differentiation in R (DifferentialExtension). This is what
is done in some Axiom polynomial domains and not others.

> ...
> I think that the current implementation of polynomials in
> Axiom more closely follow the formal approach. If somebody
> wants polynomials to behave differently, then there should
> be a clear documentation and an **additional** domain that
> support these ideas. But, please don't modify the existing
> polynomials in Axiom.
>

I agree. But we not talking about changing the way polynomials
behave, we are trying to define how polynomials behave now
in Axiom. My claim is that they do not (at least not quite)
behave that way that some people here have described. So I
am trying to change their description. :)

> >> I guess you know that, so there is probably a
> >> misunderstanding somewhere. Just to be clear:
> >>
> >> sin x + y*cos x + y^2* tan x
> >>
> >> is perfectly allright as a polynomial in y.
> >
> > I agree, but it is also a perfectly good polynomial in x
> > provided that it can appear as a member of the coefficient
> > domain:
>
> Bill, if this is your terminology, I strongly disagree with
> you. If I say something is "polynomial in x" then I mean if
> the expression is written as an expression tree then in the
> path from every x to the root I should at most see "^", "*",
> "+" (and "-").

You are right. My terminology was poor. But Axiom does not
have any domain consisting of an expression tree such as
you describe. This would be a much more restricted that the
current polynomial domains in Axiom.

What I should have written was perhaps:

"it is also a perfectly good polynomial over a ring that
allows such such expressions"

My point is that this is well-defined even if the same
symbol 'x' appears in both the underlying ring (i.e. in a
coefficient, and as the polynomial variable.

>
> > (1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT) > > > > 2 > > (1) y tan(x) + sin(x) + y cos(x) > > Type: UnivariatePolynomial(x,Expression Integer) > > > > (2) -> degree % > > > > (2) 0 > > Type: NonNegativeInteger > > Yes, Axiom is correct _and_ confusing! The confusion is relative to the presumptions that one has about how Axiom works... ;) > If a user want to construct something like UP(x,EXPR INT), > then he should know what he is doing. Unfortunately, beginners > probably don't know what they do when they type in > UP(x,EXPR INT). And they will be surprise by the strange > results. Perhaps, but I do not see any reason for beginners to use such complicated domains. > And I very much think that they will turn their back to > Axiom, because it is so confusing. (Which would be a pity.) But that *is* how Axiom was designed. You are suggesting that we should change or at least suppress this part of the design. I instead am trying to find some way to describe the what Axiom does now in a way that is comprehesible to as many Axiom users as possible. I object in principle to the idea of "dumbing down" the fundamental design of Axiom so that it only behaves in the way naïve users expect. On the other hand, I would be happy to see a new user interface for new Axiom users that would focus on implementing the "principle of least surprize". > ... > Hey, if coerce: SOMETHING -> UP(x, INT) is a total function, > then what does that mean? > ... > Does someone believe that "coerce" always has to be an > inclusion function? > > > ... > > 1 > > (11) - x > > x > > Type: UnivariatePolynomial(x,Expression Integer) > > > > is not the same a '1$P'
>
> What does that matter? If we have two domains A and B, two
> elements a \in A, b \in B, a function coerce: A->B, and
> coerce(a) = b. The whole relation between a and b is clear.
> But where is it written, that coerce in Axiom has to be
> a homomorphism? (BTW, a homomorphism of which type?
> Homomorphism of rings, of groups, of sets?)
>

'coerce' is a conversion that is intended to be automatically
applied by the interpreter presumably without the risk of
encuring any mathematical errors. So I think that at the
very least a coercion must be a morphism from A to B
that preserves the structure of A (i.e. a functor). B can
have however additional structure that is not in A. Perhaps
this is also true of other conversions (invoked by ::) when
we consider the algebraic properties of the possible result
"failed".

For example we can coerce INT -> FLOAT but we can only
convert FLOAT -> INT.

(1) -> X:INT:=1

(1)  1
Type: Integer

(2) -> Y:=X+1.1

(2)  2.1          <---- this is a coercion of INT to Float
Type: Float

(3) -> Y + 1         <---- Float is not coerced to INT

(3)  3.1
Type: Float

(4) -> Y::INT

Cannot convert from type Float to Integer for value
2.1

(4) -> Z:Float:=1

(4)  1.0
Type: Float

(5) -> Z::INT        <---- this is a conversion of Float to INT

(5)  1
Type: Integer

Regards,
Bill Page.