monomial basis for MPolyQuoLocRing

[Syz-MS]

Adding monomial basis for MPolyQuoLocRing in preparation for versal_deformation(HypersurfaceGerm).

@afkafkafk13 please have a look at this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.60%. Comparing base (7b49bb4) to head (298eb84).
Report is 15 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4235      +/-   ##
==========================================
+ Coverage   84.58%   84.60%   +0.01%     
==========================================
  Files         631      640       +9     
  Lines       85012    85135     +123     
==========================================
+ Hits        71911    72029     +118     
- Misses      13101    13106       +5     

Files with missing lines	Coverage Δ
src/Rings/mpoly-affine-algebras.jl	82.50% <100.00%> (+0.13%)	⬆️
src/Rings/mpolyquo-localizations.jl	73.67% <100.00%> (+0.20%)	⬆️

... and 26 files with indirect coverage changes

[afkafkafk13]

Could you also take care of localized rings? Up to now this seems only available for graded rings and affine algebras.

Sideremark: Do not shift the monomials back. They are still a basis after the shift (e.g. {1,x-3,x^2-6x+9 } spans the same vector space as {1,x,x^2}, but the latter is more human readable).

[Syz-MS]

Could you also take care of localized rings? Up to now this seems only available for graded rings and affine algebras.

Sideremark: Do not shift the monomials back. They are still a basis after the shift (e.g. {1,x-3,x^2-6x+9 } spans the same vector space as {1,x,x^2}, but the latter is more human readable).

@afkafkafk13 I just removed the backshift. Regarding the first part of your comment I am unsure which specific ring types in Oscar you are refering to.

[afkafkafk13]

Could you also take care of localized rings? Up to now this seems only available for graded rings and affine algebras.

Sideremark: Do not shift the monomials back. They are still a basis after the shift (e.g. {1,x-3,x^2-6x+9 } spans the same vector space as {1,x,x^2}, but the latter is more human readable).

To clarify, I was envisioning a method monomial_basis(R,I) for R a MPolyLocalizedRing and I an Ideal thereof. The benefit would be that the quo does not need to be generated on user level. Note that the other method immediately passes from R/I to localized ring and modulus anyway!

[wdecker]

To clarify, I was envisioning a method monomial_basis(R,I) for R a MPolyLocalizedRing and I an Ideal thereof.

Do you mean any type of MPolyLocalizedRing or just localizations at a point?

[afkafkafk13]

To clarify, I was envisioning a method monomial_basis(R,I) for R a MPolyLocalizedRing and I an Ideal thereof.

Do you mean any type of MPolyLocalizedRing or just localizations at a point?

Just for localizations at a point. I was already in contact with Marcel outside of github.

[Syz-MS]

Should I also move the functionality of monomial_basis(A::MPolyQuoRing) into monomial_basis(R::MPolyRing, I::MPolyIdeal) like I did in the local case in the last commit and therefore not creating the quotient at all in monomial_basis(R::MPolyRing, I::MPolyIdeal)?

[fingolfin]

Looking at this I was wondering "Why does one have to specify R at all? Why not just this:"

Suggested change

	function monomial_basis(R::MPolyRing, I::MPolyIdeal)
	base_ring(I) == R || error("ideal does not belong to the correct ring")
	function monomial_basis(I::MPolyIdeal)
	R = base_ring(I)

Perhaps the answer is "because this is not really a "monomial basis of I so we want to avoid the impression that is by giving two arguments". I can see why one would want to avoid writing down a quotient "just" to get this monomial basis. But it still feels at odds with fundamental OSCAR principles (where we like to avoid such tricks). And in any case, you still compute quo in here, so there is nothing being saved here...

Mathematically I think this is about finding a monomial basis of a complement of I in R. So an alternatively would be to do something like this:

Suggested change

	function monomial_basis(R::MPolyRing, I::MPolyIdeal)
	base_ring(I) == R || error("ideal does not belong to the correct ring")
	function monomial_basis_of_complement(I::MPolyIdeal)
	R = base_ring(I)

And then one could go a step further and move most of the body of the monomial_basis(A::MPolyQuoRing) method in here, as it only uses I, not the quotient ring?

[afkafkafk13]

Perhaps the answer is "because this is not really a "monomial basis of I so we want to avoid the impression that is by giving two arguments". I can see why one would want to avoid writing down a quotient "just" to get this monomial basis. But it still feels at odds with fundamental OSCAR principles (where we like to avoid such tricks). And in any case, you still compute quo in here, so there is nothing being saved here...

This is indeed the reason. monomial_basis(I) is absolutely not the way to go w.r.t. Oscar principles. But in particular in the context of germs and of ideal sheaves, you internally usually have an ideal in your hands and not a quotient ring when you find yourself in a setting to call monomial_basis.

To the remark with the quo: The lines here are not the key contribution of this PR. This is only the compatibility change, which currently does not touch the old code (as I do not know whether we are allowed to change this). The new contribution is in the local case (other file below) and there the quo is not computed, but monomial_basis(R,I) is the inner worker, whereas monomial_basis(quo...) is the outside appearance.
By the way, I would like to change the non-local case in the same way, if we are allowed to.

Mathematically I think this is about finding a monomial basis of a complement of I in R. So an alternatively would be to do something like this:
And then one could go a step further and move most of the body of the monomial_basis(A::MPolyQuoRing) method in here, as it only uses I, not the quotient ring?

NO, we are not looking at the complement. We are looking at the number of elements(=classes mod I) of the factorring R/I. I could live with monomial_basis_of_quo(I), but how do you type-dispatch on the type of the localization of R with this notation?

[afkafkafk13]

By the way: quo(R,I) also contains the R, even though it is not necessary. We simply tried to stay in tune with quo (thinking that it would certainly follow OSCAR's principles).

[thofma]

Since this is not returning a basis of $R/I$, but a lifted basis of $R/I$ to $R$, it is in fact a basis for the complement of $I$, complement as a $K$-subspace of $R$.

[afkafkafk13]

@wdecker: nobody wants to get rid of monomial_basis(A)! This is the way the average user should use it!

It is just a question of having a more internal, but documented variant for specialists (e.g. scripting, programming), which avoids creating the quo specifically to call monomial_basis which in turn immediately passes back to the modulus. This change is not done here yet. It is only done in the local case below. (But I would like to do it here as well.)

[wdecker]

If you document it, the user will find it. If it is internal, you may also put an _ in front. Also, you compute the quo anyway. So what do you gain?. Typing monomial_basis(R, I) instead of monomial_basis(quo(R, I)[1])? But, if it is important to you, I will not stand in your way.

[afkafkafk13]

I see this as an ok to put the work into the internal monomial_basis(R,I) and let the outside one monomial_basis(A) call it, like in the local case.

[fingolfin]

Same question as above: why not

Suggested change

	function monomial_basis(L::MPolyLocRing{<:Field, <:Any, <:Any, <:Any, <:MPolyComplementOfKPointIdeal}, I::MPolyLocalizedIdeal)
	base_ring(I) == L || error("ideal does not belong to the correct ring")
	function monomial_basis(I::MPolyLocalizedIdeal)
	L = base_ring(I)

(though perhaps with a different name)

[wdecker]

See my remark above.

[afkafkafk13]

This is not about the name, but about the type dispatch for the localization of the ring.

[thofma]

The type of the ring is the first parameter of the ideal, so it would be

blabla(I::MPolyLocalizedIdeal{MPolyLocRing{<:Field, <:Any, <:Any, <:Any, <:MPolyComplementOfKPointIdeal}})

[jankoboehm]

It should be sufficient to have a monomial basis command for the quotient ring.

[afkafkafk13]

ok. I won't insist on the global case, but the local one I would like to keep as it is right now -- moving the inner syntax to _monomial_basis (with its own docstring).

[wdecker]

How about adding a more meaningful example, that is, an example where the localization actually matters:

julia> R, (x,y) = QQ["x","y"];

julia> I = ideal(R, 2x^2-y^3, 2x^2-y^5) # two cusps
Ideal generated by
2x^2 - y^3
2x^2 - y^5

julia> A, _ = quo(R, I)
(Quotient of multivariate polynomial ring by ideal (2x^2 - y^3, 2x^2 - y^5), Map: R -> A)

julia> monomial_basis(A)
10-element Vector{QQMPolyRingElem}:
xy^2
y^2
x^3y
x^2y
xy
y
x^3
x^2
x
1

julia> L, _ = localization(A, complement_of_point_ideal(R, [0,0]));

julia> Iloc = ideal(L, 2x^2-y^3, 2x^2-y^5)
Ideal generated by
2x^2 - y^3
2x^2 - y^5

julia> Aloc,_ = quo(L, I)
(Localization of quotient of multivariate polynomial ring at complement of maximal ideal, hom: Localized quotient of multivariate polynomial ring -> Localized quotient of multivariate polynomial ring)

julia> monomial_basis(Aloc)
6-element Vector{Oscar.MPolyLocRingElem{QQField, QQFieldElem, QQMPolyRing, QQMPolyRingElem, Oscar.MPolyComplementOfKPointIdeal{QQField, QQFieldElem, QQMPolyRing, QQMPolyRingElem}}}:
xy^2
y^2
xy
y
x
1