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

mantepse · 2024-09-28T19:15:58Z

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.

…nt for MPolynomialRing_base.monomial

github-actions · 2024-09-28T20:22:24Z

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

mantepse · 2024-09-29T08:34:22Z

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

mantepse · 2024-09-29T09:36:03Z

fixed, silly thinko.

mantepse · 2024-09-29T18:07:39Z

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

mantepse · 2024-09-30T08:15:35Z

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

src/sage/rings/polynomial/multi_polynomial_ring_base.pyx

tscrim

LGTM.

mantepse · 2024-10-01T07:24:36Z

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

mantepse · 2024-10-01T07:29:49Z

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 · 2024-10-01T10:00:22Z

The plural failure should be unrelated, see #38737

tscrim

Your dict redirect methods need a doctest though.

mantepse · 2024-10-04T02:27:41Z

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 · 2024-10-04T02:30:34Z

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 · 2024-10-04T02:32:53Z

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 · 2024-10-04T02:38:14Z

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

tscrim · 2024-10-04T02:38:58Z

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 · 2024-10-04T02:43:31Z

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 · 2024-10-04T04:47:55Z

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 · 2024-10-04T04:52:07Z

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 · 2024-10-04T05:04:44Z

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 · 2024-10-04T06:40:17Z

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.

src/sage/algebras/cluster_algebra.py

src/sage/algebras/commutative_dga.py

mantepse · 2024-10-04T16:32:49Z

src/sage/algebras/letterplace/free_algebra_element_letterplace.pyx

        """
-        cdef dict d = self._poly.dict()
+        cdef dict d = self._poly.monomial_coefficients()
        yield from d.iteritems()


should I do

Suggested change

yield from d.iteritems()

yield from d.items()

throughout?

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

tscrim

Thanks. LGTM.

mantepse · 2024-10-07T07:22:18Z

Thank you :-)

mantepse · 2024-10-08T08:32:05Z

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

tscrim · 2024-10-08T09:37:40Z

Ah, sorry, I thought I did that.

sagemathgh-38729: provide monomial_coefficients for polynomials and allow single argument for MPolynomialRing_base.monomial 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. URL: sagemath#38729 Reported by: Martin Rubey Reviewer(s): Frédéric Chapoton, Martin Rubey, Travis Scrimshaw

sagemathgh-38767: polynomials/fix category We put polynomials (and friends) into the category of algebras with basis. Dependencies: sagemath#38729 URL: sagemath#38767 Reported by: Martin Rubey Reviewer(s): Travis Scrimshaw

sagemathgh-38108: Implicit function solver for lazy series This pull request provides a method `define_implicitly` for lazy rings that allows to produce lazy power series solutions for systems of functional equations, in relatively great generality, superseding sagemath#37033. We use a special action to make sure that coercion between `CoefficientRing` and its base ring works as desired. However, it is a local change, if the current approach eventually shows its shortcomings. (Alternative approach previously considered: Using a special functor to control the pushout behaviors. The action approach was chosen as a way to prevent potential conflicts with other construction functors that may appear in the future.) Dependencies: sagemath#38729 URL: sagemath#38108 Reported by: Martin Rubey Reviewer(s): Martin Rubey, Travis Scrimshaw

provide monomial_coefficients for polynomials and allow single argume…

bf7f14f

…nt for MPolynomialRing_base.monomial

github-actions bot added the s: needs review label Sep 28, 2024

Merge branch 'develop' into polynomials/monomial_coefficients

c4138fd

fix thinko

3dfdfa6

Merge branch 'develop' into polynomials/monomial_coefficients

aba786c

mantepse mentioned this pull request Sep 30, 2024

Implicit function solver for lazy series #38108

Merged

allow ETuples as well

4729f84

add line for linter

9a37e27

mantepse requested review from fchapoton and tscrim September 30, 2024 08:17

fchapoton reviewed Sep 30, 2024

View reviewed changes

src/sage/rings/polynomial/multi_polynomial_ring_base.pyx Outdated Show resolved Hide resolved

use cimport

1a94d8f

tscrim approved these changes Sep 30, 2024

View reviewed changes

tscrim added t: enhancement s: positive review c: commutative algebra and removed s: needs review labels Sep 30, 2024

mantepse added s: needs work and removed s: positive review labels Oct 1, 2024

provide monomial_coefficients for all kinds of polynomials

4517525

github-actions bot added s: needs review and removed s: needs work labels Oct 1, 2024

tscrim requested changes Oct 4, 2024

View reviewed changes

mantepse mentioned this pull request Oct 4, 2024

polynomials/fix category #38767

Merged

mantepse commented Oct 4, 2024

View reviewed changes

src/sage/algebras/cluster_algebra.py Show resolved Hide resolved

mantepse commented Oct 4, 2024

View reviewed changes

src/sage/algebras/commutative_dga.py Show resolved Hide resolved

mantepse commented Oct 4, 2024

View reviewed changes

mantepse added 2 commits October 5, 2024 12:06

make dict an alias to avoid duplicating docstrings

81f9a96

replace iteritems with items in modified files

38904b6

tscrim approved these changes Oct 7, 2024

View reviewed changes

tscrim added s: positive review and removed s: needs review labels Oct 8, 2024

vbraun merged commit 73874f0 into sagemath:develop Oct 12, 2024
22 of 26 checks passed

github-actions bot removed the s: positive review label Oct 12, 2024

mantepse deleted the polynomials/monomial_coefficients branch October 13, 2024 08:41

Uh oh!

Uh oh!

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

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

Uh oh!

Conversation

mantepse commented Sep 28, 2024

Uh oh!

github-actions bot commented Sep 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mantepse commented Sep 29, 2024

Uh oh!

mantepse commented Sep 29, 2024

Uh oh!

mantepse commented Sep 29, 2024

Uh oh!

mantepse commented Sep 30, 2024

Uh oh!

Uh oh!

tscrim left a comment

Choose a reason for hiding this comment

Uh oh!

mantepse commented Oct 1, 2024

Uh oh!

mantepse commented Oct 1, 2024

Uh oh!

mantepse commented Oct 1, 2024

Uh oh!

tscrim left a comment

Choose a reason for hiding this comment

Uh oh!

mantepse commented Oct 4, 2024

Uh oh!

tscrim commented Oct 4, 2024

Uh oh!

mantepse commented Oct 4, 2024

Uh oh!

mantepse commented Oct 4, 2024

Uh oh!

tscrim commented Oct 4, 2024

Uh oh!

tscrim commented Oct 4, 2024

Uh oh!

mantepse commented Oct 4, 2024

Uh oh!

tscrim commented Oct 4, 2024

Uh oh!

mantepse commented Oct 4, 2024

Uh oh!

tscrim commented Oct 4, 2024

Uh oh!

Uh oh!

Uh oh!

mantepse Oct 4, 2024

Choose a reason for hiding this comment

Uh oh!

tscrim Oct 4, 2024

Choose a reason for hiding this comment

Uh oh!

tscrim left a comment

Choose a reason for hiding this comment

Uh oh!

mantepse commented Oct 7, 2024

Uh oh!

mantepse commented Oct 8, 2024

Uh oh!

tscrim commented Oct 8, 2024

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Sep 28, 2024 •

edited

Loading