#6491: [with spkg, needs review] Modular Cohomology Rings of Finite p-Groups
-------------------------------+--------------------------------------------
Reporter: SimonKing | Owner: SimonKing
Type: enhancement | Status: assigned
Priority: major | Milestone: sage-4.1.1
Component: optional packages | Keywords: cohomology ring finite p-group
Reviewer: | Author: Simon King
Merged: |
-------------------------------+--------------------------------------------
Comment(by SimonKing):
Replying to [comment:12 wdj]:
> 2. The comparision between crime and your package is a bit more
complicated that it first seems I think. For example, we have
...
> Minimal list of algebraic relations:
> [b_1_0*b_1_1]
...
> sage: gap.eval("CohomologyRelators(C,2)") [[BR]]
> {{{'[ [ z, y, x ], [ z*y+y^2 ] ]' }}} [[BR]]
> These seem different but I am not an expert. Is this difference easy to
explain?
This problem is addressed in the package documentation in various places.
__Explanation:__
Of course, isomorphic rings can have different ring representations. In
fact, when computing the cohomology with our package, the result depends
on the given p-group ''together with a choice of a minimal generating
set''.
Here is an example:
{{{
sage: from pGroupCohomology import CohomologyRing
sage: tmp_root = tmp_filename()
sage: CohomologyRing.set_user_db(tmp_root)
sage: G1 = gap('DihedralGroup(8)')
sage: G2 = gap('SmallGroup(8,3)')
sage: H1 = CohomologyRing.user_db(G1, GroupName = 'Dihedral')
sage: H1.make()
sage: H2 = CohomologyRing.user_db(8,3)
sage: H2.make()
sage: H1.rels()
['b_1_1^2+b_1_0*b_1_1']
sage: H2.rels()
['b_1_0*b_1_1']
}}}
Hence, when we apply our algorithm to the dihedral group with generators
given by DihedralGroup(8), we get a result as in CRIME. But using
generators as provided by the SmallGroups library, the ring presentation
is different.
By the method {{{group()}}}, one gets a permutation group that is
guaranteed to yield the same presentation of the cohomology ring, and you
see: These permutation groups are different, and mapping generators to
generators would not provide an isomorphism of groups.
{{{
sage: H1.group()
Group( [ (1,5)(2,6)(3,8)(4,7), (1,3,2,4)(5,7,6,8) ] )
sage: H2.group()
Group( [ (1,2)(3,8)(4,6)(5,7), (1,3)(2,5)(4,7)(6,8) ] )
}}}
However, the groups ''are'' isomorphic, so, we can construct an induced
homomorphism of the cohomology rings:
{{{
sage: phi = G2.IsomorphismGroups(G1) # note that the resulting isomorphism
is not unique
sage: phi.SetName('"phi"')
sage: phi_star = H1.hom(phi,H2)
sage: phi_star
phi^*
sage: [H2.cochain_to_polynomial(phi_star(X)) for X in H1.gens()]
[1, a 0-Cochain in H^*(D8; GF(2)),
b_1_1^2+c_2_2, a 2-Cochain in H^*(D8; GF(2)),
b_1_1+b_1_0, a 1-Cochain in H^*(D8; GF(2)),
b_1_1, a 1-Cochain in H^*(D8; GF(2))]
}}}
So, the induced homomorphism is not the identity. Just for fun, let us
test whether the preimage of the relation of H2 is really zero in H1:
{{{
sage: print (phi_star^(-1))(H2('b_1_0')) * (phi_star^(-1))(H2('b_1_1'))
2-Cochain in H^*(Dihedral; GF(2)),
represented by
[0 0 0]
}}}
> 3. Regarding the PoincareSeries in HAP: I think Graham Ellis told me
that his PoincareSeries was likely to be true but not guaranteed. Is this
right? If so, how sure are you of yours? (I checked in an example that
they agree.)
I don't know how reliable it is in HAP.
Concerning reliability in our package: Note that there are two completely
different methods for the computation of the Poincaré series, namely
{{{poincare_series()}}} and {{{poincare_without_parameters}}}. The second
method uses a generic algorithm, but the first uses the parameters that
are used in Benson's completeness criterion.
So, to test the reliability, you may compare the output of the two
methods.
Note that both methods do not rely on Hilbert function computations of
Singular. The reason for an independent implementation was in fact that
Singular is not reliable, it sometimes produces silent integer overflows.
> 4. Regarding the license:
>
> (a) Can you ask any surviving Meataxe people if they might relicensing
the version you used under GPLv2+?
Onne may try. Perhaps the more recent versions are already GPLv2+.
However, we need the old version, or we need to re-implement David Green's
code.
> (b) Since David Green is a co-author - he can license the code as he
wants:-)
Well, but it would be wise to use a licence that meets the requirements of
Sage.
> (c) Did you create the database "Data for the cohomology of all groups
of order 64" yourself?
Well, the computer helped me a little...
The data base is not a relational data base (yet!), hence, no SQLAlchemy
involved. It is just the result of the computations of our package,
applying "tar -cz" to the result. Essentially, it is a courtesy, since a
computation from scratch would yield that data base in just about 50
minutes.
> Do you know the distribution license for it?
As I did it myself, I can probably choose. But I don't know how! Can you
explain?
Cheers,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6491#comment:13>
Sage <http://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
-~----------~----~----~----~------~----~------~--~---
