#6491: [with spkg, positive review pending] 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:18 wdj]:
> That is fine but I don't see how any of the issues you raise below are
important for the inclusion as an *optional* spkg, which is what this
ticket is about.
OK. I thought that this is the distinction between ''optional'' and
''experimental'', the latter being not completely portable and also not
completely reliable due to doc test errors.
> Since Meataxe is GPLv2 and you compile against it, your package is
GPLv2. I assume you are releasing your *code* under GPLv2+, but the
package itself inherits what Meataxe is. So, '''must''' is only if you
want your optional package to by GPLv2+. There are all kinds of licenses
in the optional spkg's though.
OK. But then it is conflict with my SPKG.txt, isn't it?
> BTW, if you type
>
> {{{
> Type: instance
> Base Class: pGroupCohomology.CohomologyRingFactory
> String Form: <pGroupCohomology.CohomologyRingFactory instance at
0x58075a8>
> Namespace: Interactive
> File: /home/wdj/sagefiles/sage-4.1.rc1/local/lib/python2.6
/site-packages/pGroupCohomology/__init__.py
> Docstring
>
> Constructor for modular cohomology rings of finite p-groups
>
> <snip>
> }}}
> Are you happy with that File descriptor?
What's wrong with it? In fact, this stuff is defined in ``__init__.py``.
The reason is as follows:
- The user is supposed to construct things with the ring constructor.
- Hence, it should be easy to import.
- Hence, it should be on top level: {{{from pGroupCohomology import
CohomologyRing}}} should be better than {{{from
pGroupCohomology.cohomology import CohomologyRing}}}
> > __Porting__
> >
> > Good news is that it works with Ubuntu. But did anybody try with OS X
or on Motorola processors?
>
>
> I thought I mentioned that I also tried this on an intel macbook running
10.4.11.
> Sorry, I thought I did. Install went fine on an intel macbook.
Very cool!! As I mentioned, a few months ago (Sage Days San Diego) it
didn't build at all on a Macbook!
> > __Tests__
> >
> > Did you run the test suite?
>
> Do you mean
> sage: !/home/wdj/sagefiles/p_group_cohomology-1.0/spkg-check ?
Yes, and this is the usual place for a test suite, or at least this is
what I got from the developers guide.
> This gives no idea where {{{cohomology_test.log}}} is located but I
found it.
Sorry. Assuming that the location of the script was clear, when running
it, it writes the log simply in the current work directory.
> for the intel macbook test log. In the ubuntu test log example_51 and
example_7
> had failures. I didn't understand the error but it seems to be a problem
with Singular.
> The macbook behaved better (only example_51 was listed as failing) but
again the
> problem was with Singular.
Some of them are. I don't know what happens, yet. I mean, {{{`def
sage10456=COHO6r(1);`}}} resulting in an error in Singular. These things
sometimes go away if the tests are performed in a different order. So, It
really seems to me that they are due to Singular and not to the package. I
suspect that the number of variable names in Singular is restricted. And
10456 is quite a lot. In fact, while developing the package, I tried to
keep the number of autogenerated variable names small, but it doesn't help
if you run hundreds of doc tests without restarting singular.
But something in the Ubuntu log irritates me: There is one example where a
wrong ring structure is found.
Currently I have no time to analyse it further.
By the way, there also is a test suite spkg-check-details, that does the
doc tests in a different way.
> > __More Features__
> > ...
> >
> > So, what should I do when I have new features? Open a new ticket, with
a version 1.1 of the spkg? Or (as long as the package did not become
optional yet) stay on ''this'' ticket?
> >
>
>
> When version 1.1 is ready, open up a new ticket, describe the changes
and post the new spkg. With new features, I guess you should have new
doctests?
Well, I would have an additional doctest for ''this'' new feature, the
rest would be the same.
> In any case, I think for an optional package, this is fine. If you want
to call it "pending" and make more changes then that is fine too.
Well, I think the Massey product should go in, and I definitely want to
see what happens with the doc tests.
So, I think it would hurt to keep it pending until my return end of July.
Or are there different opinions?
Cheers,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6491#comment:20>
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
-~----------~----~----~----~------~----~------~--~---
