-
Notifications
You must be signed in to change notification settings - Fork 126
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
Adds free resolutions over quotient rings by using Singular.sres
#4134
Conversation
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)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Thanks for doing this! Actually, I have a big computation going on right now which could potentially benefit from this. |
if T <: MPolyQuoRingElem | ||
!iszero(length) || error("Specify a length up to which a free resolution should be computed") | ||
end | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
I think you can leave it as it is now.
… Am 25.09.2024 um 12:58 schrieb Rafael Mohr ***@***.***>:
@RafaelDavidMohr commented on this pull request.
In src/Modules/UngradedModules/FreeResolutions.jl <#4134 (comment)>:
> + if T <: MPolyQuoRingElem
+ !iszero(length) || error("Specify a length up to which a free resolution should be computed")
+ end
+
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.
—
Reply to this email directly, view it on GitHub <#4134 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXET5HLNPO6YQTY3ZSULZYKJNTAVCNFSM6AAAAABOWHW3DKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGMRXHEYTCOBVGE>.
You are receiving this because you commented.
|
# 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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
My changes seem to work for now. It remains to clean up some of the tests. |
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 |
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 @jankoboehm : Any opinion on this matter? |
Some timings for On current master: On the head of this PR: On 3d35d0a, i.e. not using I had to disable two lines in the tests for the modules over |
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
|
This is still pending. Other than that, this seems good to go, I think. |
Singular.jl v0.23.8 is now available |
I added the compat bump myself. No objections from me anymore |
Adds free resolutions over quotient rings by using
Singular.sres
(withfres
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