[Top][All Lists]

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

RE: [Axiom-developer] about Expression Integer

From: Bill Page
Subject: RE: [Axiom-developer] about Expression Integer
Date: Wed, 22 Feb 2006 12:13:36 -0500


On February 22, 2006 8:55 AM you wrote:
> ...
> Please bear with me.

No problem. Respond as and when you get time... :)

> > Martin wrote: 
> > > If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x
> > > as a coefficient, then it must be clear that the "x" in 1/x
> > > is something different than the "x" in 2*x. Otherwise we don't
> > > get a polynomial, obviously.
> >
> Bill Page wrote: 
> > I think this is wrong. In fact, it is clear from the 
> > implementation of Axiom that whether the 'x' in these two
> > cases is the same or not depends on which domain to which
> > they belong.

Perhaps I should have said this differently. Yes, I do agree that
the 'x' in '1/x' and '2*x' are different. But they are not
different in the sense in which 'x' and 'y' are different, i.e.
they are not different variables - they are the same variable
used in two different ways. In particular the 'x' in '1/x' is
a member of the coefficient domain just like '2', while the 'x'
in '2*x' is a member of the polynomial domain. Furthermore the
symbol '*' denotes an operation defined in the polynomial
domain, while the symbol '/' denotes an operation in the
coefficient domain.

> > 
> > Could you please define in what sense "Otherwise we don't 
> > get a polynomial, obviously."? To me this is not obvious -
> > it is wrong.
> Why should this be wrong?
> 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. And if the degree of the
term in which such a coefficient appears is 0, then by
convention we will write this polynomial in a way that looks
the same as '2/x'.

> 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 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

(1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)

   (1)  y tan(x) + sin(x) + y cos(x)
   Type: UnivariatePolynomial(x,Expression Integer)

(2) -> degree %

   (2)  0
   Type: NonNegativeInteger

> > Documentation is a good thing. But why should we retain 
> behaviour in Axiom
> > that is mathematically incorrect? What advantage does this 
> odd behaviour of
> > 'differentiate' have over a mathematically correct implementation?
> I think that 'differentiate' does not exhibit odd behaviour. 
> Why do you think it's odd?
> 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. :(

(3) -> ex1:=(x+1/sin(x))$UP(x,EXPR INT)

   (3)  x + ------
   Type: UnivariatePolynomial(x,Expression Integer)

(4) -> degree ex1

   (4)  1
   Type: PositiveInteger

(5) -> differentiate(ex1,x)

        sin(x)  - cos(x)
   (5)  ----------------
   Type: UnivariatePolynomial(x,Expression Integer)

(6) -> ex2:=(x+1/sin(x))$DMP([x],EXPR INT)

   (6)  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.

> ...
> In fact I cannot see a single reason to consider a domain
> DMP(vars, EXPR INT) at all, except for the fact that we do 
> not have a domain EXPR(vars, coefficients) yet.

How would you use such a domain to solve the problem originally
posed by Francois about expansion of trigonometric expressions
that started this thread? At the very least we would need
'DEXPR(vars, coefficients)',i.e. the "distributed" version.
But I have no objection to this suggestion. It is the other
things that we discovered about complicated nested types
along the way that concerns me now.

> > > Note that b::UP([x], INT) or b::POLY INT give errors!
> > 
> > Obviouse 'b' has no representation in these domains. 
> Yes it has: 1 is a UP([x], INT).

No! 'b' for example in:

(9) ->   P := UP(x, EXPR INT)

   (9)  UnivariatePolynomial(x,Expression Integer)
   Type: Domain

(10) ->   a :P := x

   (10)  x
   Type: UnivariatePolynomial(x,Expression Integer)

(11) ->   b := a/x

   (11)  - x
   Type: UnivariatePolynomial(x,Expression Integer)

is not the same a '1$P'

Bill Page.

reply via email to

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