RE: [Axiom-developer] about Expression Integer

[Page, Bill]

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.