provide monomial_coefficients for polynomials and allow single argument for MPolynomialRing_base.monomial

[mantepse]

The goal of this pull request is to allow generic programming with instances of CombinatorialFreeModule and polynomial rings.

In particular, we provide an alias monomial_coefficients for the existing method dict of polynomial rings, and we allow to specify the exponents in monomial of multivariate polynomial rings as a single tuple.

[github-actions]

Documentation preview for this PR (built with commit 92c4646; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[mantepse]

The failure in quantum_clifford is real, I'm looking into it.

[mantepse]

fixed, silly thinko.

[mantepse]

I cannot reproduce the test failure in src/sage/rings/polynomial/polynomial_element.pyx on my computer.

[mantepse]

I thought that ETuples would be tuples, but that is not the case.

[tscrim]

LGTM.

[mantepse]

I made another mistake, sorry. There are several places where dict is defined, and I want to make things more generic, not less :-)

[mantepse]

I think it would actually be good to deprecate the dict method. The name does not make it clear what it does, and it does something very different to the dict function. However, it is probably better to open a separate pull request for that.

[mantepse]

The plural failure should be unrelated, see #38737

[tscrim]

I wouldn't worry too much about aligning dict and monomial_coefficients everywhere. The former is not a category-specified thing.

[tscrim]

Your dict redirect methods need a doctest though.

[mantepse]

I wouldn't worry too much about aligning dict and monomial_coefficients everywhere. The former is not a category-specified thing.

Yes. But my goal is to see whether we can make the functionality category-specified, and eventually deprecate dict.

[tscrim]

I wouldn't worry too much about aligning dict and monomial_coefficients everywhere. The former is not a category-specified thing.

Yes. But my goal is to see whether we can make the functionality category-specified, and eventually deprecate dict.

I probably would not do that since that method is about the return type of the data for the object rather than something mathematical. I would rather let each implementation handle it as it sees fit.

[mantepse]

I wouldn't worry too much about aligning dict and monomial_coefficients everywhere. The former is not a category-specified thing.

Yes. But my goal is to see whether we can make the functionality category-specified, and eventually deprecate dict.

I probably would not do that since that method is about the return type of the data for the object rather than something mathematical. I would rather let each implementation handle it as it sees fit.

Yes, I agree.

[mantepse]

Putting polynomials into a graded category is not desired, if I recall correctly? There is no comment in the code though.

[tscrim]

I probably would not do that since that method is about the return type of the data for the object rather than something mathematical. I would rather let each implementation handle it as it sees fit.

Yes, I agree.

I might have misunderstood your intent. Perhaps I should also clarify that I am not in favor of deprecating dict, but perhaps encouraging the use of monomial_coefficients when that is the desired information. It happens to align with the data for, e.g., polynomials, but people might want to actually think of it as a dict. Perhaps that is also a distinction without a difference...

[tscrim]

Putting polynomials into a graded category is not desired, if I recall correctly? There is no comment in the code though.

By default, yes, because the morphisms would become too restrictive for most users. What we should do is add an input to specify the grading to each variable, in which case it is clear the user wanted a graded object. (The is what the free algebra does.)

[mantepse]

Putting polynomials into a graded category is not desired, if I recall correctly? There is no comment in the code though.

By default, yes, because the morphisms would become too restrictive for most users. What we should do is add an input to specify the grading to each variable, in which case it is clear the user wanted a graded object. (The is what the free algebra does.)

I'm very sorry, my question was wrong. It should have been: "Puting polynomials into the category of algebras with basis is not desired, if I recall correctly?"

[tscrim]

Putting polynomials into a graded category is not desired, if I recall correctly? There is no comment in the code though.

By default, yes, because the morphisms would become too restrictive for most users. What we should do is add an input to specify the grading to each variable, in which case it is clear the user wanted a graded object. (The is what the free algebra does.)

I'm very sorry, my question was wrong. It should have been: "Puting polynomials into the category of algebras with basis is not desired, if I recall correctly?"

That I don't recall, and I can't see why. They are already implemented as such effectively...

[mantepse]

Oh, that's good news! I'll try to add _indices and

diff --git a/src/sage/rings/polynomial/polynomial_ring_constructor.py b/src/sage/rings/polynomial/polynomial_ring_constructor.py
index a135fe8de6c..12cceaf4c05 100644
--- a/src/sage/rings/polynomial/polynomial_ring_constructor.py
+++ b/src/sage/rings/polynomial/polynomial_ring_constructor.py
@@ -932,7 +932,7 @@ def polynomial_default_category(base_ring_category, n_variables):
         sage: QQ['s']['t'].category() is UniqueFactorizationDomains() & CommutativeAlgebras(QQ['s'].category()).Infinite()
         True
     """
-    category = Algebras(base_ring_category)
+    category = Algebras(base_ring_category).WithBasis()
 
     if n_variables:
         # here we assume the base ring to be nonzero

[tscrim]

In principle, the _indices should be an implementation detail left to the classes, and nothing in the category-provided code should be using it. It’s possible that is not the case though, but the other implementations do not have to follow the CFM design pattern.

[mantepse]

should I do

Suggested change

	yield from d.iteritems()
	yield from d.items()

throughout?

[tscrim]

This can be changed since it was part of the Python3 transition.

[tscrim]

Thanks. LGTM.

[mantepse]

Thank you :-)

[mantepse]

Hm, can I set this to "positive review"?

[tscrim]

Ah, sorry, I thought I did that.