The PolynomialRing that isn't

[Ricardo Buring]

Dear sage-devel,

I would like to drag up this old issue because it is a source of confusion and frustration for new users. The problem is that PolynomialRing uses (lib)Singular's ring without restricting the possible term orderings. Singular's ring is a polynomial ring _only if_ it is passed a "global" term ordering. If it is passed a "local" term ordering, then it is rather a localization of a polynomial ring. It is easy to see how this can be confusing when computing things that should be independent of the (global) term ordering, such as dimension (https://trac.sagemath.org/ticket/10708) or simply divisibility (https://ask.sagemath.org/question/52623/find-quotient-of-two-multivariate-polynomials-which-are-divisible/).

1. Can we add a warning about this current situation, e.g. in the PolynomialRing constructor?
    This was suggested on Ask SageMath: https://ask.sagemath.org/question/52699/suggestion-for-documentation-of-multivariate-polynomials/
    The current documentation, "return the (...) polynomial ring (...)" is incomplete.

2. How much SageMath functionality depends on localizations, and is currently (ab)using PolynomialRing in this way?
    So far, I find: ToricIdeal, LetterplaceIdeal, InteractiveLPProblem, GroebnerStrategy (in tests), PathAlgebra, PathAlgebraElement, PathSemigroup, PowerSeriesRing, MPowerSeriesRing_generic, PolynomialSequence_generic (for no particular reason), AlgebraicScheme_subscheme_affine, MPolynomialIdeal (in tests).
    It's not that much, so it would (internally) not be that big a deal if the interface (the way to construct localizations of polynomial rings) changed.

3. How should these two functionalities of Singular (ideally) be exposed in SageMath?
    Easy but ugly: add phrases like "(or a localization thereof)" to the docs, and maybe add a localization flag to the PolynomialRing constructor to explicitly allow local orderings.
    I think it would be better to somehow separate the two. I suppose there should be a common base class, for simplicity of interaction with (lib)Singular.
    Could we add a constructor like PolynomialRingLocalization? Let that one accept the local orderings, and let PolynomialRing accept only global orderings.
    I guess the difficulty is to make everything work out with the parents and categories frameworks. Can somebody comment on that?
    By the way, it is a bit unfortunate that the interface to Singular's ring is called MPolynomialRing_libsingular rather than just Ring_libsingular (in view of this issue).

Best regards,
Ricardo

[Vincent Delecroix]

A warning is likely to show up in a lot of place in the
current source code, isn't it?

Please consider integrating the recent flint implementation

http://flintlib.org/sphinx/fmpz_mpoly.html
http://flintlib.org/sphinx/fmpq_mpoly.html
http://flintlib.org/sphinx/nmod_mpoly.html

Having this interfaced is desirable and might help for the
global design of multivariate polynomial rings in Sage.

Vincent

[Sebastian Oehms]

Recently I made some suggestions about that in this thread.

Best,

Sebastian

[Nils Bruin]

On Monday, July 27, 2020 at 5:25:16 AM UTC-7, Ricardo Buring wrote:

Dear sage-devel,

I would like to drag up this old issue because it is a source of confusion and frustration for new users. The problem is that PolynomialRing uses (lib)Singular's ring without restricting the possible term orderings. Singular's ring is a polynomial ring _only if_ it is passed a "global" term ordering. If it is passed a "local" term ordering, then it is rather a localization of a polynomial ring.

 

So, mathematically we shouldn't allow singular's local term orderings on polynomial rings. We should have an appropriate localization in place instead. We already have some types in that direction; think Laurent polynomials and power series, for instance.

There are probably non-mathematical reasons why we (and singular!) allow them currently:

 1) Does singular actually implement the localizations fully? It may be that 1+x is considered a unit but that the inverse can't be represented.

 2) There may be a lot of code replication if you do separate them out in separate types

 3) The usage scenarios are so limited that the hack is considered sufficient.

If the answer to 1) is affirmative, then the sage type could be just a wrapper. Otherwise we would need to provide the missing functionality.

Problem 2) can be mitigated by judiciously choosing an inheritance structure (hopefully) so that as much code as possible can be shared.

Problem 3) is another scenario. In the longer term I don't think this will hold, but if people want to go with that, there's not much to do other than documenting appropriately. Quite frankly I have not much sympathy for users who just plug in a random option and are then surprised by the results. Local term orderings are not term orderings at all in the traditional sense.