#18514: Upgrade of group cohomology spkg
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: needs_work
Priority: major | Milestone: sage-6.8
Component: packages: | Resolution:
optional | Merged in:
Keywords: group cohomology | Reviewers:
Authors: Simon King | Work issues: Create a new-style
Report Upstream: None of the above | package with least effort
- read trac for reasoning. | Commit:
Branch: | Stopgaps:
Dependencies: #18494 |
-------------------------------------+-------------------------------------
Changes (by SimonKing):
* cc: david.green@… (added)
Comment:
I am now confident that it is feasible to make the group cohomology
software work with the new optional meataxe package from #12103. I managed
to rewrite the stand-alone programs of David Green needed in the package,
and the rest "should work" (TM) by search-and-replace operations (really,
ALL names in meataxe have changed).
But I have questions concerning the new code structure.
The old spkg (p_group_cohomology-2.1.5) consists of
- Original sources of meataxe-2.2.4, together with my "fork" of meataxe,
- C-programs written by David Green, in src/present/,
- GAP-functions written by David Green, in src/pGroupCohomology,
- Singular-functions written by me, in src/pGroupCohomology,
- Cython modules written by me, in src/pGroupCohomology,
- documentation, including a doc builder taken (and modified) from old
Sage versions,
- a data base of cohomology rings for the groups of order 64.
For the new package, I suggest:
- `meataxe-2.4.24` is used, as provided by the package from #12103.
- The C-programs of David Green, converted to work with the new !MeatAxe,
will be a new optional package called `modular_resolutions-1.0` (or do you
prefer `modres-1.0`?) depending on `meataxe`, adding me as a second
author, as the conversion to the new !MeatAxe was very nontrivial, and I
also added error handling.
- The database will also be part of `modular_resolutions`.
- The Cython modules will become optional extensions in the !SageMath
library, say, `sage.groups.modular_cohomology`, depending on
`modular_resolutions` and on `database_gap`. In that way, the
documentation would be taken care of.
- Where shall the Singular and GAP functions go? Is there a natural place?
There is `SAGE_LOCAL/share/singular/` for the Singular functions. But for
GAP?
Remark: `database_gap` is needed because of the !SmallGroups library.
Technically, the upcoming `modular_resolutions` (or `modres`) package
would not depend on it; but it is needed in the cohomology computations,
thus, perhaps it makes still sense to add `database_gap` as a dependency
of `modular_resolutions`?
--
Ticket URL: <http://trac.sagemath.org/ticket/18514#comment:58>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
