#9894: Group cohomology spkg, version 2.1.2
-----------------------------------+----------------------------------------
Reporter: SimonKing | Owner: SimonKing
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: optional packages | Keywords: modular group cohomology
solaris t2
Work_issues: | Upstream: N/A
Reviewer: Karl-Dieter Crisman | Author: Simon King
Merged: | Dependencies:
-----------------------------------+----------------------------------------
Changes (by SimonKing):
* status: needs_work => needs_review
* work_issues: make it work with the latest Sage version; perhaps 2.1.2
=>
Old description:
> Version 2.1.1 of the modular group cohomology package is now available.
> There is extensive
> [http://sage.math.washington.edu/home/SimonKing/Cohomology/index.html
> documentation]. The package needs the Small Groups library (available in
> the gap-packages spkg) and can be installed with {{{sage -i
> http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.1.spkg}}}
>
> '''__New Features__'''
>
> '''1. Improved code quality'''
>
> - IIRC, one of the referee's complaint on earlier versions of the
> package was that the !__init!__.py file actually contains code, rather
> than just importing things. So, I made a new module "factory.py". Now,
> the !__init!__.py only contains documentation and import statements.
>
> - Moreover, I split the !__call!__ method of the cohomology ring
> constructor into smaller units.
>
> - Virtually all computations with this package require creating certain
> data files on disk. However, the data that are shipped by the package are
> installed in SAGE_DATA. So, if a user has no write access in that folder,
> he can read from the database, but can not add further computations to
> it. In previous versions, it meant that the user had to create his/her
> own database ''from scratch''. This is solved in version 2.1.1: Still,
> the user will create his/her own database, but this database can make
> full use of the stuff that already is in SAGE_DATA.
>
> - Typically one has methods whose result can be cached and needs only be
> re-computed if the ring approximation changes; this is now being taken
> care of by decorators.
>
> - I tried to reduce compiler warnings.
>
> - Using the package, several bugs in Singular and GAP have been
> uncovered. The new Singular version 3-1-1 fixes some bugs, so that in
> some cases more efficient methods can be used. The package tests the
> available Singular version; it both supports the new features and is able
> to work around the old Singular bugs.
>
> - We finally achieved '''100% doctest coverage!! '''
>
> - By oversight, the old test script failed to execute the tests of
> special methods (such as {{{__add__}}} or {{{__mul__}}}. The new script
> now captures all tests, and complains if a class, method or function does
> not appear to be tested. Also, the test script does parallel tests.
>
> - The parallel testscript uncovered a problem with temporary files
> associated with Sage's pexpect interfaces -- see #10004. The testscript
> tests if the problem reported at #10004 is fixed, and will only do
> parallel testing if it is fixed.
>
> '''2. Extended computational capability'''
>
> - The completeness criteria are further improved. We use three criteria,
> namely the modified Benson criterion (found by David Green and myself),
> the Symonds criterion and the Hilbert-Poincaré criterion (suggested by
> Peter Symonds and worked out by myself). Due to new methods of
> constructing parameters, the Symonds criterion is now often the best
> choice - but not always, so that it is good to have three methods to
> choose from.
>
> - New functionality includes the computation of preimages of induced
> homomorphisms, essential ideals and depth essential ideals. Using the
> package, a new example of a group was found for which the square of the
> essential ideal does not vanish (this is only the second known example!).
> So far, a conjecture of Jon Carlson on depth essential ideals can be
> confirmed.
>
> '''3. Portability '''
>
> The package fully works on t2! This is a very non-trivial achievement. It
> involved:
> * Changing the names of several functions from {{{C-MeatAxe}}}, since
> the Sun linker seems to confuse them with functions from pari. This is a
> problem similar to the one found at #1396.
> * t2 is a big-endian machine. GAP's random generator depends on the
> endianness (which is a bug). Certain internal data used by the cohomology
> computations are obtained by randomised algorithms of GAP. The ring
> presentation found for the cohomology ring depends on these internal
> data. So, in order to get machine independent computationally well
> defined results, special care was needed, as discussed on
> [http://groups.google.com/group/sage-
> devel/browse_thread/thread/623f7291ab7e782e sage-devel]
>
> '''__Testing__'''
>
> As usual, if the environment variable {{{SAGE_CHECK}}} is exported and
> has the value {{{yes}}}, the test script is automatically executed and
> the result saved in {{{SAGE_ROOT/install.log}}}.
>
> The script tests parallely. By default, the number of threads is one
> third of the number of available CPUs. This can be overruled by exporting
> the environment variable {{{SAGE_NUMBER_THREADS}}}.
>
> However, problems with parallel testing in Version 2.1 revealed a problem
> with Sage's {{{pexpect}}} interfaces: ''All'' interfaces (e.g., GAP and
> Singular) and all parallel branches use a single temporary file for
> passing long commands. A solution is at #10004. The test script of the
> cohomology spkg will only do parallel testing if gap and singular use
> different temporary files.
>
> I successfully installed and tested the package on the following machines
> and the following versions of Sage and Singular:
> * t2.math, Sage 4.5.1, Singular 3-1-1
> * bsd.math, Sage 4.5.2, Singular 3-1-0, both in 64 and 32 bit mode
> * sage.math, Sage 4.5.1, Singular 3-1-0
> * x86_64 GNU/Linux, Intel Core2 CPU 6700 @ 2.66GHz, Sage 4.5.2, Singular
> 3-1-1 -- ''without'' write permission in SAGE_DATA.
>
> On another GNU Linux machine with AMD processors, it builds and seems to
> work even with Sage 4.2.1, but apparently the interface to the @parallel
> decorator has changed, so that I was not able to run the test script.
New description:
Version 2.1.2 of the modular group cohomology package is now available.
There is extensive
[http://sage.math.washington.edu/home/SimonKing/Cohomology/index.html
documentation]. The package needs the Small Groups library (available in
the gap-packages spkg) and can be installed with {{{sage -i
http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.2.spkg}}}
Most importantly: The version 2.0, that is the current "official" version
of the optional package, would not work with the current version of Sage.
So, there has to be an upgrade of the spkg.
Moreover, it has new features.
'''__New Features__'''
'''1. Improved code quality'''
- IIRC, one of the referee's complaint on earlier versions of the package
was that the !__init!__.py file actually contains code, rather than just
importing things. So, I made a new module "factory.py". Now, the
!__init!__.py only contains documentation and import statements.
- Moreover, I split the !__call!__ method of the cohomology ring
constructor into smaller units.
- Virtually all computations with this package require creating certain
data files on disk. However, the data that are shipped by the package are
installed in SAGE_DATA. So, if a user has no write access in that folder,
he can read from the database, but can not add further computations to it.
In previous versions, it meant that the user had to create his/her own
database ''from scratch''. This is solved in version 2.1.1: Still, the
user will create his/her own database, but this database can make full use
of the stuff that already is in SAGE_DATA.
- Typically one has methods whose result can be cached and needs only be
re-computed if the ring approximation changes; this is now being taken
care of by decorators.
- I tried to reduce compiler warnings.
- Using the package, several bugs in Singular and GAP have been
uncovered. The new Singular version 3-1-1 fixes some bugs, so that in some
cases more efficient methods can be used. The package tests the available
Singular version; it both supports the new features and is able to work
around the old Singular bugs.
- We finally achieved '''100% doctest coverage!! '''
- By oversight, the old test script failed to execute the tests of
special methods (such as {{{_add_}}} or {{{_mul_}}}. The new script now
captures all tests, and complains if a class, method or function does not
appear to be tested. Also, the test script does parallel tests.
- The parallel testscript uncovered a problem with temporary files
associated with Sage's pexpect interfaces -- see #10004. The testscript
tests if the problem reported at #10004 is fixed, and will only do
parallel testing if it is fixed.
'''2. Extended computational capability'''
- The completeness criteria are further improved. We use three criteria,
namely the modified Benson criterion (found by David Green and myself),
the Symonds criterion and the Hilbert-Poincaré criterion (suggested by
Peter Symonds and worked out by myself). Due to new methods of
constructing parameters, the Symonds criterion is now often the best
choice - but not always, so that it is good to have three methods to
choose from.
- New functionality includes the computation of preimages of induced
homomorphisms, essential ideals and depth essential ideals. Using the
package, a new example of a group was found for which the square of the
essential ideal does not vanish (this is only the second known example!).
So far, a conjecture of Jon Carlson on depth essential ideals can be
confirmed.
'''3. Portability '''
The package fully works on t2! This is a very non-trivial achievement. It
involved:
* Changing the names of several functions from {{{C-MeatAxe}}}, since the
Sun linker seems to confuse them with functions from pari. This is a
problem similar to the one found at #1396.
* t2 is a big-endian machine. GAP's random generator depends on the
endianness (which is a bug). Certain internal data used by the cohomology
computations are obtained by randomised algorithms of GAP. The ring
presentation found for the cohomology ring depends on these internal data.
So, in order to get machine independent computationally well defined
results, special care was needed, as discussed on
[http://groups.google.com/group/sage-
devel/browse_thread/thread/623f7291ab7e782e sage-devel]
'''__Testing__'''
As usual, if the environment variable {{{SAGE_CHECK}}} is exported and has
the value {{{yes}}}, the test script is automatically executed and the
result saved in {{{SAGE_ROOT/install.log}}}.
The script tests parallely. By default, the number of threads is one third
of the number of available CPUs. This can be overruled by exporting the
environment variable {{{SAGE_NUMBER_THREADS}}}.
However, problems with parallel testing in Version 2.1 revealed a problem
with Sage's {{{pexpect}}} interfaces: ''All'' interfaces (e.g., GAP and
Singular) and all parallel branches use a single temporary file for
passing long commands. A solution is at #10004. The test script of the
cohomology spkg will only do parallel testing if gap and singular use
different temporary files.
I successfully installed and tested the package on the following machines
and the following versions of Sage and Singular:
* t2.math, Sage 4.5.1, Singular 3-1-1
* bsd.math, Sage 4.5.2, Singular 3-1-0, both in 64 and 32 bit mode
* sage.math, Sage 4.5.1, Singular 3-1-0
* x86_64 GNU/Linux, Intel Core2 CPU 6700 @ 2.66GHz, Sage 4.5.2, Singular
3-1-1 -- ''without'' write permission in SAGE_DATA.
On another GNU Linux machine with AMD processors, it builds and seems to
work even with Sage 4.2.1, but apparently the interface to the @parallel
decorator has changed, so that I was not able to run the test script.
--
Comment:
I have created a new version 2.1.2, available as stated in the ticket
description.
There were three independent problems:
* Singular upgrade: Some commands have changed, and so I had to rewrite
some parts of my code
* Cython upgrade: Some code, that admittedly was buggy, might have
resulted in an error at running time, and the new Cython is refusing it
during compilation. So, I fixed these bugs.
* Coercion and category framework: Some recent changes in #9138 or #11900
and related stuff, due to yours truly, have created an incompatibility
with the group cohomology package: I shot myself into the foot. Now, the
cohomology rings are making better use of category and coercion framework.
For me, the spkg test suite works. I didn't test on t2 or related
machines, though.
Anyway, ready for review again!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9894#comment:47>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
