Fixes for the degree function

[HechtiDerLachs]

This addresses #2999 .

The PR contains the improved changes from #3238, rebased on #3237.

It can be rebased again, once #3237 is merged.

For the last testset in test/Modules/ModulesGraded.jl I now get the following timings:

julia> @time Oscar._alt_simplify(M); # M is Omega without grading.
  0.490810 seconds (2.12 M allocations: 113.333 MiB)

julia> @time Oscar._alt_simplify(Omega);
  0.667269 seconds (3.38 M allocations: 151.342 MiB)

so the gradings still seem to make things slower. But computations now at least finish in comparable time.

[thofma]

What is the plan for the :task keyword, which is still there for the truncate function?

[thofma]

Just adding this here, so that we don't accidentally merge this without resolving the :task question.

[HechtiDerLachs]

It turns out, this PR has another problem (apart from the tests failing again):

Edit: This seems to be about the flattenings of modules over rather exotic rings. These can not be expected
to work in general and so I think it's safe to leave this cleanup to another PR. That this did not blow up on master is only luck. So we should have the problems below in mind, but not have this PR blocked by that.

  kk = GF(40009);
  B, (t,) = polynomial_ring(kk, [:t]);
  IP5 = projective_space(B, [:u, :v, :w, :x, :y, :z]);
  S = homogeneous_coordinate_ring(IP5);
  (u, v, w, x, y, z) = gens(S);
  f = x*y - t^2*v^2 - w^2;
  g = z*w - t*u*v;
  I = ideal(S, [f, g]);
  X, inc_X = sub(IP5, I);
  Om1X = Oscar.relative_cotangent_module(X);
  SX = homogeneous_coordinate_ring(X);
  F1X = graded_free_module(SX,[0]);
  TX,_ = hom(Om1X,F1X);
  TXamb,_ = pushforward(inc_X,TX);
  W1X,_ = hom(TX,F1X)
  M, a, b = Oscar._alt_simplify(W1X)
  is_isomorphism(a) # true
  is_isomorphism(b) #false
  compose(a, b) == identity_map(domain(a)) # true
  compose(b, a) == identity_map(domain(b)) # true

If one proceeds by

K, inc = kernel(b)
v = inc(K[1])
is_zero(v) #false 
w = b(v)
is_zero(w) # true
is_zero(a(w)) # false 

The only thing I found so far is that the SubModuleOfFreeModule layer of the modules is still not sufficiently generic so that in one way or the other Groebner basis reduction via singular is called on modules over towers of polynomial rings. But this will be nasty to debug, I guess. Interestingly, the above code does not fail on the latest master.

[jankoboehm]

Just adding this here, so that we don't accidentally merge this without resolving the :task question.

The idea is to do that issue in a separate PR. This one should limit to the degree check question.

[jankoboehm]

Interestingly, the above code does not fail on the latest master.
Before merging, we should find out why it works on master, and now not any more with this modification. Otherwise one surely will be able to produce other examples which fail. Perhaps I have an idea.

Reduction is part of the layer.

fine

[HechtiDerLachs]

Before merging, we should find out why it works on master, and now not any more with this modification. Otherwise one surely will be able to produce other examples which fail. Perhaps I have an idea.

@jankoboehm : This is not a citation, but what you said, correct?

In any case, I have a fix now and I understand why it worked on master but not here. This can be pushed to #3348 . But it will be several hundred lines of code unrelated with this PR's original intention. So I think, it should also go separately.

[HechtiDerLachs]

I had no choice but to also include the changes of the flattenings of modules. Otherwise the tests wouldn't run again. Also, they were running for the wrong reasons before, so I think, it's better this way.

[HechtiDerLachs]

Good to be merged. Only non-required tests have not run yet and I don't see how to trigger them.

[lgoettgens]

@benlorenz @aaruni96 some heads-up for the backport: This PR introduced some code that is not compatible with AbstractAlgebra v0.40.0. For the master branch, this was replaced by the new interface in #3374. For the backporting of these two commits, you probably either need to keep the order as on the master branch (first cherry-pick this and #3374 afterwards), or apply cb62fb3 (#3374) and then 404ac73 (#3374) after cherry-picking this PR to make it work again.

[benlorenz]

Thanks for the info, I did backport #3374 earlier today with some small conflicts that I needed to resolve. (due to not having this PR yet)
But I will now try to redo this in the correct order just to be safe.