I think that the hard part here is identifying what variables you  
consider to be in the coefficient basering and what ones are not. I  
would propose there be an optional parameter basering to the  
coefficient function. By default it would be the base ring of the  
polynomial, and coefficient would return the coefficient of exactly  
that monomial.

sage: R.<x,y,z> = QQ[]
sage: f = x^3*y^2 + 2*z*y^2 + 3*y^2 + 4*x*y*z
sage: f.coefficient(y)
0
sage: f.coefficient(y^2)
3
sage: f.coefficient(y^2, base=QQ['x']) # result in QQ['x']
x^3 + 3
sage: f.coefficient(y^2, base=QQ['z'])
2*z + 3
sage: f.coefficient(y^2, base=QQ['x,z'])
x^3 + 2*z + 3
sage: f.coefficient(y, base=QQ['x'])
0
sage: f.coefficient(y, base=QQ['x,z'])
4*x*z

For efficiency, one could also accept a list/tuple of exponents (like  
the polydict identifier) to extract the coefficient of a single  
monomial.

sage: f.coefficient([0,2,1])
2

- Robert


On Oct 12, 2007, at 3:54 PM, Nils Bruin wrote:

> On Oct 12, 1:25 pm, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote:
> [...]
>> Suppose I had a poly ring with 19 variables and one of them was  
>> named "y".
>> How would I get the coefficient for y^0 in your syntax?  (That is,  
>> the
>> constant term in k[y][...].)  This is the sticking point in what  
>> is currently
>> implemented.
>
> No, that would be the constant term in k[...][y]. The syntax would
> then be:
>
> poly.coeff({ a for a in poly.parent().generators() if a != y }, 1)
>
> (i.e., all variables except y are allowed)
>
> except that python doesn't like set comprehension (why not? is there
> an unordered list type with quick membership test?), so we might want
> to make it a list instead:
>
> poly.coeff([ a for a in poly.parent().generators() if a != y ], 1)
>
> If that is the most common usage scenario you have in mind, then this
> notation might be a tad wasteful. Would surgery on poly.dict() solve
> your problems?
>
> Incidentally, poly.coefficient does have documentation. The behaviour
> you describe is a bug relative to that description. The alternative
> behaviour that you describe, nor mine, is in line with the definition
> given there either.
>
>
>
> 

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to