Design for the modules

[HechtiDerLachs]

Oscar.jl/src/Modules/UngradedModules.jl

Line 493 in 1a361bf

mutable struct ModuleGens{T}

This looks like the analogue of the BiPolyArray for polynomial rings in Oscar. But does it work for towers of polynomial rings? Or any other type of ring which is not free polynomial over an admissible field?

In the beginning of the file, the type parameter T suggests that it can be used for any type of (elements of a) ring, but it seems that with the advent of ModuleGens, there is a very harsh implicit restriction on what T can really be. Are there possibilities that this can be really widened up so that one can also use quotient rings, localizations of polynomial rings, towers of polynomial rings, etc.? Ideally, one would then have a BiPolyArray-structure for either of these cases with a resolution of the singular functionality via dispatch. Do you see any possibilities to introduce such flexibility here?

[HechtiDerLachs]

@jankoboehm , @AlexD97 , @wdecker

[HechtiDerLachs]

A comment on the side:

Oscar.jl/src/Modules/UngradedModules.jl

Line 868 in 1a361bf

gens::ModuleGens

Shouldn't these entries also be typed using T?

Probably similar here?

Oscar.jl/src/Modules/UngradedModules.jl

Line 1118 in 1a361bf

sub::SubModuleOfFreeModule

[HechtiDerLachs]

Just to make clear where this is heading:

I would like to introduce coherent sheaves on varieties. For this, it would be convenient if I could use the module concepts also over localizations and quotient rings of polynomial rings, as these have been used heavily for the affine schemes. Now the question is to which extend the code on modules is generic and which parts have to be specialized.

Similar questions apply to projective schemes and graded modules, later on.

[jankoboehm]

The module concept is set up that it can used/easily adapted for further settings. In general our goal is to avoid code duplication in what we are doing at the moment for the further settings. For the graded case and modules over quotients of polynomial rings adaptation is easy. For localizations the Gröbner machinery on the Singular side is limited to localizations at coordinate hyperplanes, but from that is is easy to produce on the Oscar side an abstraction layer for localizations at prime ideals. For anything more general, litte is available on the Gröbner side and one has to see what can be done algorithmically. The driving force should be what is needed in applications.

[HechtiDerLachs]

I've been playing a little with the modules today and I encounter the following issue. It is important to use the latest version of this branch, because only here do we have the implementations of some required methods.

R, (x,y) = PolynomialRing(QQ, ["x", "y"])
X = Spec(R)
W = OO(X)
A = W[x^2; y^2]
B = W[x;y]
F = FreeMod(W, 1, "e")
M = SubQuo(F, B, A)

As far as I can see, there is no mathematical obstruction to defining subquotients for rings R which are localizations of polynomial algebras. But:

1. this is not possible at this stage, because singular_assure is called (in some inappropriate place? See also this issue) and
2. the question is whether we really want to implement the localizations of modules this way.
   Regarding 2): The alternative would be that I manually implement another type SubQuoLocalizedModule similar to rings. But my first impression is that this is not really the way to go and I would rather use the generic code for finitely generated modules and only implement another dispatch on that.

Any opinions?

[jankoboehm]

Our strategy is to use the generic code for the local case to avoid code duplication, as we do for the graded and filtered case. If you make a list of what you need, we can probably provide rather quickly a nucleus which can do the necessary for you.

[HechtiDerLachs]

I have to admit that it is difficult to come up with a concise list of necessities regarding the functionality of modules. Maybe it is best if we discuss this somewhere live in person?

Skimming through your code, it seems to me that the following modification might already be a good start: ModuleGens has two internal constructors, both of which need a Singular module as input. Comparing this with BiPolyArray, I'm wondering: Couldn't you alter this to two constructors with one of them taking input only from the Oscar-side and the other one only from the Singular-side?

Then, depending on the type parameter T, one could implement specific methods for singular_assure, the translation from one side to the other, equality checks, reduction, etc.

Finally, it would be great if the functionality can be extended to all rings R on the Oscar side, that have a free polynomial ring P as a work-horse in the backend, such as quotient rings, localizations, etc.