List Archives >
Maple User Group List Archive >
Archive by date >
This Month By Date >
This Month By Topic
[MUG] Re: coeff on a generic polynomial
| [MUG] Re: coeff on a generic polynomial |
|
Author: Maple User Group
Posted: Fri, 22 Nov 2002 16:37:48 -0500
|
>> From: Maple User Group "maple_gr"
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Tue, 19 Nov 2002 16:14:31 -0800 (PST)
From: Robert Israel "israel"
To: "maple-list"
Subject: coeff on a generic polynomial
On Mon, 18 Nov 2002, Charles James Leonardo Quarra Cappiello wrote:
|> a definite polynomial like
|>
|> > p: x -> a*x^2 + b*x + c;
|>
|> can be accessed with coeff like
|> > coeff( p(z), z, 0 );
|> c
|>
|> BUt, if p is defined like
|>
|> >p:x->sum( a[i]*x^i , I=0..n );
I assume you mean := and i here, not : and I.
|> this still is considered a polynom object
|> > type ( p, polynom);
|> true
Yes, p is a "polynom", as is any other name, but p(z) is not:
> type(p(z), polynom);
false
Of course, p(z) is _not_ a polynomial, it is an unevaluated summation
(assuming n has not been assigned a value).
|> But, coeff doesnt have the desired effect:
|> > coeff( p(z) , z, 0);
|> Error, unable to compute coeff
Not too surprising, since coeff is designed for polynomials rather than
unevaluated series.
Actually, it's not quite clear what you should want as
the result of coeff for this example, if Maple doesn't know whether
n >= 0.
A simple work-around in this particular case is to evaluate p(z) with a
definite value of n (>= 0). So:
> coeff(eval(p(z),n=0),z,0);
a[0]
But doing it in general (maybe for a sum that's not in powers of z, but
of powers of z-c, or something more general) would not be so simple.
Robert Israel "israel"
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia
Vancouver, BC, Canada V6T 1Z2
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Tue, 19 Nov 2002 23:24:40 -0500 (EST)
From: Edwin Clark "eclark"
To: Charles James Leonardo Quarra Cappiello "charsquarra"
Subject: coeff on a generic polynomial
You might do this:
> p:=(x,n)->sum('a[i]*x^i','i'=0..n):
> coeff(p(z,0),z,0);
a[0]
> coeff(p(z,1),z,1);
a[1]
> coeff(p(z,2),z,2);
a[2]
>
------------------------------------------------------------
W. Edwin Clark, Math Dept, University of South Florida,
http://www.math.usf.edu/~eclark/
------------------------------------------------------------
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Wed, 20 Nov 2002 10:13:09 +0100
From: Preben Alsholm "P.K.Alsholm"
To: "maple-list"
Subject: coeff on a generic polynomial
Notice that if a is just a name then type(a,polynom) returns true. In
your case p is the name of a function (procedure). Procedures are only
evaluated to a name, so type(p,polynom) will return true.
Try instead:
type(p(x),polynom);
whattype(p(x));
op(0,p(x));
op(p(x));
and you see the problem.
Preben Alsholm
Department of Mathematics
Technical University of Denmark
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
From: "Dr Francis J. Wright" "F.J.Wright"
To: "charsquarra"
Subject: coeff on a generic polynomial
Date: Wed, 20 Nov 2002 13:23:36 -0000
Let me define p as follows (which I assume is what you intended):
p := x -> sum( a[i]*x^i , i=0..n );
It is true that p is of type polynom, because a variable to which a
procedure (or table) has been assigned evaluates to itself, so p is
(trivially) a polynomial in p of degree 1. However, the test you should
have made is this:
type(p(x), polynom);
false
This is because p(x) is a symbolic sum and not a polynomial.
> But, coeff doesnt have the desired effect:
> > coeff( p(z) , z, 0);
> Error, unable to compute coeff
>
> How can i do this?
I don't know of any straightforward way to extract polynomial terms from an
arbitrary symbolic sum of polynomial terms, although for this simple example
there are trivial tricks one could use, e.g. this extracts the constant
term, which appears to be what you wanted:
eval(op(1,p(x)), i=0);
a[0]
The general problem is an example of manipulating what one might call
"indefinite objects", which seems to be something that CA systems are
currently not very good at. I'm working on it.
Francis
|
[View Complete Thread]
Previous by date: [MUG] Numerical error, Madham53
Next by date: [MUG] Re: ODE with singularity, Maple User Group
Previous thread: [MUG] more about implicitdiff:complexity and recursiveness, Charles James Leonardo Quarra Cappiello
Next thread: [MUG] ODE with singularity, Jens-Uwe Herrmann
|
(NAG)
