Re: [sage-devel] Re: coeffs() & coefficients()
On Thursday, November 27, 2014 at 5:29:35 PM UTC+7, Nathann Cohen wrote: > > > Of course, proposing the statu quo may be unpopular ;-). Another > solution I > > can propose is to keep f.coefficients() as it is, make f.coeffs() an > alias > > of the former, and only keep f.list() for the list of all the > coefficients. > > If I understand what you said, you want "coefficients" to be left > unchanged for compatibility reasons with other classes, and you want > an easy way to get the *list* of coefficients too. While I do not see > why this dense/sparse=True argument would be a problem (it is only > optional, the default behaviour would not change), what about doing > that: > > 1) Remove .coeffs > 2) Update the doc of coefficients to hint that the *list* of > coefficients can be obtained through list(P), or P.list ? > > I thought that we tried in Sage to avoid short names/abbreviations > anyway, and it would also avoid the problem raised by Francis: a > function whose name abbreviates another's should be an alias, nothing > else. > > Nathann > How do remove .coeffs ? Help me -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: coeffs() & coefficients()
I *did ask if I should deprecate, I just wasn't sure if we can deprecate the alias. On Wed Dec 03 2014 at 4:10:25 PM john_perry_usm wrote: > Will the ticket you've opened also deal with multivariate polynomial > ideals, or are you working on symbolic expressions only? > Yes. It's almost always better to split such tickets. Note that Laurent polys don't have list() but have valuation(), so list() would be useful to have. -- 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] Re: coeffs() & coefficients()
On Thursday, November 27, 2014 2:23:09 AM UTC-8, Bruno Grenet wrote: > > While I agree that the current names can be confusing, we have to be > careful not to make something even more confusing. As mentioned earlier > by John, f.coefficients() is "correlated" with f.exponents() and I think > it is a good feature to keep, A drawback of this correlation is that it leads people to the wrong way of accessing this information. If you need both exponents (exponent vectors for multivariate) and the corresponding coefficients, then you should get those tied together. I think f.dict() does this, but I'm not sure if it does it very efficiently. Getting the exponents and coefficients is then just a matter of f.dict().keys() and f.dict().values() [which fully deserve to be called f.exponents() and f. coefficients()]. If "dict" is an inefficient data structure to be using here, perhaps there should be a routine that returns f.dict().items() , in that case obviously *not* going through a dict. -- 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] Re: coeffs() & coefficients()
Le 27/11/2014 11:29, Nathann Cohen a écrit : Of course, proposing the statu quo may be unpopular ;-). Another solution I can propose is to keep f.coefficients() as it is, make f.coeffs() an alias of the former, and only keep f.list() for the list of all the coefficients. If I understand what you said, you want "coefficients" to be left unchanged for compatibility reasons with other classes, and you want an easy way to get the *list* of coefficients too. While I do not see why this dense/sparse=True argument would be a problem (it is only optional, the default behaviour would not change), what about doing that: 1) Remove .coeffs 2) Update the doc of coefficients to hint that the *list* of coefficients can be obtained through list(P), or P.list ? You understand correctly, and I agree with your proposal (especially writing in the documentation of .coefficients how to get the full list of coefficients). Bruno -- 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] Re: coeffs() & coefficients()
> Of course, proposing the statu quo may be unpopular ;-). Another solution I > can propose is to keep f.coefficients() as it is, make f.coeffs() an alias > of the former, and only keep f.list() for the list of all the coefficients. If I understand what you said, you want "coefficients" to be left unchanged for compatibility reasons with other classes, and you want an easy way to get the *list* of coefficients too. While I do not see why this dense/sparse=True argument would be a problem (it is only optional, the default behaviour would not change), what about doing that: 1) Remove .coeffs 2) Update the doc of coefficients to hint that the *list* of coefficients can be obtained through list(P), or P.list ? I thought that we tried in Sage to avoid short names/abbreviations anyway, and it would also avoid the problem raised by Francis: a function whose name abbreviates another's should be an alias, nothing else. Nathann -- 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] Re: coeffs() & coefficients()
Le 27/11/2014 10:47, Nathann Cohen a écrit : It seems to me that as a general principle, a method whose name is an abbreviation of the name of another method should actually be the same method. Anything else is hugely confusing to a user. Both the functionalities described are, of course, useful, but giving them such similar names has a times certainly confused me. +1 In order to keep the two features, however, what would you think of a solution with coeffs, coefficients_list and coefficients_dict ? It does not look very clean, but that is the only way I see to make it clearer while not removing the abbreviation. This would require a deprecation for "coefficients", though. Alternative solution: it is possible to make coeffs an alias to coefficients, and to give them both the two features. coeffs(dense=True) == coefficients(dense=True) coeffs(sparse=True) == coefficients(sparse=True) This would require to pick a default value for sparse/dense, which also means that one of the two functions will have to display a deprecation warning for a while. While I agree that the current names can be confusing, we have to be careful not to make something even more confusing. As mentioned earlier by John, f.coefficients() is "correlated" with f.exponents() and I think it is a good feature to keep, and similarly I find important to keep the consistency with multivariate polynomials (for which only the notion of "nonzero coefficients" make sense). The difficulty to my mind, and this may have historically lead to the current situation, is that for the reasons I mentioned I think that f.coefficients() should return the nonzero coefficients, and on the other hand it is also important to have a simple way to ask for the list of all the coefficients. That's why I find the current situation better than having a argument "sparse/dense=True" to the function. For the other proposal of Nathann (coeffs, coefficients_list, coefficients_dict), I do not find it less confusing since I do not know which one(s) return the nonzero coefficients and which one(s) return the full list of coefficients! Of course, proposing the statu quo may be unpopular ;-). Another solution I can propose is to keep f.coefficients() as it is, make f.coeffs() an alias of the former, and only keep f.list() for the list of all the coefficients. Cheers, Bruno -- 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] Re: coeffs() & coefficients()
> It seems to me that as a general principle, a method whose name is an > abbreviation of the name of another method should actually be the same > method. Anything else is hugely confusing to a user. Both the > functionalities described are, of course, useful, but giving them such > similar names has a times certainly confused me. +1 In order to keep the two features, however, what would you think of a solution with coeffs, coefficients_list and coefficients_dict ? It does not look very clean, but that is the only way I see to make it clearer while not removing the abbreviation. This would require a deprecation for "coefficients", though. Alternative solution: it is possible to make coeffs an alias to coefficients, and to give them both the two features. coeffs(dense=True) == coefficients(dense=True) coeffs(sparse=True) == coefficients(sparse=True) This would require to pick a default value for sparse/dense, which also means that one of the two functions will have to display a deprecation warning for a while. Nathann -- 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.
