-
Notifications
You must be signed in to change notification settings - Fork 133
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
Add mres
and nres
Singular Calls for Free resolutions
#2500
Add mres
and nres
Singular Calls for Free resolutions
#2500
Conversation
src/Modules/UngradedModules.jl
Outdated
elseif algorithm == :sres | ||
res = Singular.fres(singular_kernel_entry, length) |
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 seems to be an old bug: you want sres but ask for fres!
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.
Fixed in d6abd9f
Once this is merged, I will extend the docu and explain what the difference between the different methods is. |
Project.toml
Outdated
@@ -35,7 +35,7 @@ Polymake = "0.10.0" | |||
Preferences = "1" | |||
RandomExtensions = "0.4.3" | |||
RecipesBase = "1.2.1" | |||
Singular = "0.18.2" | |||
Singular = "0.18.6" |
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.
This looks right (I didn't check the versions, but I trust you did).
Thanks!
This PR has no test for the new code, so naturally it will pass, even if actually calling the code was broken. So either a test should be added in this PR (could be a doctest or could be a regular test); or else I'd hope that @wdecker would add one when he extends the documentation for this? |
A word on the now failing tests: I could be wrong, but to me it seems that the issue is the following: Oscar starts computing a free resolution by computing the input module as a cokernel and then passes that cokernel to Singular to let it compute a free resolution for that. My question is: Should we try to handle this bug in this PR or a seperate one? |
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 are several problems here: To begin with, fres and sres require as input a gröbner basis. This is missing so far. There is another problem on which @jankoboehm is already working.
For the time being, I suggest to replace sres by fres in the test. If this makes the test pass, let us merge the PR. More tests and docu will be added as soon as all problems are fixed. @RafaelDavidMohr please open an issue which reminds us to do the above.
Unfortunately the same problem seems to be happening with So |
The situation for |
Ok! In a sence, Let me know if I can help with fixing this. |
We think there are some changes in the latest Singular.jl that may help, but couldn't find them just now; but @hannes14 will check |
d6abd9f
to
b749b80
Compare
I added Let me know if I missed something. |
Looks like a valid solution to me. |
If the geometry would like to merge this, fine by me, but someone needs to explicitly approve it |
We are still discussing it. Will be merged tomorrow.
… Am 11.09.2023 um 11:49 schrieb Max Horn ***@***.***>:
If the geometry would like to merge this, fine by me, but someone needs to explicitly approve it
—
Reply to this email directly, view it on GitHub <#2500 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASSXEXBII5IO7TWHQP2DP3XZ3NBXANCNFSM6AAAAAAZYNCDTQ>.
You are receiving this because you were mentioned.
|
Codecov Report
@@ Coverage Diff @@
## master #2500 +/- ##
==========================================
+ Coverage 73.63% 74.36% +0.72%
==========================================
Files 455 455
Lines 64411 68587 +4176
==========================================
+ Hits 47427 51002 +3575
- Misses 16984 17585 +601 |
Here is a bit more explanation on why things should work now. Originally I diagnosed the problem wrong. Previously, for a given module We start by computing a presentation of
then we let
and now the two chain complexes were patched together as follows:
This is now always a correct free resolution (because we basically just take the one Singular gives us, |
@RafaelDavidMohr Thx for doing this. I have a small remark: The methods
and also the "dummy" method
should be adjusted to the syntax we have now for |
As I understand it, we switch the presentation matrix originally computed by OSCAR to the (in case of mres, not fres) possibly modified one returned by Singular. Are we sure that this is the same module and not just an isomorphic one (then we have to keep track of the isomorphism), what if we resolve a submodule. We cannot change the generators, since the representation of the elements is referencing them. It also looks to me as if the grading is removed? Best have a quick talk in person once possible. |
Yes, in person (Saarbrücken for instance) is probably easier. I will however have a look at the grading issue and at the things @wdecker mentioned. Edit: Actually, @jankoboehm, I am not sure what you mean by "the grading is removed". I tried a random example and I'm getting a graded free resolution. Could you specify? |
16b8250
to
87d2059
Compare
See 347349c. I adjusted the docu accordingly, the docu for |
This is good for now. However, for the |
Pull request was closed
* add `mres` with fix * fixes no relation edge case * adds `nres`, updated doc, adds tests * fix typo `mres` -> `nres` * compatibility changes to other `free_resolution` methods --------- Co-authored-by: Rafael Mohr <[email protected]> Co-authored-by: ederc <[email protected]>
Adds corresponding keywords to
free_resolution
and adjusts docu accordingly.