Re: [Axiom-developer] about Expression Integer

[Martin Rubey]

"Bill Page" <address@hidden> writes:

> > Here's a definition for polynomial from wikipedia:
> > 
> >   In mathematics, a polynomial is an expression in which constants
> >   and variables are combined using (only) addition, subtraction,
> >   and multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not.

> I think this definition is less general it needs to be and difficult to apply
> in the context of Axiom. We need to know what are "constants" and what are
> "variables" and where "addition", "subtraction" and "multiplication" are
> defined.
 
> > I recall that in the Algebra course I attended, the polynomial
> > ring was defined as a ring (of coefficients) together with a
> > variable which is to be transcendent over that ring. 
> 
> That definition is much better. In the case we are discusing the ring of
> coefficients is the domain 'EXPR INT' which includes expressions of the form
> '1/x' and so it is correct to say that '2/x' is not in itself a polynomial
> but it can be a coefficient in a polynomial.

Yes, but the variable of the polynomial needs to be transcendent over the
coefficient domain. So we have to have two different x here.

> > sin x + y*cos x + y^2* tan x 
> > 
> > is perfectly allright 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:

NO! It is not a polynomial in x.

> (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, but the x of UP(x, EXPR INT) is a different x than the x in sin(x). They
only happen to have the same name.

> > Of course, if you claim that x+1/sin(x) is a polynomial, than I'm out of
> > luck.
> 
> Indeed, I think you are out of luck. :(

Why? Are you really saying that x+1/sin(x) is a polynomial in x? Once more: the
polynomial variable needs to be transcendent over the coefficient domain. The
reason is simple: otherwise you lose all the interesting features of
polynomials, for example, that you can easily test for equality, given a test
for equality in the coefficient domain.

> (3) -> ex1:=(x+1/sin(x))$UP(x,EXPR INT)
> 
>                1
>    (3)  x + ------
>             sin(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (4) -> degree ex1
> 
>    (4)  1
>    Type: PositiveInteger
> 
> (5) -> differentiate(ex1,x)
> 
>               2
>         sin(x)  - cos(x)
>    (5)  ----------------
>                    2
>              sin(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (6) -> ex2:=(x+1/sin(x))$DMP([x],EXPR INT)
> 
>                1
>    (6)  x + ------
>             sin(x)
>    Type: DistributedMultivariatePolynomial([x],Expression Integer)
> 
> (7) -> degree ex2
> 
>    (7)  [1]
>    Type: DirectProduct(1,NonNegativeInteger)
> 
> (8) -> differentiate(ex2,x)
> 
>    (8)  1
>    Type: DistributedMultivariatePolynomial([x],Expression Integer)
> 
> The results for (5) and (8) should be identical... QED.

(What are you proving here?)

Yes, they should be identical, and I vote for (8). Well, in fact I vote for not
using a construction like DMP([x], EXPR INT). What I would find nice though
would be a way to say: have a polynomial in x with coefficients beeing
arbitrary expressions which do not contain the variable x. (In this case, the
result of (5) would indeed be 1.)

There are several problems with the UP domain, for example, try

(27) -> ex3:=(y+1/sin(x))$UP(y,EXPR INT); differentiate(ex3, x)

               2
         sin(x)  - cos(x)
   (27)  ----------------
                    2
              sin(x)
                             Type: UnivariatePolynomial(y,Expression Integer)


> At the very least we would need 'DEXPR(vars, coefficients)',i.e. the
> "distributed" version.  But I have no objection to this suggestion.

Great.

> It is the other things that we discovered about complicated nested types
> along the way that concerns me now.

Great.

Martin