See https://trac.sagemath.org/ticket/33813 for a somewhat related issue, by
the way.
On Wednesday, October 19, 2022 at 1:18:56 PM UTC-7 john.c...@gmail.com
wrote:
> My suggestion was only for univariate polynomials. I am certainly not
> proposing this for multivariate polynomials. I still
Isn't that to make the interface between univariate and multivariate
polynomials compatible? Changing the default may break code that can
currently work with univariate and multivariate polynomial rings
interchangeably.
On Wednesday, 19 October 2022 at 09:34:59 UTC-7 john.c...@gmail.com wrote:
My suggestion was only for univariate polynomials. I am certainly not
proposing this for multivariate polynomials. I still cannot think of
a use case for the current default for univariate polynomials. (And,
more than one person has complained to me about this "very annoying
and
> Could it be it's the same default for univariate and multivariate cases?
In the latter case, it's easier to blow off memory usage to store zeros...
You are right. In fact, the multivariate coefficients method does not even
have a "sparse" option.
Le mercredi 19 octobre 2022 à 16:10:13
Could it be it's the same default for univariate and multivariate cases? In
the latter case, it's easier to blow off memory usage to store zeros...
On Wed, 19 Oct 2022, 21:06 David Ayotte, wrote:
> I agree with this suggestion. Whenever I am looking for the coefficients
> of a polynomial, I
I agree with this suggestion. Whenever I am looking for the coefficients of
a polynomial, I also use the option "sparse=False" as this gives me
indirect information about the degree of each associated monomial. In fact,
I remember being a bit confused when I first used this method.
Best,
Does anyone ever use pol.coefficients() and not
pol.coefficients(sparse=False)? I mean, why is the default option
sparse=True? There must be very few occasions for the default,and I
get tired of typing sparse=False I do know that pol.list() is the
same as pol.coefficients(sparse=False).
I
John H Palmieri wrote:
> I like the idea of mimicking the trac setup, but moving away from trac
> also lets us reconsider parts of the trac interface. I personally do
> not find the "Priority" label very helpful, other than whether it's a
> blocker or not. What do others think?
I agree about the
