> On Tue, May 10, 2011 at 10:37 PM, Mike Hansen <mhan...@gmail.com> wrote: > > On Tue, May 10, 2011 at 6:52 PM, Rob Beezer <goo...@beezer.cotse.net> wrote: > >> OK, thanks for the explanation, Tom. p.exponents() was the missing > >> piece I did not have. > > > It would probably make sense to have p.monomials() method to be > > consistent with the multivariate case: > > > sage: R.<t,s> = QQ[] > > sage: p = t^4 + 8 > > sage: p.coefficients() > > [1, 8] > > sage: p.monomials() > > [t^4, 1] > > sage: sum(c*m for c,m in zip(p.coefficients(), p.monomials())) > > t^4 + 8 > > +1
+1 (with documentation with benchmarching -- p.monomials() might be more expensive than the analogous loop over p.exponents()). > > p.coeffs() might be better off renamed to something like > > all_coefficients or dense_coefficients or .... I suggest deprecation and reference in p.coefficients to p.list. > I use p.coeffs() pretty often. Perhaps p.coefficients should take an > additional argument: p.coeffs could be an alias to > p.coefficients(dense=True), and get deprecated. +1 to deprecation I'm opposed to different behaviour for p.coeffs and p.coefficients, which can only be a source of confusion. As long as p.list() is documented in p.coefficients() then I'm neutral on adding the dense keyword -- like p.coeffs() [see docstring] it is likely to be slower, and people are likely to use it. I was at first surprised by p.coefficients but it seems useful, efficient, and compatible with sparse and dense representations; p.list() is completely standard Python syntax. --David -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
