#15666: p_group_cohomology upgrade
-------------------------------------------------+-------------------------
Reporter: SimonKing | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.1
Component: packages: optional | Resolution:
Keywords: group cohomology | Merged in:
Authors: Simon King | Reviewers:
Report Upstream: None of the above - read trac | Work issues:
for reasoning. | Commit:
Branch: | Stopgaps:
Dependencies: |
-------------------------------------------------+-------------------------
Changes (by {'newvalue': u'Simon King', 'oldvalue': ''}):
* author: => Simon King
* upstream: N/A => None of the above - read trac for reasoning.
Old description:
> The optional package `p_group_cohomology-2.1.4` does not install on
> sage-6.1.b4. First problem: It tries to include `interrupt.pxi`, but
> apparently these things have moved.
>
> Also, it is using the old spkg layout. With a little help from an expert
> of the new conventions after switching to git, this could be fixed as
> well.
New description:
The optional package `p_group_cohomology-2.1.4` does not install on
sage-6.1.b4. First problem: It tries to include `interrupt.pxi`, but
apparently these things have moved.
Also, it is using the old spkg layout. With a little help from an expert
of the new conventions after switching to git, this could be fixed as
well.
A package version that installs both on sage-5.12, sage-5.13 and
sage-6.1.beta4 is available at
[http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.4.p1.spkg]
--
Comment:
As a first step, I was fixing the most urgent problem: The package did not
build on the most recent Sage versions. Also, the expected output of some
doctests changed (old and new result are mathematically equivalent).
A colleague of mine had problems to load cohomology rings that he computed
and saved with previous versions of the spkg. The underlying problem was
that the address of the group in the small groups library is supposed to
be a pair of integers, but the package did not complain if is was given by
two integers defined in the GAP pexpect interface. If you then saved the
cohomology ring, the pexpect element would be part of the pickle---but can
not be unpickled, because the element is defined in terms of a GAP session
that is not available when one reloads the data.
So, I needed to do two or three more changes:
- If a saved cohomology ring is loaded, then "custom" attributes depending
on pexpect elements are simply ignored. If the loaded ring's attribute
`_key` (which is important for the cache of cohomology rings) depends on
pexpect (which is the case in the scenario sketched above), then it is
attempted to reconstruct it from other available data. This was enough to
rescue the data of my colleague, but admittedly it involves some trickery.
- The small groups library address is now always transformed into a pair
of (Sage) integers, even if it was originally provided by GAP-via-pexpect.
So I think there already is something that can be reviewed.
What is not done ''yet'' (and therefore it is 2.1.4.p1 and not 2.1.5):
- Updated SPKG.txt
- Transition to git. Here I'd really need some guidance how to "track its
contents in my own repository": How to set up a repository at university
of Washington (I think there is the "official" home of the package: public
documentation, download site and database), so that people can pull from
it? How to set it up such that I can push to it from Jena?
What will not be done: Moving my fork to more recent `MeatAxe`. Reasons:
- My current project is to replace the algorithm for computing minimal
projective resolutions by something faster (using a non-commutative F5
algorithm). This, I plan to do in the Sage library, relying on the
matrices available there (e.g., Linbox). Hence, `MeatAxe` is not involved
in my current project.
- Rebasing my patches on top of the new version would involve a lot of
work.
- David Green's code for computing minimal projective resolutions uses
`MeatAxe` for matrix arithmetic, and it was written using the old
`MeatAxe` version. Hence, I would need to change a substantial amount of
C-code that was not authored by me. Not a nice job.
So, I would only consider to switch to the latest `MeatAxe` if there would
be a good reason. However, the matrix arithmetic in the latest `MeatAxe`
version is not superior to the old version (`MeatAxe` is much more than
matrix arithmetic, by the way, but I am using it, since `MeatAxe`'s matrix
arithmetic non-prime fields of odd order <255 is substantially faster than
the matrix implementation that is currently used in Sage).
--
Ticket URL: <http://trac.sagemath.org/ticket/15666#comment:4>
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/groups/opt_out.
