How to set up Singular functionality for generic polynomial rings?

[HechtiDerLachs]

Say, I have a ring of coefficients A and I would like to do computations in the ring B, (x,y,z) = PolynomialRing(A, ["x", "y", "z"]). Up to now, the Singular functionality is available whenever A can be converted to a corresponding singular ring. But, for example, when A = QQ[t], I get an error message for now.

Is it possible to write a generic functionality to cook up the singular rings for generic polynomial rings over coefficient rings A whenever we already have an Oscar <-> Singular correspondence implemented for A?

On the singular side, this would then flatten the structure by simply adding the variables to the singular_ring(A) while on the Oscar side, we can benefit from the separation of the two types of variables.

Are such ideas coherent with the current design for Oscar? If yes, what would be the correct points to start? Oscar itself, or even Singular.jl?

@tthsqe12 @thofma

[thofma]

Sorry, I don't understand the question. This is working:

julia> A, = QQ["t"];

julia> B, (x,y,z) = PolynomialRing(A, ["x", "y", "z"]);

julia> singular_ring(B)
Singular Polynomial Ring (Coeffs(17)),(x,y,z),(lp(3),C)

Could you give a concrete example of something that is not working and should be working?

[HechtiDerLachs]

Good to see that the translation to the singular side already exists in this case. However, ideal membership fails, for instance:

A, (t) = PolynomialRing(QQ, ["t"])
t = t[1]
R, (x,y,z) = PolynomialRing(A, ["x", "y", "z"])
I = ideal(R, [x*t])
S = singular_ring(R)
t in I
x in I
x*t in I

[HechtiDerLachs]

Btw: It is very annoying that in the above example t is assigned a vector of variables, i.e. the behaviour depends on the number of variables in A.

[thofma]

No, it does not depend on the number of variables. If the variables are a vector, the second return value is also a vector. A, (t) = is just the same as A, t =.

In the above, the ring S has nothing to do with t, x or I. The call t in I is failing because t is not an element of the ring over which I is defined. The call x in I gives

ERROR: TypeError: in typeassert, expected fmpq_mpoly, got a value of type Singular.spoly{Singular.n_Q}

This is a bug and an issue should be opened.

[wdecker]

By the way:

julia> A, (t) = PolynomialRing(QQ, ["t"])
(Multivariate Polynomial Ring in t over Rational Field, fmpq_mpoly[t])

julia> t
1-element Vector{fmpq_mpoly}:
t

julia> A, (t,) = PolynomialRing(QQ, ["t"])
(Multivariate Polynomial Ring in t over Rational Field, fmpq_mpoly[t])

julia> t
t

[HechtiDerLachs]

Alright, thanks for the feedbacks! I will consider opening an issue about the first thing. But after talking with @tthsqe12 today, it seems that there are even more bugs down the road when translating Oscar rings to coefficient rings in Singular, so I'm not sure how reasonable it is to raise this particular issue at this point, before other things like https://github.com/oscar-system/Singular.jl/issues/416#issuecomment-824953842 are not yet addressed.

[HechtiDerLachs]

After some discussions today, I will try to make my question/suggestion more precise.

For some particular setups and questions, it is preferable to have polynomial rings in Oscar in the form of a tower of rings. So I presume that we would like to have the functionality like ideal membership, presentation of modules etc. available for generic polynomial rings R over arbitrary coefficient rings A. Yet, for the algorithmic backend using Singular, it will be best, to flatten such structures as much as possible before running any Groebner-basis algorithm on a particular problem. So what we wish to have on the Oscar and the Singular side, respectively is

 (Oscar side)                                 (Singular side)
R = (QQ[t])[x,y,z]      <---vs--->      SingR = QQ[t,x,y,z]

One way to achieve this, is to explicitly flatten R already on the Oscar side before going to the Singular side:

                       (Oscar side)                                             (Singular side)
R = (QQ[t])[x,y,z]    isomorphic to   Rflat = QQ[t,x,y,z]     <---vs--->      SingR = QQ[t,x,y,z]

But depending on the problem, one will also have a preferred ordering on SingR, for instance a block ordering with (x,y,z) in the first block and (t) in the second. If one was first flattening the ring on the Oscar side, one would have to take care of applying this ordering to the Singular side manually.

Instead of the Oscar sided flattening, I propose the following. Provide a function

flat_singular_ring(R::MPolyRing{T}) where {T}

that recursively checks whether A = coefficient_ring(R) already admits a translation to the singular side and then automatically sets up the flat singular side with a block ordering for the variables of R. This would have to come in a package with automated conversion of elements to from either side to the other.

This would then provide a (hopefully) performant computational backend for the generic polynomial rings which could probably also be extended to modules over these rings.

[tthsqe12]

Singular.jl likes polynomial rings over fields F, and it is even happier when F is a native Singular field.
For now, we can have a two step process:

oscar QQ[x,y][z,w]
<=>
oscar QQ[z,w,x,y]
<=>
singular QQ[z,w,x,y]  with some block ordering

However, the denesting code will have to be modified a bit to get the block sizes.

[HechtiDerLachs]

Thanks for the reply. After all, it seems likely that an enhanced Oscar-sided conversion pattern is more practical to achieve. Also, for the particular applications that I had in mind, it might be better to have another workaround along these lines. However, that does not address the question how to implement a performant computational backend for generic polynomial rings using Singular which might be an issue of its own interest.