Re: [sage-devel] coeffs() coefficients()
Hi, if it can help, here are two remarks: First, P.coeffs does not shortcut anything compared to P.coefficients because we have tab completion. It even slows things down: if i want coefficients, i will write P.coeTAB and then it will not auto-complete fully because coeffs adds a breaking node between P.coe and P.coefficients (and symmetrically) so actually removing P.coeffs will speed things up. Second, from the new user point of view, the method is called coefficients not nonzero_coefficients so people use it the straightforward way and since it works on most tested example, they will not go further in reading the doc. I have observed the problem with coefficients default behaviour some times already, see for example : http://ask.sagemath.org/question/23920/polynomial-in-gfp2/?answer=23922#post-id-23922 The main issue here is that it somehow fails silently. A common workflow is to tab-complete for what you are looking for, if something with the right name appears, try it and use it if it works, look at the documentation only if your example did not work as expected. A test polynomial basically looks like 1+2*x+5*x^3 tried with second coeff, unlikely 1+2*x^4. Note that everything is already coded as P.dict(), P.__getitem__() and P.__iter__() so the main question is about visibility and accessibility. A newcommer is unlikely to look at the P.dict() method while tab-completing (even less P.__getitem__([2,3]) nor P([2,3])), while the word coefficients immediately makes sense and deserves having a try. If i had two gifts coefficients and dict to offer to a developper and a newcommer, it is not clear i would have done the current choice, newcomers are not subscribed to sage-devel however. By the way, i found 'nonzero' much easier to understand than 'sparse' in this context. Ciao, Thierry On Wed, Nov 26, 2014 at 12:06:31PM -0800, john_perry_usm wrote: Hello Sages Last week (?) I noticed that a program I wrote was making a mistake, because f.coeffs() and f.coefficients() return very different results: the former provides a dense representation (with 0's), the second a sparse one (no 0's, correlating with f.exponents()). I like this OK, but the help string isn't clear on this: the latter states merely, Return the coefficients of the monomials appearing in self; while the former states, Returns self.list(). The help on self.list() states merely, Returns a list with the coefficients of self. So the difference is that one states monomials *appearing* in self, while the other does not clarify that it gives the monomials appearing in self, which presumably means it includes monomials *not* appearing in self. I'm not good at these kinds of inferences, so this does not immediately convey dense or sparse representation, or not to me, anyway. I would propose the following: *f.coeffs?* should state something to the effect of, Returns all the coefficients of a dense representation of f. *f.coefficients?* should state something like, Returns all the coefficients of a sparse representation of f; that is, it returns only the non-zero coefficients, in a list correlated with f.exponents. (Notice the explicit statement of the correlation, reinforcing sparse representation.) *f.list?* should be mostly identical to f.coeffs? I'm willing to open a ticket author a patch to this effect, if at least one other person agrees here. john perry -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] coeffs() coefficients()
Hello Sages Last week (?) I noticed that a program I wrote was making a mistake, because f.coeffs() and f.coefficients() return very different results: the former provides a dense representation (with 0's), the second a sparse one (no 0's, correlating with f.exponents()). I like this OK, but the help string isn't clear on this: the latter states merely, Return the coefficients of the monomials appearing in self; while the former states, Returns self.list(). The help on self.list() states merely, Returns a list with the coefficients of self. So the difference is that one states monomials *appearing* in self, while the other does not clarify that it gives the monomials appearing in self, which presumably means it includes monomials *not* appearing in self. I'm not good at these kinds of inferences, so this does not immediately convey dense or sparse representation, or not to me, anyway. I would propose the following: *f.coeffs?* should state something to the effect of, Returns all the coefficients of a dense representation of f. *f.coefficients?* should state something like, Returns all the coefficients of a sparse representation of f; that is, it returns only the non-zero coefficients, in a list correlated with f.exponents. (Notice the explicit statement of the correlation, reinforcing sparse representation.) *f.list?* should be mostly identical to f.coeffs? I'm willing to open a ticket author a patch to this effect, if at least one other person agrees here. john perry -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] coeffs() coefficients()
Hello John, As a very regular user of these functions, I think this is useful to have both (and luckily you don't want to remove one or the other!). For the documentation, I agree that it could and should be clearer! For your proposition, I am quite reluctant on using dense and sparse in the documentation: There exist dense and sparse representations of polynomials in Sage, and I wonder if this would not confuse users. Some may think that f.coeffs is for densely represented polynomials and f.coefficients for sparsely represented ones. I think one could use as inspiration for the documentation of f.coefficients() the case of multivariate polynomials. It states Return the nonzero coefficients of this polynomials in a list. I find this formulation clear and simple enough. It is not clear to me that one should add the part one the correlation with f.exponents() that you proposed. In the same vein, I would propose Return all the coefficients of f in a list, including the coefficients equal to zero for f.coeffs. Anyway, I agree and you can open a ticket, I'll be happy to review it! Cheers, Bruno P.S.: On a related note, I am procrastinating for some time now the opening of a ticket to make the interfaces of univariate polynomial rings and multivariate polynomial rings more consistent. For instance, the leading coefficient is f.leading_coefficient() in the former and f.lc() in the latter. Many other things like that are a bit frustrating... Le 26/11/2014 21:06, john_perry_usm a écrit : Hello Sages Last week (?) I noticed that a program I wrote was making a mistake, because f.coeffs() and f.coefficients() return very different results: the former provides a dense representation (with 0's), the second a sparse one (no 0's, correlating with f.exponents()). I like this OK, but the help string isn't clear on this: the latter states merely, Return the coefficients of the monomials appearing in self; while the former states, Returns self.list(). The help on self.list() states merely, Returns a list with the coefficients of self. So the difference is that one states monomials /appearing/ in self, while the other does not clarify that it gives the monomials appearing in self, which presumably means it includes monomials /not/ appearing in self. I'm not good at these kinds of inferences, so this does not immediately convey dense or sparse representation, or not to me, anyway. I would propose the following: *f.coeffs?* should state something to the effect of, Returns all the coefficients of a dense representation of f. *f.coefficients?* should state something like, Returns all the coefficients of a sparse representation of f; that is, it returns only the non-zero coefficients, in a list correlated with f.exponents. (Notice the explicit statement of the correlation, reinforcing sparse representation.) *f.list?* should be mostly identical to f.coeffs? I'm willing to open a ticket author a patch to this effect, if at least one other person agrees here. john perry -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com mailto:sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com mailto:sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] coeffs() coefficients()
Thanks, everyone. I agree with Bruno's improvement on my suggestion. I will do this in the next few days, but I am first traveling, I may need a reminder. I also think the interfaces between univariate multivariate polynomials should be brought more in line, but that seems like quite a bit of work. Perhaps we could somehow sketch a partial beginning with obvious improvements, implement that? john perry On Wednesday, November 26, 2014 9:29:18 PM UTC+1, Bruno Grenet wrote: Hello John, As a very regular user of these functions, I think this is useful to have both (and luckily you don't want to remove one or the other!). For the documentation, I agree that it could and should be clearer! For your proposition, I am quite reluctant on using dense and sparse in the documentation: There exist dense and sparse representations of polynomials in Sage, and I wonder if this would not confuse users. Some may think that f.coeffs is for densely represented polynomials and f.coefficients for sparsely represented ones. I think one could use as inspiration for the documentation of f.coefficients() the case of multivariate polynomials. It states Return the nonzero coefficients of this polynomials in a list. I find this formulation clear and simple enough. It is not clear to me that one should add the part one the correlation with f.exponents() that you proposed. In the same vein, I would propose Return all the coefficients of f in a list, including the coefficients equal to zero for f.coeffs. Anyway, I agree and you can open a ticket, I'll be happy to review it! Cheers, Bruno P.S.: On a related note, I am procrastinating for some time now the opening of a ticket to make the interfaces of univariate polynomial rings and multivariate polynomial rings more consistent. For instance, the leading coefficient is f.leading_coefficient() in the former and f.lc() in the latter. Many other things like that are a bit frustrating... Le 26/11/2014 21:06, john_perry_usm a écrit : Hello Sages Last week (?) I noticed that a program I wrote was making a mistake, because f.coeffs() and f.coefficients() return very different results: the former provides a dense representation (with 0's), the second a sparse one (no 0's, correlating with f.exponents()). I like this OK, but the help string isn't clear on this: the latter states merely, Return the coefficients of the monomials appearing in self; while the former states, Returns self.list(). The help on self.list() states merely, Returns a list with the coefficients of self. So the difference is that one states monomials *appearing* in self, while the other does not clarify that it gives the monomials appearing in self, which presumably means it includes monomials *not* appearing in self. I'm not good at these kinds of inferences, so this does not immediately convey dense or sparse representation, or not to me, anyway. I would propose the following: *f.coeffs?* should state something to the effect of, Returns all the coefficients of a dense representation of f. *f.coefficients?* should state something like, Returns all the coefficients of a sparse representation of f; that is, it returns only the non-zero coefficients, in a list correlated with f.exponents. (Notice the explicit statement of the correlation, reinforcing sparse representation.) *f.list?* should be mostly identical to f.coeffs? I'm willing to open a ticket author a patch to this effect, if at least one other person agrees here. john perry -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com javascript:. To post to this group, send email to sage-...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
