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 Groebner bases of noncommutative polynomials via GBNP #31446
Comments
comment:1
Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date. |
comment:3
What is the status of this ticket? Looking at the Gitlab repo, it seems like that code might be ready for review. Should that be submitted for review on this ticket? |
comment:4
Thanks for looking into it, as I did not worked on it for a long time. I just updated the instructions there for GBNP v1.0.4. From a quick skim, it is almost ready:
|
Branch: u/mathzeta2/31446_gbnp_wrapper |
Commit: |
comment:5
Here is an updated version from that repo, which I think is ready for review. |
Author: Guy Blachar, Tomer Bauer |
comment:7
Stalled in |
comment:8
It seems like there is a merge issue going on - I'm having trouble viewing the diff, and I'm getting the warning Warning: Merge failed for 9a3773bcd7c0c544d22f3dfd3b74f422543bc2d3 |
comment:9
It needs a simple rebase to the latest develop. |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:13
See #34138 for a native Sage version for the exterior algebra. |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:15
It looks like there has been a bad merge as there are a number of changes that do not appear related to this ticket. It might be best to cherry-pick the relevant commits into a new branch based off |
comment:16
O git! Why thou'rt mercurial and not Mercurial? Let's see if the patchbots will be happy with the new branch. Last 10 new commits:
|
Changed branch from u/mathzeta2/31446_gbnp_wrapper2 to u/mathzeta2/31446_gbnp_wrapper3 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:20
The docs seem to build fine for me, so does the failing of the "build documentation" badge is unrelated? |
Changed keywords from none to groebner basis |
comment:21
Yes; you can see from the patchbot that the doc built okay. However, the manual building and installing of the package is not allowed I believe. It does seem to be included in the |
comment:22
Replying to @tscrim:
Thanks.
It seems that gap_packages includes GBNP v1.0.3 released 2016-03-08, per their changelog, and the "manual install" here suggests v1.0.5 released 2022-03-09. There are no doctest errors using v1.0.3, but it might be a good idea to update gap_packages in a new ticket. If I have to guess why the manual install instructions are there, then it has to do with the initial development of this wrapper, which was done using a binary Sage or on Windows (or both). So it was impossible to use gap_packages which requires a compiler, IIRC. The manual install with extracting one tarball is possible in such case, that relied on this obsolete Wiki page. This is still a convenient way to install GAP packages that do not require any compiler. Do we have anywhere in the Sage docs an explanation how to install optional GAP packages (not the one for gap_packages), or links to the GAP docs? It is a question that come up in ask.sagemath.org from time to time. For this ticket, I suppose using |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:24
Replying to @mathzeta:
+1 This usually happens with new GAP versions, but it doesn't have to happen in sync.
The first thing we (or at least I) usually tell people is to install I am a very strong -1 on including the "manual" instructions here in anything associated with this ticket. I do not want anything to hint at anything that looks "very official" that hasn't been rigorously tested by the build team. These instructions can go on some Sage wiki page or something like that, but as a general instruction (of course, with an appropriate warning). |
comment:25
I should also say I am -1 on having any installation instructions. There are other places in Sage already for this. IMO, it is sufficient just to tell the user they need to install it. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:27
OK, I have removed the manual install instructions, but kept the paragraph telling that gap_packages is needed. Because gap_packages contains only a small fraction of the available GAP packages, and libgap makes it easier to interface many packages, I think there should be an official place that tells how one can try to install and use new GAP packages. Of course it should tell the state of support (i.e., none) for such endeavors. Replying to @tscrim:
Grepping for |
comment:28
Fair enough. I do agree that it is useful to tell the user directly what to do to get the file to work for "most" users. Although having a more standard page with more robust instructions would be better. That doesn't need to be done here though. Next I am going to get into the main code comments: I think this should fit together better with the free algebra implementations that are currently in Sage. I see two obvious ways to do this:
I would do option (2) as it means better exposure and it means we don't have yet-another-implementation. Plus, you are already almost there anyways with subclassing. It's a bit more work, but it will make for a much nicer result IMO. You won't have to mark so many tests as optional either. I disagree with the
Hence, I think your GB method should return a tuple. Your interface file is not (just) an interface, it contains an implementation within Sage using the interface. Although if you go with option (2) above, the only things that would really survive would be the The function names Not necessary, but it would be nice to have something that checks containment of ideals by reducing the generators of one to the other. Minor point, but I would like this reverted: - :maxdepth: 2
+ :maxdepth: 1 as I like the current version. |
comment:29
Replying to @tscrim:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:31
Replying to @mkoeppe:
It is already used. Replying to @tscrim:
Reverted. I agree that it is better to have an API consistency for methods called |
comment:33
Replying to @mathzeta:
I don't think there is that much to change. Most of it is just moving the code to I = super(FreeAlgebra_generic, self).ideal(*gens, **kwds)
return GapIdeal(self, I.gens())
I don't really understand this comment. Of course
It doesn't do that; the onus is on the user to hold onto a reference to output and then build on that. Returning a tuple just means the user has to do one more step of Some other comments:
|
The GAP package GBNP, according to its documentation, "provides algorithms for computing Gröbner bases of noncommutative polynomials with coefficients from a field implemented in GAP and with respect to the “total degree first then lexicographical” ordering".
GBNP can be wrapped for Sage by including and adapting this project. The current implementation in Sage for noncommutative Gröbner bases wraps
letterplace
(from Singular) is restricted to weighted homogeneous elements, and it seem to be somewhat less efficient than GBNP. In any case, it is a good idea to have more than one engine for such tasks.Note that GAP supports function fields (including with more than one variable), but the
libgap
interface does not.CC: @mathzeta @tscrim @trevorkarn
Component: algebra
Keywords: groebner basis
Author: Guy Blachar, Tomer Bauer
Branch/Commit: u/mathzeta2/31446_gbnp_wrapper3 @
81f11dd
Issue created by migration from https://trac.sagemath.org/ticket/31446
The text was updated successfully, but these errors were encountered: