Clarify how monomial orderings are supposed to be specified

[joschmitt]

Is your feature request related to a problem? Please describe.
There is a lot of potential for confusion in how one can specify monomial orderings in OSCAR (see e.g. a question by @gfourier in Slack some time ago and #3039).

• One can either give an ordering with the ring ("Singular style"):

julia> R, (x, y, z) = polynomial_ring(QQ, ["x", "y", "z"], ordering = :degrevlex)

There are only three different orderings available and this appears to be used for the functionality from AbstractAlgebra.jl, most prominently divrem and printing.

• Secondly, there are the fancy orderings of type MonomialOrdering which one specifies for e.g. leading_term, groebner_basis and so on.

Describe the solution you'd like
There should be a consistent way of using monomial orderings in OSCAR.

Additional context
I think we should get rid of the orderings from AbstractAlgebra.jl. I lost track of what the state of divrem vs normal_form is though.

[thofma]

I don't think we can "get rid" of those orderings, but we can choose to make them disappear in the user interface.

[YueRen]

I second the suggestion of removing the orderings from AbstractAlgebra.jl.

[fingolfin]

I am not sure we can remove this option? What is it used for: to affect printing of polynomials, it seems... Anything else (@fieker / @thofma ?).

If it is just that, perhaps renaming it to printing_ordering or so would be an option.

[joschmitt]

It is also used for divrem...

[YueRen]

One option is to write a function that takes the monomial ordering of the polynomial ring, which are orderings from AbstractAlgebra.jl, and return a monomial ordering for Singular. We can then use that function to make groebner_bases respect the default ordering of the polynomial ring.

[joschmitt]

I don't like this idea (assuming I understand it correctly). The default value for the ordering keyword argument is :lex. I think most people would be surprised if we compute Gröbner bases w.r.t. lex by default?
In my opinion, we should hide the ordering in the polynomial ring constructor as much as possible from the non-expert user or at least clarify in the documentation what this ordering does. The latter is a bit difficult though since the documentation would be in AbstractAlgebra where we cannot reference the OSCAR documentation for monomial orderings (I think?).

[YueRen]

@joschmitt Very true! If groebner_basis takes the ordering of the ring by default, then the default ordering of the ring needs to be changed to degree reverse lexicographic.

[jankoboehm]

It doesn't. The abstract algebra ordering should be hidden as far as we can. The ring has a default OSCAR ordering (in an attribute, but that could be moved to a field) which is the reasonable for the respective ring (in the non-graded case degree reverse lex). This is the ordering which is used for Gröbner bases.

[joschmitt]

In my opinion, we should "hide" the ordering keyword of polynomial_ring.

• This ordering is not used in a way a user might expect. In particular, there is no relationship between ordering(R) and default_ordering(R).
• The ordering is barely used and no non-expert user should need to change it. The only exception would be the function divrem.
• Many functions in OSCAR come with a ordering keyword (groebner_basis, leading_monomial, ...) which accept a different type and have completely different meaning than the ordering of polynomial rings.

I see two options how we could resolve this; both are "breaking" and need to be done before 1.0:

1. Rename the keyword to e.g. internal_ordering as proposed in Hide ordering a bit Nemocas/AbstractAlgebra.jl#1597 .
2. Stop importing polynomial_ring in OSCAR and overwrite the functions, so that the ordering keyword is completely gone (AbstractAlgebra would stay unchanged). Expert users can still call the AbstractAlgebra method directly to set the ordering.

Option 2 would require more maintenance effort as any signature that is changed in AbstractAlgebra needs to be adjusted correctly in OSCAR too (depending how we do it). Still, right now I would prefer 2.

EDIT: The decision is to go with option 1 and possibly adjust the OSCAR documentation a bit.