homogenization for ideal with ZZ^m grading

[JohnAAbbott]

Homogenization for ideals in ZZ^m-graded ring.
Also trick to make it a bit faster (sometimes).

[codecov]

Codecov Report

Merging #2372 (083490b) into master (c9b9a80) will decrease coverage by 0.55%.
The diff coverage is 15.54%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2372      +/-   ##
==========================================
- Coverage   72.66%   72.11%   -0.55%     
==========================================
  Files         429      429              
  Lines       60036    60501     +465     
==========================================
+ Hits        43623    43633      +10     
- Misses      16413    16868     +455     

Files Changed	Coverage Δ
src/Rings/mpoly-graded.jl	73.76% <14.38%> (-8.82%)	⬇️
experimental/PlaneCurve/src/AffinePlaneCurve.jl	88.82% <100.00%> (ø)

... and 22 files with indirect coverage changes

[wdecker]

Do not remove this line as it has not yet been addressed:

TODO: Adjust for ZZ-gradings as soon as weighted orderings are available

[wdecker]

aaa

[wdecker]

Sorry, what I mean here is that you should not returnI as you have to return an ideal in a new polynomial ring with homogenizing variables added.

[wdecker]

You are performimg two additional GB computations here. I agree that adding smaller elements may be helpful with respect to speed but is this also true when you use GB computations to find the elements?

[JohnAAbbott]

I made some "randomly generated" tests, and it was generally faster (and only rarely a bit slower) when using these GB computations. If you have some "real" inputs, we can test them. In summary: the costs of these two GB computations were (usually) lower than the speed gain when computing the saturation. Conceivably, this may change when Hans has a better implementation of saturation -- the question should then be revisited.
Of course, if you have a better way of generating further "small" elements of the ideal, let me know.

[wdecker]

Of course, your subsequent test is_one(I) mentioned already above computes a REDUCED degrevlex GB which would be completely superfluous whenever the ideal is not the whole ring. In total you introduced 3 superfluous GB computations. The subsequent saturation step would detect whether the original ideal is the whole ring anyway.

[JohnAAbbott]

I am considering changing the "short-cut" case to

 if all(is_homogeneous, gens(I)) 
        Hgens = homogenization(gens(I))
        return ideal(parent(Hgens), Hgens)

The zero ideal needs some special handling (which I have omitted here).

[JohnAAbbott]

Ah! The weight matrix W is an input parameter, and not intrinsic to the graded ring... ?1?

[wdecker]

I do not understand. What is the short-cut case? Also, I do not understand your code. You homogenize the generators with respect to the standard ZZ-grading if they are homogeneous with respect to the standard ZZ-grading?

And which weight matrix do you mean?

[JohnAAbbott]

OK, maybe the "short-cut case" is useless: I meant if the given generators already happen to be homogeneous (with respect to W). I'll ask Hans whether saturation by a variable which does not appear in the generators as handled efficiently... if so, then my "short-cut" is quite unnecessary. The call to homogenization when the generators are already homogeneous is simply to map them into the correct ring [as you pointed out].
I am puzzled as to why the input parameters to homogenization(I,W,var,pos) include W, var and pos. I would have expected these 3 parameters to be "instrinsic" to the graded polynomial ring. The documentation says that is_homogeneous takes just 1 argument; and the examples suggest that the grading used is that of the graded polynomial ring. So it is not clear to me why I must specify W when calling homogenization. To some extent I can understand why var and pos are necessary (though it seems like they should be recorded inside the graded polynomial ring along with the weight matrix W)

[wdecker]

The point here is that, typically, we do not have the graded ring yet. That is, I is not an ideal of a graded ring . So you need to tell the function with respect to which grading it should homogenize. One method for is_homogeneous is Bill's AA version of is_homogeneous which checks whether a polynomial is homogeneous with respect to the standard ZZ-grading (so this applies also to polynomials in non-graded rings, but has a specific grading in mind). The methods is_homogeneous we implemented in addition apply to elements of graded rings only. So this is another case of confusion arising from the history of AA.

[JohnAAbbott]

Ah! So in practice I cannot use is_homogeneous on the input generators, right? That excludes the "short-cut".
Indeed it is confusing that "homogenization" has such a context-dependent meaning. I must review my code.
I also spoke to Hans: Singular does not yet handle specially the case of saturating by variables which do not appear in the generators.

[fieker]

just use length(f) this avoids the extremely expensive collect(coefficients
Many iterators also support length, so even length(coefficients(f)) would be better

[JohnAAbbott]

Thanks. I've updated my local copy.

[wdecker]

@JohnAAbbott The problems I have with this PR are not yet resolved (see comments above). I suggest to make this a draft until we have met in person again.

[JohnAAbbott]

@wdecker
I have removed the code which "wanted to check" whether the given generators are already homogeneous because it did not work as hoped: is_homogeneous defaults to standard grading. Anyway, it is probably best to delegate to Singular the task of spotting simplifications when computing the saturation.
The "superfluous" GB computations in gens_for_homog are mathematically unnecessary, but in my tests the complete homogenization computation (incl. the cost of gens_for_homog) was often significantly faster than when using just the supplied generators; there were some cases where the complete homogenization computation became a bit slower (but I have not seen any cases where it became significantly slower). Of course, I can replace

    Hgens = homogenization(gens_for_homog(I), W, var, pos)

with the simpler line

    Hgens = homogenization(gens(I), W, var, pos)

but as I have just said that will typically make homogenization slower (sometimes significantly slower).

[JohnAAbbott]

@wdecker
Hans suggested a compromise: inside gens_for_homog check whether a GB is already known, and if so, use any that are there. This should guarantee that gens_for_homog is quick, but produces a benefit only if some GB has already been cached. My guess is that a DegRevLex GB computation for the original ideal is likely considerably cheaper than the GB computation inside the computation of the saturation.

[wdecker]

Yes, the idea here is to include this as one method to be compared with the other methods in a Series of involved examples. To run these tests we wait until Hans has fixed saturation in Singular. Von meinem iPhone gesendet

…

Am 17.05.2023 um 15:25 schrieb JohnAAbbott ***@***.***>:  @wdecker Hans suggested a compromise: inside gens_for_homog check whether a GB is already known, and if so, use any that are there. This should guarantee that gens_for_homog is quick, but produces a benefit only if some GB has already been cached. My guess is that a DegRevLex GB computation for the original ideal is likely considerably cheaper than the GB computation inside the computation of the saturation. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[fingolfin]

So Hans fixed this in Singular and will make a new Singular_jll release soon. And then hopefully we can also soon have a new Singular.jl release (this is partially waiting on me).

[JohnAAbbott]

Saturation by a principal ideal generated by a product is equivalent to a cascade of saturations by the factors: see Kreuzer+Robbiano Book 1, Tutorial 37 part (g).
Saturation by a single indeterminate: see Kreuzer+Robbiano book 2 Corollary 4.4.9.

[JohnAAbbott]

Unless I am mistaken there should now be the completely new implementation accessible via the new function homogenization2 which is intended to be a drop-in replacement for homogenization (just for ideals).
By using a temporary different name once can test and compare the two versions. I know of no case where the old code is as fast as the new code (i.e. homogenization2 should always be faster, usually much faster).
The newly added code deliberately does not follow OSCAR coding standards -- I plan to "clean" it when the PR is no longer a draft.