Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds free resolutions over quotient rings by using Singular.sres #4134

Merged
merged 17 commits into from
Sep 30, 2024

Conversation

RafaelDavidMohr
Copy link
Contributor

Adds free resolutions over quotient rings by using Singular.sres (with fres currently not working for quotient rings in Singular).

Some Macaulay2 people told me that their users were confused by the fact that they could compute free resolutions over quotient rings without specifying a length, so I force the user to set a length for the free resolution when computing over quotient rings.

CC: @ederc

@wdecker
Copy link
Collaborator

wdecker commented Sep 24, 2024

Some Macaulay2 people told me that their users were confused by the fact that they could compute free resolutions over quotient rings without specifying a length, so I force the user to set a length for the free resolution when computing over quotient rings.

That is o.k. Just for the record: entering zero would also be o.k. since then Singular stops after number of variables +1 steps.

push!(values, MPolyBuildCtx(base_ring(F)))
push!(values, zero(Rx))
Copy link
Collaborator

@HechtiDerLachs HechtiDerLachs Sep 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were these deliberately reverted because we do not have an MPolyBuildCtx over quotient rings? In that case, I suggest to refactor this part of the code via type dispatch. We talked about it during last week's workshop how to speed this up, eventually. Also, I think @Lax202 's work in progress on non-commutative groebner bases might touch this part again. So we should eventually decide how to split this up here.

Edit: This does not need to hold this PR back for now. But before anyone merges, we should open an issue to remind us to clean this bit up.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up: I tried do speed up some of our computations yesterday and made a patch for this part here in #4147 . Would it be desirable to push it directly to this PR? If so, please let me know.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a look and fixing this! Merging this in unison would be good for me.

@HechtiDerLachs
Copy link
Collaborator

Thanks for doing this! Actually, I have a big computation going on right now which could potentially benefit from this.

Comment on lines +409 to +412
if T <: MPolyQuoRingElem
!iszero(length) || error("Specify a length up to which a free resolution should be computed")
end

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Singular's sres sets a default of nvars(basering) modules to be computed, if no length is specified. It might be better for compatibility to document this fallback instead of throwing an error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking a look. Having this default nvars(basering) length is the same they had in Macaulay2, they told me that they removed this at some point for clarity for the users.

But if you prefer to have this default, I will of course make the appropriate changes.

@wdecker
Copy link
Collaborator

wdecker commented Sep 25, 2024 via email

Comment on lines 270 to 274
# if isone(length(s)) # TODO: length doesn't work!
# (i, e, c) = first(s)
# push_term!(ctx, R(c), e)
# return FreeModElem(sparse_row(Qx, [(i, finish(ctx))]))
# end
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does anyone know what is the correct way to check whether a Singular.svector has only one term? length throws an error, even though it should be part of the iterator interface.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

length(p::svector) = Int(libSingular.pLength(p.ptr))

should do it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: @hannes14 's PR on Singular.jl just got merged. Do we have to wait for a release there? Or can we remove the method here already?

ping @lgoettgens

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You will need to wait for a new release of Singular.jl, and then adapt the compat entry in Oscar's Project.toml to this new version number

@@ -283,18 +283,21 @@ function (F::FreeMod{<:MPolyRingElem})(s::Singular.svector)
return FreeModElem(sparse_row(Rx, [(i, finish(ctx)) for (i, ctx) in cache]), F)
end

# TODO: move this eventually
length(s::Singular.svector) = Int(Singular.libSingular.pLength(s.ptr))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move this to Singular.jl before merging this PR. Sorting this out afterwards is more of a hassle than doing it right the first time

@HechtiDerLachs
Copy link
Collaborator

My changes seem to work for now. It remains to clean up some of the tests.

RafaelDavidMohr and others added 2 commits September 26, 2024 10:41
Co-authored-by: Matthias Zach <85350711+HechtiDerLachs@users.noreply.github.com>
Co-authored-by: Matthias Zach <85350711+HechtiDerLachs@users.noreply.github.com>
@RafaelDavidMohr
Copy link
Contributor Author

Thanks @HechtiDerLachs for fixing the last tests. Is there any interest in keeping the option to compute free resolutions over quotients by iterative kernel computations in addition to using sres?

@RafaelDavidMohr RafaelDavidMohr marked this pull request as ready for review September 26, 2024 08:43
@HechtiDerLachs
Copy link
Collaborator

Is there any interest in keeping the option to compute free resolutions over quotients by iterative kernel computations in addition to using sres?

I think it's always good to have different options for the user and a reasonable default. Eventually it would be nice to have the computation lazy, but using sres. But this is probably to be decided elsewhere and not on this PR. If the tests pass, then from my side I'm ok with the iterative kernel computation being disabled for the moment. We still have the code to put it back in and I am probably using the hypercomplexes, anyway.

@jankoboehm : Any opinion on this matter?

@HechtiDerLachs
Copy link
Collaborator

HechtiDerLachs commented Sep 26, 2024

Some timings for @time Oscar.test_module("test/Modules/", new=false)

On current master:
37.206091 seconds (185.12 M allocations: 9.750 GiB, 24.01% gc time, 20.60% compilation time)
37.702440 seconds (184.58 M allocations: 9.738 GiB, 22.81% gc time, 21.73% compilation time)

On the head of this PR:
37.933323 seconds (189.73 M allocations: 9.926 GiB, 23.15% gc time, 23.39% compilation time)
38.951809 seconds (190.67 M allocations: 9.939 GiB, 22.77% gc time, 19.89% compilation time)

On 3d35d0a, i.e. not using MPolyBuildCtx for the conversion
42.981092 seconds (215.30 M allocations: 10.906 GiB, 21.85% gc time, 17.19% compilation time)
42.981092 seconds (215.30 M allocations: 10.906 GiB, 21.85% gc time, 17.19% compilation time)
41.036220 seconds (214.36 M allocations: 10.897 GiB, 22.19% gc time, 18.05% compilation time)
43.827199 seconds (215.27 M allocations: 10.907 GiB, 21.35% gc time, 20.50% compilation time)

I had to disable two lines in the tests for the modules over MPolyQuoRing for the latter.

Copy link

codecov bot commented Sep 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.68%. Comparing base (55ea957) to head (64f6b44).
Report is 17 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4134      +/-   ##
==========================================
+ Coverage   84.65%   84.68%   +0.02%     
==========================================
  Files         626      628       +2     
  Lines       84313    84471     +158     
==========================================
+ Hits        71377    71535     +158     
  Misses      12936    12936              
Files with missing lines Coverage Δ
src/Modules/UngradedModules/FreeResolutions.jl 81.30% <100.00%> (-8.03%) ⬇️
src/Modules/UngradedModules/ModuleGens.jl 74.88% <100.00%> (+2.06%) ⬆️
src/Modules/UngradedModules/Presentation.jl 94.02% <100.00%> (+0.04%) ⬆️

... and 30 files with indirect coverage changes

@HechtiDerLachs
Copy link
Collaborator

You will need to wait for a new release of Singular.jl, and then adapt the compat entry in Oscar's Project.toml to this new version number

This is still pending. Other than that, this seems good to go, I think.

@lgoettgens
Copy link
Member

You will need to wait for a new release of Singular.jl, and then adapt the compat entry in Oscar's Project.toml to this new version number

This is still pending. Other than that, this seems good to go, I think.

Singular.jl v0.23.8 is now available

@lgoettgens
Copy link
Member

I added the compat bump myself. No objections from me anymore

@afkafkafk13 afkafkafk13 merged commit 2fe164e into oscar-system:master Sep 30, 2024
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants