Sage: Ticket #9894: Group cohomology spkg, version 2.1.2
https://trac.sagemath.org/ticket/9894
<p>
Version 2.1.2 of the modular group cohomology package is now available. There is extensive <a class="ext-link" href="http://sage.math.washington.edu/home/SimonKing/Cohomology/index.html"><span class="icon"></span>documentation</a>. The package needs the Small Groups library (available in the gap-packages spkg) and can be installed with <code>sage -i http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.2.spkg</code>
</p>
<p>
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.
</p>
<p>
Moreover, it has new features.
</p>
<p>
<strong><span class="underline">New Features</span></strong>
</p>
<p>
<strong>1. Improved code quality</strong>
</p>
<ul><li>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.
</li></ul><ul><li>Moreover, I split the __call__ method of the cohomology ring constructor into smaller units.
</li></ul><ul><li>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 <em>from scratch</em>. 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.
</li></ul><ul><li>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.
</li></ul><ul><li>I tried to reduce compiler warnings.
</li></ul><ul><li>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.
</li></ul><ul><li>We finally achieved <strong>100% doctest coverage!! </strong>
</li></ul><ul><li>By oversight, the old test script failed to execute the tests of special methods (such as <code>_add_</code> or <code>_mul_</code>. 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.
</li></ul><ul><li>The parallel testscript uncovered a problem with temporary files associated with Sage's pexpect interfaces -- see <a class="closed ticket" href="https://trac.sagemath.org/ticket/10004" title="defect: The gap instances in a parallelised function do not always have ... (closed: fixed)">#10004</a>. The testscript tests if the problem reported at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10004" title="defect: The gap instances in a parallelised function do not always have ... (closed: fixed)">#10004</a> is fixed, and will only do parallel testing if it is fixed.
</li></ul><p>
<strong>2. Extended computational capability</strong>
</p>
<ul><li>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.
</li></ul><ul><li>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.
</li></ul><p>
<strong>3. Portability </strong>
</p>
<p>
The package fully works on t2! This is a very non-trivial achievement. It involved:
</p>
<ul><li>Changing the names of several functions from <code>C-MeatAxe</code>, since the Sun linker seems to confuse them with functions from pari. This is a problem similar to the one found at <a class="closed ticket" href="https://trac.sagemath.org/ticket/1396" title="enhancement: Ideal.groebner_basis should accept keyword arguments for strategy ... (closed: duplicate)">#1396</a>.
</li><li>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 <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/623f7291ab7e782e"><span class="icon"></span>sage-devel</a>
</li></ul><p>
<strong><span class="underline">Testing</span></strong>
</p>
<p>
As usual, if the environment variable <code>SAGE_CHECK</code> is exported and has the value <code>yes</code>, the test script is automatically executed and the result saved in <code>SAGE_ROOT/install.log</code>.
</p>
<p>
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 <code>SAGE_NUMBER_THREADS</code>.
</p>
<p>
However, problems with parallel testing in Version 2.1 revealed a problem with Sage's <code>pexpect</code> interfaces: <em>All</em> interfaces (e.g., GAP and Singular) and all parallel branches use a single temporary file for passing long commands. A solution is at <a class="closed ticket" href="https://trac.sagemath.org/ticket/10004" title="defect: The gap instances in a parallelised function do not always have ... (closed: fixed)">#10004</a>. The test script of the cohomology spkg will only do parallel testing if gap and singular use different temporary files.
</p>
<p>
I successfully installed and tested the package on the following machines and the following versions of Sage and Singular:
</p>
<ul><li>t2.math, Sage 4.5.1, Singular 3-1-1
</li><li>bsd.math, Sage 4.5.2, Singular 3-1-0, both in 64 and 32 bit mode
</li><li>sage.math, Sage 4.5.1, Singular 3-1-0
</li><li>x86_64 GNU/Linux, Intel Core2 CPU 6700 @ 2.66GHz, Sage 4.5.2, Singular 3-1-1 -- <em>without</em> write permission in SAGE_DATA.
</li></ul><p>
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.
</p>
<p>
<strong>optional spkg</strong>: <a class="ext-link" href="http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.2.spkg"><span class="icon"></span>http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.2.spkg</a>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/9894
Trac 1.1.6kcrismanSat, 11 Sep 2010 08:10:39 GMT
https://trac.sagemath.org/ticket/9894#comment:1
https://trac.sagemath.org/ticket/9894#comment:1
<p>
On a Mac OS X 10.4 G4 PPC running at 1.25 GHz, 1 GB memory, I get successful installation and mostly passed doctests, but some failure. See <a class="ext-link" href="http://sage.math.washington.edu/home/kcrisman/RelevantPCohomTest.log"><span class="icon"></span>the relevant bits of the log</a>. I didn't post the whole log because there are some non-failures reported as failures due to another spkg update - I checked these individually, and they are definitely ok. I'm going to try <code>./sage -ba</code> and reinstall just to make sure, but it's apparent that at least a few of these things are real differences - different list entries, different orderings, etc. Happy hunting!
</p>
TicketSimonKingSat, 11 Sep 2010 10:15:45 GMT
https://trac.sagemath.org/ticket/9894#comment:2
https://trac.sagemath.org/ticket/9894#comment:2
<p>
Hi!
</p>
<p>
Thank you for testing!
</p>
<p>
I found this error particularly interesting, at the very end of the file
</p>
<pre class="wiki"> sage: H.sylow_cohomology().Dickson
Expected:
['-b_2_0^6 - b_2_2^6 - b_2_2^2*b_4_6^2 + b_2_2^3*c_6_11 + b_4_6^3', None]
Got:
['b_4_6^3-b_2_2^2*b_4_6^2-b_2_2^6-b_2_0^6+b_2_2^3*c_6_11', None]
</pre><p>
What you got is, as much as I see, the result that you would get when computing <code>H.sylow_cohomology()</code> from scratch. But in fact it is expected that <code>H.sylow_cohomology()</code> is automatically downloaded from a web repository, containing cohomology rings that were computed with an old version of the package and thus have equivalent data (note that the polynomials above are equal) presented in a different form.
</p>
<p>
Could it be that you worked without internet connection? At least, it would explain that particular error.
</p>
<p>
Often there is a "list index out of range" in <code>MODCOHO.find_relations</code>. This one is a bit obscure to me at the moment. Can you try one of these examples manually and post the full traceback?
</p>
<p>
There is one error in "<a class="missing wiki">BarCode?</a>.show"; I have seen this on OS X before, but this seems to be a problem with "show" on OS X in general.
</p>
<p>
Could you please post the <em>entire</em> log? It seems that you cut off too much. E.g., I can not see how <code>COCH.massey_power</code> fails.
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketSimonKingSat, 11 Sep 2010 13:19:00 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/9894#comment:3
https://trac.sagemath.org/ticket/9894#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>tests should work independent of the data the user has on his/her system</em>
</li>
</ul>
<p>
Hi!
</p>
<p>
It seems that there is a problem I hadn't thought of: If one has used the spkg before, then data are accumulated that are later used when doing related computations. Of course, I <em>did</em> use the package before. Now, when testing, it can happen that the old results (potentially obtained with an old program version) are used and spoil the tests.
</p>
<p>
So, @kcrisman, this might be another explanation for the "particularly interesting" failure: There are old data on my computer, and I accidentally used the old data in the tests.
</p>
<p>
I have to think how to solve that problem. Certainly the tests should work both with and without having old data in the system. I did try to write the tests so that the computations are either done from scratch or use data that I have full control of, but it seems that I missed some exceptions.
</p>
<p>
Bets regards,
Simon
</p>
TicketkcrismanSat, 11 Sep 2010 15:53:56 GMT
https://trac.sagemath.org/ticket/9894#comment:4
https://trac.sagemath.org/ticket/9894#comment:4
<p>
I did <code>./sage -ba</code> to get rid of the erroneous errors (that would include the file you refer to). I'll upload an updated version of that part of the log. Also, there *was* internet connection (had to have it to download it, and also to get the gap package I didn't realize I needed until it told me so), but it is true I have never computed these before or used the spkg before. As far as I can tell, the second run had the same failures, but I didn't bother to check all of them by hand.
</p>
<p>
Finally, here is one of the typical failures replicated. I can check some other stuff (possibly not until rather later, though) if you give very explicit instructions as to what commands to run.
</p>
<pre class="wiki">Crismans-Computer:~ crisman$ Desktop/sage-4.5.3/sage
----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: from pGroupCohomology import CohomologyRing
sage: tmp = tmp_filename()
sage: CohomologyRing.set_user_db(tmp)
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing(G,prime=2,GroupName='A8')
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
/Users/crisman/<ipython console> in <module>()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/__init__.pyc in __call__(self, *args, **kwds)
2676 # By now, we have both subgroups and their cohomology rings.
2677 if not HP.completed:
-> 2678 HP.make()
2679 # not needed for HSyl, since it was computed when we did it in the computation of HP
2680
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.make (pGroupCohomology/modular_cohomology.c:46208)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.next (pGroupCohomology/modular_cohomology.c:45211)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/cohomology.so in pGroupCohomology.cohomology.COHO.lift_dickson (pGroupCohomology/cohomology.c:63567)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.PrescribedRestrictions (pGroupCohomology/modular_cohomology.c:35570)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.decomposable_classes (pGroupCohomology/modular_cohomology.c:33350)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.find_relations (pGroupCohomology/modular_cohomology.c:32768)()
IndexError: list index out of range
</pre>
TicketkcrismanSat, 11 Sep 2010 15:55:15 GMT
https://trac.sagemath.org/ticket/9894#comment:5
https://trac.sagemath.org/ticket/9894#comment:5
<p>
If there are tests that need internet, by the way, those should be marked <code># optional - internet</code>.
</p>
TicketSimonKingSat, 11 Sep 2010 17:17:10 GMT
https://trac.sagemath.org/ticket/9894#comment:6
https://trac.sagemath.org/ticket/9894#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:4" title="Comment 4">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
I did <code>./sage -ba</code> to get rid of the erroneous errors (that would include the file you refer to). I'll upload an updated version of that part of the log. Also, there *was* internet connection (had to have it to download it, and also to get the gap package I didn't realize I needed until it told me so), but it is true I have never computed these before or used the spkg before.
</p>
</blockquote>
<p>
Yes, probably that's why. I moved my old data out of the way, and then I got a couple of errors. It turned out that this could be resolved by doing <code>CohomologyRing.user_db(...)</code> when I did <code>CohomologyRing(...)</code> (the latter did access old data).
</p>
<blockquote class="citation">
<blockquote>
<p>
As far as I can tell, the second run had the same failures, but I didn't bother to check all of them by hand.
</p>
</blockquote>
</blockquote>
<p>
Yes, no surprise. My erroneous tests assumed that you had data on your computer obtained by <em>previous</em> versions of the package.
</p>
<blockquote class="citation">
<p>
Finally, here is one of the typical failures replicated. I can check some other stuff (possibly not until rather later, though) if you give very explicit instructions as to what commands to run.
</p>
</blockquote>
<p>
Thank you! I'll see if I can somehow replicate the error.
</p>
<p>
Does the error also occur if you do
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing
sage: tmp = tmp_filename()
sage: CohomologyRing.set_user_db(tmp)
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing.user_db(G,prime=2,GroupName='A8')
</pre><p>
?
Best regards,
Simon
</p>
TicketSimonKingSat, 11 Sep 2010 17:19:17 GMT
https://trac.sagemath.org/ticket/9894#comment:7
https://trac.sagemath.org/ticket/9894#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:5" title="Comment 5">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
If there are tests that need internet, by the way, those should be marked <code># optional - internet</code>.
</p>
</blockquote>
<p>
Thank you! I didn't know that this is possible.
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketSimonKingSat, 11 Sep 2010 20:08:01 GMT
https://trac.sagemath.org/ticket/9894#comment:8
https://trac.sagemath.org/ticket/9894#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:7" title="Comment 7">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:5" title="Comment 5">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
If there are tests that need internet, by the way, those should be marked <code># optional - internet</code>.
</p>
</blockquote>
<p>
Thank you! I didn't know that this is possible.
</p>
</blockquote>
<p>
However, there are only two tests for which the internet accessibility should really make a difference: There, <code>CohomologyRing.web_db(...)</code> is explicitly called.
</p>
<p>
When doing <code>CohomologyRing(...)</code> or <code>CohomologyRing.user_db(...)</code>, it is tried to download the result from the web repository (unless requested otherwise by the optional argument <code>websource=False</code>), and if this fails, the computation is simply started from scratch, without raising an error.
</p>
<p>
I am now trying to change the tests so that they will work both with or without old data being present.
</p>
TicketkcrismanSun, 12 Sep 2010 00:00:16 GMT
https://trac.sagemath.org/ticket/9894#comment:9
https://trac.sagemath.org/ticket/9894#comment:9
<blockquote class="citation">
<p>
Does the error also occur if you do
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing
sage: tmp = tmp_filename()
sage: CohomologyRing.set_user_db(tmp)
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing.user_db(G,prime=2,GroupName='A8')
</pre></blockquote>
<p>
It's slightly different:
</p>
<pre class="wiki">Crismans-Computer:~ crisman$ Desktop/sage-4.5.3/sage
----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: sage: from pGroupCohomology import CohomologyRing
sage: sage: tmp = tmp_filename()
sage: sage: CohomologyRing.set_user_db(tmp)
sage: sage: G = gap('AlternatingGroup(8)')
sage: sage: H = CohomologyRing.user_db(G,prime=2,GroupName='A8')
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
/Users/crisman/<ipython console> in <module>()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/__init__.pyc in user_db(self, *args, **kwds)
2991 """
2992 kwds['root'] = COHO.user_db
-> 2993 return self(*args, **kwds)
2994
2995 def set_web_db(self, s = None):
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/__init__.pyc in __call__(self, *args, **kwds)
2676 # By now, we have both subgroups and their cohomology rings.
2677 if not HP.completed:
-> 2678 HP.make()
2679 # not needed for HSyl, since it was computed when we did it in the computation of HP
2680
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.make (pGroupCohomology/modular_cohomology.c:46208)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.next (pGroupCohomology/modular_cohomology.c:45211)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/cohomology.so in pGroupCohomology.cohomology.COHO.lift_dickson (pGroupCohomology/cohomology.c:63567)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.PrescribedRestrictions (pGroupCohomology/modular_cohomology.c:35570)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.decomposable_classes (pGroupCohomology/modular_cohomology.c:33350)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.find_relations (pGroupCohomology/modular_cohomology.c:32768)()
IndexError: list index out of range
</pre><p>
But essentially the same. Apparently the <code>find_relations</code> method is assuming some list has the wrong length.
</p>
TicketSimonKingSun, 12 Sep 2010 08:49:58 GMT
https://trac.sagemath.org/ticket/9894#comment:10
https://trac.sagemath.org/ticket/9894#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:4" title="Comment 4">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Finally, here is one of the typical failures replicated. I can check some other stuff (possibly not until rather later, though) if you give very explicit instructions as to what commands to run.
</p>
</blockquote>
<p>
There are various lists occuring inside <code>find_relations</code>. There is also some Singular commands used to determine coefficients of lists, so, the error could be there as well.
</p>
<p>
Since I can not replicate it on my computer, can you please do/answer the following?
</p>
<p>
What version of Sage are you using? What version of Singular is it?
</p>
<p>
Remove your "private cohomology database" in order to be sure that there is no debris left. You will probably not mind to do it by <code>rm -r ~/.sage/pGroupCohomology/db/*</code> (or you can move the contents of the folder to a backup location). The folder itself must be present, though.
</p>
<p>
Do the following in Sage:
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing, _cache
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing(G,prime=2,GroupName='A8')
sage: for X in _cache.values():
....: print X.autosave_name(), X.completed
....:
</pre><p>
This should give something like
</p>
<pre class="wiki">/home/king/.sage/pGroupCohomology/db/H6gp1mod2.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/8gp3/H8gp3.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/32gp49/H32gp49.sobj True
/home/king/.sage/pGroupCohomology/db/H192gp1493mod2.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/32gp27/H32gp27.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/2gp1/H2gp1.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/64gp138/H64gp138.sobj True
/home/king/.sage/pGroupCohomology/db/HA8mod2.sobj False
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/16gp14/H16gp14.sobj True
/home/king/SAGE/sage-4.4.2/data/pGroupCohomology/8gp5/H8gp5.sobj True
</pre><p>
These are all cohomology rings that one needs to know in order to compute <code>H</code>. But since the construction of <code>H</code> fails for you, the list might be different, and at least the <code>.../HA8mod2.sobj</code> should be missing.
</p>
<p>
You see that the cohomology rings of prime power groups are in the public database <code>SAGE_ROOT/data/...</code>, whereas the non prime power groups are in your private database <code>~/.sage/...</code>.
</p>
<p>
Do you get a <code>False</code> after a prime power group in the above list?
</p>
<p>
According to the traceback you got, I expect that you have a <code>False</code> after <code>H192gp1493mod2.sobj</code>. Can you please post (or send me by e-mail) all files from the above list which are followed by <code>False</code>? Then I can do further debugging with them.
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketSimonKingSun, 12 Sep 2010 14:58:45 GMT
https://trac.sagemath.org/ticket/9894#comment:11
https://trac.sagemath.org/ticket/9894#comment:11
<p>
Hi Karl-Dieter,
</p>
<p>
There is also another way to potentially get more insight: Could you try the computation in protocol mode, i.e., <code>H = CohomologyRing(G,prime=2,GroupName='A8',options='prot')</code>? The last few protocol lines before the error will probably help to locate the problem.
</p>
<p>
Best regards,
Simon
</p>
TicketSimonKingSun, 12 Sep 2010 16:26:59 GMTwork_issues changed
https://trac.sagemath.org/ticket/9894#comment:12
https://trac.sagemath.org/ticket/9894#comment:12
<ul>
<li><strong>work_issues</strong>
changed from <em>tests should work independent of the data the user has on his/her system</em> to <em>bug in find_relations on some systems; tests should work independent of the data the user has on his/her system</em>
</li>
</ul>
<p>
Perhaps I found the solution: In <code>find_relations</code> (and various other places), I parsed an ideal M in Singular into a list of strings as follows:
</p>
<pre class="wiki">singular.eval('print(%s)'%M.name()).split(',\n')
</pre><p>
I guess that <code>split(',\n')</code> is a mistake: There are systems (including OS X?) on which '\n' is not the line break character. So, I should better do
</p>
<pre class="wiki">[t.strip() for t in singular.eval('print(%s)'%M.name()).split(',')]
</pre><p>
I am now preparing and testing an updated version. So, until later...
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketSimonKingSun, 12 Sep 2010 20:43:11 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/9894#comment:13
https://trac.sagemath.org/ticket/9894#comment:13
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
changed from <em>bug in find_relations on some systems; tests should work independent of the data the user has on his/her system</em> to <em>Is the code independent of the computer's newline character?</em>
</li>
</ul>
<p>
Hi!
</p>
<p>
I updated the package, changing the tests so that they should work with or without old data being present, and changing the code so that it is not expected that '\n' is the newline character.
</p>
<p>
I tested it on the desktop computer in my office and am currently running tests on bsd.math, t2.math and sage.math.
</p>
<p>
So, it is ready for review again.
</p>
<p>
If you want to re-install and test the package, please don't forget to delete the copy of the <em>old</em> package version, for otherwise the new version would not be downloaded. Hence,
</p>
<pre class="wiki">rm $SAGE_ROOT/spkg/optional/p_group_cohomology-2.1.spkg
sage -f http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.spkg
</pre><p>
Testing with
</p>
<pre class="wiki">export SAGE_CHECK=yes
</pre><p>
Bounding the number of parallel tests with, e.g.
</p>
<pre class="wiki">export SAGE_NUMBER_THREADS=2
</pre><p>
Cheers,
</p>
<p>
Simon
</p>
TicketSimonKingMon, 13 Sep 2010 07:27:58 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/9894#comment:14
https://trac.sagemath.org/ticket/9894#comment:14
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
changed from <em>Is the code independent of the computer's newline character?</em> to <em>Fix problems on t2. Is the code independent of the computer's newline character?</em>
</li>
</ul>
<p>
There are doctest failures on t2. So, back at work...
</p>
TicketSimonKingMon, 13 Sep 2010 10:06:45 GMT
https://trac.sagemath.org/ticket/9894#comment:15
https://trac.sagemath.org/ticket/9894#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:14" title="Comment 14">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
There are doctest failures on t2. So, back at work...
</p>
</blockquote>
<p>
But it's strange: <em>All</em> errors come from GAP, and they are like
</p>
<pre class="wiki">TypeError: Error evaluating $sage81:=IsBoundGlobal("exportMTXLIB");; in Gap
</pre><p>
or
</p>
<pre class="wiki"> TypeError: Error evaluating $sage24:="DihedralB";; in Gap
</pre><p>
Of course, both commands are supposed to work! I could imagine that it is a parallelisation problem. The errors occurred with <code>SAGE_NUMBER_THREADS=8</code>. I am now seeing if it works with <code>SAGE_NUMBER_THREADS=4</code>.
</p>
TicketSimonKingMon, 13 Sep 2010 14:47:17 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/9894#comment:16
https://trac.sagemath.org/ticket/9894#comment:16
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
changed from <em>Fix problems on t2. Is the code independent of the computer's newline character?</em> to <em>Is the code independent of the computer's newline character?</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:15" title="Comment 15">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:14" title="Comment 14">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
There are doctest failures on t2. So, back at work...
</p>
</blockquote>
<p>
But it's strange: <em>All</em> errors come from GAP...
</p>
</blockquote>
<p>
And when I did it again, they vanished. Strange enough. But I think testing on the machine of kcrisman is more important. Can you please try?
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketkcrismanMon, 13 Sep 2010 15:01:34 GMT
https://trac.sagemath.org/ticket/9894#comment:17
https://trac.sagemath.org/ticket/9894#comment:17
<blockquote class="citation">
<p>
And when I did it again, they vanished. Strange enough. But I think testing on the machine of kcrisman is more important. Can you please try?
</p>
</blockquote>
<p>
Eventually, but at least not until tonight, possibly not until several evenings from now. I will try hard to <code>rm</code> all relevant stuff, though, before trying all this out :)
</p>
TicketkcrismanTue, 14 Sep 2010 00:46:45 GMT
https://trac.sagemath.org/ticket/9894#comment:18
https://trac.sagemath.org/ticket/9894#comment:18
<blockquote class="citation">
<p>
Since I can not replicate it on my computer, can you please do/answer the following?
</p>
<p>
What version of Sage are you using? What version of Singular is it?
</p>
</blockquote>
<p>
I have no explanation for the following.
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: singular_version()
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
/Users/crisman/<ipython console> in <module>()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/sage/interfaces/singular.pyc in singular_version()
1916 EXAMPLES:
1917 """
-> 1918 return singular.eval('system("--version");')
1919
1920
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/sage/interfaces/singular.pyc in eval(self, x, allow_semicolon, strip, **kwds)
547
548 if s.find("error") != -1 or s.find("Segment fault") != -1:
--> 549 raise RuntimeError, 'Singular error:\n%s'%s
550
551 if get_verbose() > 0:
RuntimeError: Singular error:
? cannot open `help.cnf`
Singular for ppcMac-darwin version 3-1-1 (3114-2010090802) Sep 8 2010 02:24:06
with
factory(@(#) factoryVersion = 3.1.1),libfac(3.1.1,Feb 2010),
GMP(4.2),NTL(5.4.2),32bit,static readline,Plural,DBM,
dynamic modules,OM_NDEBUG,random=1284424481
CC= gcc -O3 -g -fPIC -pipe -DNDEBUG -DOM_NDEBUG -DppcMac_darwin -DHAVE_CONFIG_H,
CXX= g++ -O3 -g -fPIC -pipe -DNDEBUG -DOM_NDEBUG -DppcMac_darwin -DHAVE_CONFIG_H (4.0.1 (Apple Computer, Inc. build 5370))
argv[0] : Singular-3-1-1
SearchPath: /Users/crisman/Desktop/sage-4.5.3/local/share/singular:/Users/crisman/Desktop/sage-4.5.3/local/LIB
Singular : /Users/crisman/Desktop/sage-4.5.3/local/bin/Singular
BinDir : /Users/crisman/Desktop/sage-4.5.3/local/bin
RootDir : /Users/crisman/Desktop/sage-4.5.3/local
DefaultDir: /Users/crisman/Desktop/sage-4.5.3/local
InfoFile :
IdxFile :
HtmlDir :
ManualUrl : http://www.singular.uni-kl.de/Manual/3-1-1
ExDir :
Path : /Users/crisman/Desktop/sage-4.5.3/local/bin:/Users/crisman/Desktop/sage-4.5.3:/bin:/sbin:/usr/bin:/usr/sbin
EmacsDir :
Available HelpBrowsers: dummy, emacs,
Current HelpBrowser: dummy
? error occurred in or before STDIN line 49965: `system("--version");`
</pre><p>
But as you can see in the error messages, it's the 3.1.1 devel version, and this works:
</p>
<pre class="wiki">Crismans-Computer:~ crisman$ Desktop/sage-4.5.3/sage -singular
SINGULAR / Development
A Computer Algebra System for Polynomial Computations / version 3-1-1
0<
by: G.-M. Greuel, G. Pfister, H. Schoenemann \ Feb 2010
FB Mathematik der Universitaet, D-67653 Kaiserslautern \
</pre><blockquote class="citation">
<p>
Remove your "private cohomology database" in order to be sure that there is no debris left. You will probably not mind to do it by <code>rm -r ~/.sage/pGroupCohomology/db/*</code> (or you can move the contents of the folder to a backup location). The folder itself must be present, though.
</p>
<p>
Do the following in Sage:
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing, _cache
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing(G,prime=2,GroupName='A8')
</pre></blockquote>
<p>
This fails for me earlier:
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing, _cache
sage: G = gap('AlternatingGroup(8)')
sage: H = CohomologyRing(G,prime=2,GroupName='A8')
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
/Users/crisman/<ipython console> in <module>()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/__init__.pyc in __call__(self, *args, **kwds)
2676 # By now, we have both subgroups and their cohomology rings.
2677 if not HP.completed:
-> 2678 HP.make()
2679 # not needed for HSyl, since it was computed when we did it in the computation of HP
2680
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.make (pGroupCohomology/modular_cohomology.c:46208)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.next (pGroupCohomology/modular_cohomology.c:45211)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/cohomology.so in pGroupCohomology.cohomology.COHO.lift_dickson (pGroupCohomology/cohomology.c:63567)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.PrescribedRestrictions (pGroupCohomology/modular_cohomology.c:35570)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.decomposable_classes (pGroupCohomology/modular_cohomology.c:33350)()
/Users/crisman/Desktop/sage-4.5.3/local/lib/python2.6/site-packages/pGroupCohomology/modular_cohomology.so in pGroupCohomology.modular_cohomology.MODCOHO.find_relations (pGroupCohomology/modular_cohomology.c:32768)()
IndexError: list index out of range
</pre><p>
I'll try the reinstall next.
</p>
TicketkcrismanTue, 14 Sep 2010 00:59:30 GMT
https://trac.sagemath.org/ticket/9894#comment:19
https://trac.sagemath.org/ticket/9894#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:11" title="Comment 11">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Hi Karl-Dieter,
</p>
<p>
There is also another way to potentially get more insight: Could you try the computation in protocol mode, i.e., <code>H = CohomologyRing(G,prime=2,GroupName='A8',options='prot')</code>? The last few protocol lines before the error will probably help to locate the problem.
</p>
</blockquote>
<p>
Cool documentation of what is going on! I removed the db stuff (but not the folder) again, and got this before the same error (I assume that up to here it is the same for you):
</p>
<pre class="wiki">
There is no new generator of H^*(SmallGroup(192,1493); GF(2)) in degree 7
Degree 7 of the visible ring structure of H^*(SmallGroup(192,1493); GF(2)) is computed!
Saving H^*(SmallGroup(192,1493); GF(2))
We expect that the Hilbert-Poincare criterion will not apply before degree 11
Start computation in Degree 8
All stable cocycles are decomposable
Determine degree 8 standard monomials of H^*(SmallGroup(192,1493); GF(2))
Express 48 standard monomials as cocycles
> Interreduction
> Determining decomposable subspace
> Extracting relations
There is no new relation in degree 8
There is no new generator of H^*(SmallGroup(192,1493); GF(2)) in degree 8
Try to lift 1st power of 0th Dickson invariant
Determine degree 8 standard monomials of H^*(SmallGroup(192,1493); GF(2))
Express 48 standard monomials as cocycles
> Interreduction
> Determining decomposable subspace
> Extracting decomposable cocycles and relations
---------------------------------------------------------------------------
IndexError Traceback (most recent call last)
</pre>
TicketkcrismanTue, 14 Sep 2010 01:06:11 GMT
https://trac.sagemath.org/ticket/9894#comment:20
https://trac.sagemath.org/ticket/9894#comment:20
<blockquote class="citation">
<p>
If you want to re-install and test the package, please don't forget to delete the copy of the <em>old</em> package version, for otherwise the new version would not be downloaded. Hence,
</p>
<pre class="wiki">rm $SAGE_ROOT/spkg/optional/p_group_cohomology-2.1.spkg
sage -f http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.spkg
</pre><p>
Testing with
</p>
<pre class="wiki">export SAGE_CHECK=yes
</pre></blockquote>
<p>
Currently doing this. It will take some time.
</p>
<blockquote class="citation">
<pre class="wiki">export SAGE_NUMBER_THREADS=2
</pre></blockquote>
<p>
lol - this processor has one core, and you can't do multiple thread with Sage on it (I've tried).
</p>
TicketSimonKingTue, 14 Sep 2010 08:05:44 GMT
https://trac.sagemath.org/ticket/9894#comment:21
https://trac.sagemath.org/ticket/9894#comment:21
<p>
Hi!
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:19" title="Comment 19">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
...
Determining decomposable subspace
Extracting decomposable cocycles and relations
</p>
</blockquote>
</blockquote>
<p>
Yep. That confirms my conjecture. Right after that line of protocol, there is a line containing a <code>split</code> statement, and IIRC it originally was
</p>
<pre class="wiki">SelfValues = singular.eval('print(%s)'%DG.name()).split(',\n')
</pre><p>
In the current version, it is
</p>
<pre class="wiki">SelfValues = [t.strip() for t in singular.eval('print(%s)'%DG.name()).split(',')]
</pre><p>
instead.
</p>
<p>
Could you test the following, please:
</p>
<pre class="wiki">sage: R = singular.ring(0,'(x,y)','dp')
sage: I = singular.maxideal(3)
sage: singular.eval('print(%s)'%I.name()).split(',\n')
['y^3', 'x*y^2', 'x^2*y', 'x^3']
sage: [t.strip() for t in singular.eval('print(%s)'%I.name()).split(',')]
['y^3', 'x*y^2', 'x^2*y', 'x^3']
</pre><p>
I reckon that on your computer the two lists are different.
</p>
<p>
Cheers,
</p>
<p>
Simon
</p>
TicketkcrismanTue, 14 Sep 2010 08:32:58 GMT
https://trac.sagemath.org/ticket/9894#comment:22
https://trac.sagemath.org/ticket/9894#comment:22
<blockquote class="citation">
<p>
Could you test the following, please:
</p>
<pre class="wiki">sage: R = singular.ring(0,'(x,y)','dp')
sage: I = singular.maxideal(3)
sage: singular.eval('print(%s)'%I.name()).split(',\n')
['y^3', 'x*y^2', 'x^2*y', 'x^3']
sage: [t.strip() for t in singular.eval('print(%s)'%I.name()).split(',')]
['y^3', 'x*y^2', 'x^2*y', 'x^3']
</pre></blockquote>
<p>
Well:
{{{----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
</p>
<hr />
<p>
sage: R = singular.ring(0,'(x,y)','dp')
sage: I = singular.maxideal(3)
sage: singular.eval('print(%s)'%I.name()).split(',\n')
['y<sup>3', 'x*y</sup>2', 'x<sup>2*y', 'x</sup>3']
sage: [t.strip() for t in singular.eval('print(%s)'%I.name()).split(',')]
['y<sup>3', 'x*y</sup>2', 'x<sup>2*y', 'x</sup>3']
}}}
But:
</p>
<pre class="wiki">Successfully installed p_group_cohomology-2.1
Running the test suite.
Testing the package pGroupCohomology...
Will use 1 parallel processes
pGroupCohomology fails
pGroupCohomology.unit_test_64 passes in 585.23 s
pGroupCohomology._IsKeyEquivalent passes in 52.95 s
<snip>
pGroupCohomology.resolution.G_ALG.kG_map passes in 16.91 s
pGroupCohomology.resolution.G_ALG.isAbelian passes in 17.09 s
pGroupCohomology.resolution.MasseyDefiningSystems passes in 15.39 s
pGroupCohomology.resolution.MasseyDefiningSystems.__init__ passes in 15.38 s
pGroupCohomology.resolution.MasseyDefiningSystems._make passes in 15.43 s
pGroupCohomology.resolution.MasseyDefiningSystems.values passes in 17.53 s
There were doctest failures:
pGroupCohomology:
sage -t -optional -long "/Users/crisman/.sage/temp/Crismans_Computer.local/3200/dir_0/file_0.py"
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
[1803.1 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -optional -long "/Users/crisman/.sage/temp/Crismans_Computer.local/3200/dir_0/file_0.py" # Time out
Total time for all tests: 1803.4 seconds
Summary
-------
The following tests fail:
pGroupCohomology
Total time: 15702.23 sec
</pre><p>
So now I'll just
</p>
<pre class="wiki">export SAGE_TIMEOUT_LONG=3600
</pre><p>
and <code>./sage -f</code> it again, and hopefully all will be well in the morning. I have to say, five hours to install and test - that's quite an spkg, quite the computation!
</p>
TicketkcrismanTue, 14 Sep 2010 08:35:05 GMT
https://trac.sagemath.org/ticket/9894#comment:23
https://trac.sagemath.org/ticket/9894#comment:23
<p>
Not sure what happened there - must have formatted wrong.
</p>
<pre class="wiki">----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: R = singular.ring(0,'(x,y)','dp')
sage: I = singular.maxideal(3)
sage: singular.eval('print(%s)'%I.name()).split(',\n')
['y^3', 'x*y^2', 'x^2*y', 'x^3']
sage: [t.strip() for t in singular.eval('print(%s)'%I.name()).split(',')]
['y^3', 'x*y^2', 'x^2*y', 'x^3']
</pre>
TicketkcrismanTue, 14 Sep 2010 08:35:44 GMT
https://trac.sagemath.org/ticket/9894#comment:24
https://trac.sagemath.org/ticket/9894#comment:24
<p>
If that fails again, I would like to know where these doctests live in the spkg so I can figure out how to run them individually.
</p>
TicketSimonKingTue, 14 Sep 2010 08:54:15 GMT
https://trac.sagemath.org/ticket/9894#comment:25
https://trac.sagemath.org/ticket/9894#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:22" title="Comment 22">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
and <code>./sage -f</code> it again, and hopefully all will be well in the morning. I have to say, five hours to install and test - that's quite an spkg, quite the computation!
</p>
</blockquote>
</blockquote>
<p>
Ouch! Five hours is really much. On my desktop computer, the total time for the tests is <code>2812.09 sec</code>, and installation takes maybe 10 minutes.
</p>
<p>
By the way, the test skript runs *all* doctests. So, it always includes the ones marked long. Perhaps in the next version I should provide the possibility to only run the short tests.
</p>
<p>
But what is the point of having tests that take so long? This is due to the fact that often I was not able to find smaller examples that show the benefit of a particular method.
</p>
<p>
How to find the doctests? Well, you had a timeout in pGroupCohomology. So, you are in the lucky situation that the test is in a Python file, namely (if you untar'd the package) in <code>p_group_cohomology-2.1/src/pGroupCohomology/__init__.py</code>. You could run <code>sage -t -verbose -long</code> on that file (that wouldn't work for the Cython files). Using the "verbose" option would show exactly what part of the test takes so long.
</p>
<p>
It is surprising to me that the two lists in the little <code>split</code> test are equal. But anyway, I think <code>[t.strip() for t in singular.eval('print(%s)'%I.name()).split(',')]</code> is cleaner than <code>singular.eval('print(%s)'%I.name()).split(',\n')</code>
</p>
<p>
Cheers,
</p>
<p>
Simon
</p>
TicketSimonKingTue, 14 Sep 2010 10:34:20 GMT
https://trac.sagemath.org/ticket/9894#comment:26
https://trac.sagemath.org/ticket/9894#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:22" title="Comment 22">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I have to say, five hours to install and test - that's quite an spkg, quite the computation!
</p>
</blockquote>
</blockquote>
<p>
PS:
</p>
<p>
On my machine, the longest <em>single</em> test takes about 90 seconds. Since the documentation of <code>pGroupCohomology.__init__</code> contains many examples (it is an introduction how to use the package), it is no surprise that it takes longer, but it is still <code>pGroupCohomology passes in 242.05 s</code>.
</p>
TicketkcrismanTue, 14 Sep 2010 11:00:17 GMTreviewer set; work_issues deleted
https://trac.sagemath.org/ticket/9894#comment:27
https://trac.sagemath.org/ticket/9894#comment:27
<ul>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>work_issues</strong>
<em>Is the code independent of the computer's newline character?</em> deleted
</li>
</ul>
<blockquote class="citation">
<p>
On my machine, the longest <em>single</em> test takes about 90 seconds. Since the documentation of <code>pGroupCohomology.__init__</code> contains many examples (it is an introduction how to use the package), it is no surprise that it takes longer, but it is still <code>pGroupCohomology passes in 242.05 s</code>.
</p>
</blockquote>
<pre class="wiki">pGroupCohomology passes in 1205.79 s
</pre><p>
So less than six times slower - not bad ;)
</p>
<p>
I think the timeout was because I had a heavy other load (watching Carl Witty's video, downloading things) when I ran it the first time. But remember, this is a 1.25 GHz machine with only 1 GB memory!
</p>
<p>
Anyway, I can't review this any more because I don't use Singular or GAP much at all (though I still think it's cool that you are calculating the cohomology rings as rings, there has to be a way to apply this nicely to the topology stuff in Sage), but I will at least add myself as a first reviewer.
</p>
TicketSimonKingTue, 14 Sep 2010 15:10:55 GMT
https://trac.sagemath.org/ticket/9894#comment:28
https://trac.sagemath.org/ticket/9894#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:27" title="Comment 27">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
I think the timeout was because I had a heavy other load (watching Carl Witty's video, downloading things) when I ran it the first time. But remember, this is a 1.25 GHz machine with only 1 GB memory!
</p>
</blockquote>
<p>
OK, my machine has 2 GB. But actually keeping the memory consumption low was a driving force behind many things that I did for the first version of the package. As a result, the cohomology for most (but not all) groups of order 128 can be computed with 2 GB.
</p>
<p>
But I think I should put "find smaller test cases" on my to-do list for version 2.2.
</p>
<blockquote class="citation">
<p>
Anyway, I can't review this any more because I don't use Singular or GAP much at all
</p>
</blockquote>
<p>
What a pity! But thanks for your effort!
</p>
<blockquote class="citation">
<p>
(though I still think it's cool that you are calculating the cohomology rings as rings, there has to be a way to apply this nicely to the topology stuff in Sage),
</p>
</blockquote>
<p>
I wonder if this will be possible. As it is, the package is very much addressed to algebra, and I don't see how this could be changed.
</p>
<blockquote class="citation">
<p>
but I will at least add myself as a first reviewer.
</p>
</blockquote>
<p>
Sure!
</p>
<p>
Best regards,
</p>
<p>
Simon
</p>
TicketSimonKingSat, 25 Sep 2010 23:01:08 GMTowner, description, summary changed
https://trac.sagemath.org/ticket/9894#comment:29
https://trac.sagemath.org/ticket/9894#comment:29
<ul>
<li><strong>owner</strong>
changed from <em>tbd</em> to <em>SimonKing</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/9894?action=diff&version=29">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Group cohomology spkg, version 2.1</em> to <em>Group cohomology spkg, version 2.1.1</em>
</li>
</ul>
<p>
In the meantime, I created a new version of the package (and changed the description accordingly). It was inspired by David Green's complaint that the package would try to load data from SAGE_DATA but would then be unable to do further computations without write permission.
</p>
TicketkcrismanThu, 02 Dec 2010 16:34:25 GMT
https://trac.sagemath.org/ticket/9894#comment:30
https://trac.sagemath.org/ticket/9894#comment:30
<p>
What do you think needs still to be done/checked for positive review?
</p>
TicketSimonKingThu, 02 Dec 2010 16:54:53 GMT
https://trac.sagemath.org/ticket/9894#comment:31
https://trac.sagemath.org/ticket/9894#comment:31
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:30" title="Comment 30">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
What do you think needs still to be done/checked for positive review?
</p>
</blockquote>
<p>
I think the guide line are the new features, which are (according to the project home page):
</p>
<ul><li>v2.1.1: Usage of symbolic links to the public database, so that one can use (but of course not install) this package even without write permission in SAGE_DATA. Restructuring the code. Parallel testing is now only permitted if ticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/10004" title="defect: The gap instances in a parallelised function do not always have ... (closed: fixed)">#10004</a> is applied (September 2010).
</li><li>v2.1: Support for big endian machines. 100% doctest coverage, parallel testing. New: Essential and depth essential ideals. Improved completion tests. (September 2010).
</li></ul><p>
In other words, it would be good if someone who is not author (i.e., not I) does parallel tests on a machine like T2 (which is big endian), in the following setting: The package is installed by someone with write permission in SAGE_DATA, but tested by someone <em>without</em> write permission in SAGE_DATA.
</p>
<p>
And from the mathematical point of view, one might look at essential and depth essential ideals.
</p>
TicketkcrismanThu, 02 Dec 2010 17:08:10 GMT
https://trac.sagemath.org/ticket/9894#comment:32
https://trac.sagemath.org/ticket/9894#comment:32
<p>
Hmm, I don't know how to do # 1 (though I have access to a big endian machine), since I am the only user on the box; I definitely am not enough of a group cohomology expert to do # 2!
</p>
TicketSimonKingThu, 02 Dec 2010 17:15:31 GMT
https://trac.sagemath.org/ticket/9894#comment:33
https://trac.sagemath.org/ticket/9894#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:32" title="Comment 32">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Hmm, I don't know how to do # 1 (though I have access to a big endian machine), since I am the only user on the box; I definitely am not enough of a group cohomology expert to do # 2!
</p>
</blockquote>
<p>
I did it like that: I installed Sage plus the database_gap package plus the cohomology package as root, and then I did computations in my usual account.
</p>
<p>
Another possibility: Install the package in the usual way, but then change the permissions (recursively, of course) for SAGE_DATA, so that you have read but not write permission - then you should still be able to use the package.
</p>
TicketSimonKingSat, 28 May 2011 09:31:26 GMT
https://trac.sagemath.org/ticket/9894#comment:34
https://trac.sagemath.org/ticket/9894#comment:34
<p>
-- bump --
</p>
<p>
Any reviewer for version 2.1.1 of the optional group cohomology package, after 6 months?
</p>
TicketkcrismanWed, 01 Jun 2011 03:12:55 GMT
https://trac.sagemath.org/ticket/9894#comment:35
https://trac.sagemath.org/ticket/9894#comment:35
<p>
I wish I could. It seemed to work great at the time, but I just don't have the time to do the things needed to test some of the things you mention above. It does seem a big shame it's not positively reviewed.
</p>
TicketjhpalmieriWed, 20 Jul 2011 00:32:08 GMT
https://trac.sagemath.org/ticket/9894#comment:36
https://trac.sagemath.org/ticket/9894#comment:36
<p>
I tried this out with SAGE_CHECK=yes, and I'm getting doctest failures on three different platforms: sage.math, OS X, and fulvia (a skynet machine which is OpenSolaris on x86). I'm attaching logs for them. On sage.math, this was based on a vanilla copy of 4.7.1.alpha4, and on the other machines, it was on top of 4.7.1.rc0. I'm also building on the skynet machine mark, but it's abominably slow, so I don't know when it will finish.
</p>
<p>
Do I need to be concerned about these?
</p>
TicketjhpalmieriWed, 20 Jul 2011 00:32:38 GMTattachment set
https://trac.sagemath.org/ticket/9894
https://trac.sagemath.org/ticket/9894
<ul>
<li><strong>attachment</strong>
set to <em>sage-math.log</em>
</li>
</ul>
<p>
doctest failures, sage.math.washington.edu
</p>
TicketjhpalmieriWed, 20 Jul 2011 00:32:55 GMTattachment set
https://trac.sagemath.org/ticket/9894
https://trac.sagemath.org/ticket/9894
<ul>
<li><strong>attachment</strong>
set to <em>osx.log</em>
</li>
</ul>
<p>
doctest failures, OS X box
</p>
TicketjhpalmieriWed, 20 Jul 2011 00:33:29 GMTattachment set
https://trac.sagemath.org/ticket/9894
https://trac.sagemath.org/ticket/9894
<ul>
<li><strong>attachment</strong>
set to <em>fulvia-opensolaris.log</em>
</li>
</ul>
<p>
doctest failures, OpenSolaris
</p>
TicketSimonKingWed, 20 Jul 2011 07:31:39 GMT
https://trac.sagemath.org/ticket/9894#comment:37
https://trac.sagemath.org/ticket/9894#comment:37
<p>
Hi John!
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:36" title="Comment 36">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I tried this out with SAGE_CHECK=yes, and I'm getting doctest failures on three different platforms: sage.math, OS X, and fulvia
</p>
</blockquote>
<p>
Thank you for returning to this!
</p>
<p>
It is rather unfortunate to have failures. I hope that I will have time to fix them -- I am already in the middle of the next project.
</p>
<blockquote class="citation">
<p>
I'm also building on the skynet machine mark, but it's abominably slow, so I don't know when it will finish.
</p>
<p>
Do I need to be concerned about these?
</p>
</blockquote>
<p>
I guess if there are failures on three different machines then you don't need to wait for mark.
</p>
<p>
One question: Most of the errors look like
</p>
<pre class="wiki"> sig_on_count()
Expected:
0
Got:
15
</pre><p>
What does that sig_on_count() mean? Does that mean that I forgot <code>_sig_off</code> after <code>_sig_on</code>?
</p>
TicketjhpalmieriWed, 20 Jul 2011 16:18:48 GMT
https://trac.sagemath.org/ticket/9894#comment:38
https://trac.sagemath.org/ticket/9894#comment:38
<blockquote class="citation">
<p>
What does that sig_on_count() mean? Does that mean that I forgot _sig_off after _sig_on?
</p>
</blockquote>
<p>
I have no idea, but it sounds like a good guess to me.
</p>
TicketSimonKingThu, 21 Jul 2011 09:29:31 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/9894#comment:39
https://trac.sagemath.org/ticket/9894#comment:39
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>fix doc tests</em>
</li>
</ul>
<p>
<span class="underline">Speed</span>
</p>
<p>
I will use the occasion to slightly modify the <code>MeatAxe</code> sources (they already <em>are</em> modified compared with release 2.2.4):
</p>
<p>
<code>MeatAxe</code> uses plain loops to initialise memory. Actually, Michael Ringe did replace memset by such loops, in Revision 2.7. However, he does not explain why he did so.
</p>
<p>
Since most compilers should be pretty well in optimising memset (or calloc), I re-introduce the usage of memset and also of calloc. With that change, the multiplication time for two 2000x2000 matrices over GF(125) drops from 15 seconds (which already beats the default <code>Matrix_modn_dense</code> in Sage by a loooooong way!) to less than 12 seconds on my machine.
</p>
<p>
In other words, the cohomology computations should now generally be a bit faster.
</p>
<p>
<span class="underline"><code>_sig_on/_sig_off</code></span>
</p>
<p>
Concerning sig_on_count: It is really a nice feature that the balance of _sig_on/_sig_off is automatically tested since sage-4.7.1! I went through the sources, and indeed it seems that there can be situations where an error is raised between _sig_on/_sig_off (which must be avoided).
</p>
<p>
<span class="underline">The other doctest failures</span>
</p>
<ul><li>The test <code>pGroupCohomology.factory.CohomologyRingFactory.get_public_db</code> verifies that by default the public cohomology data base is in <code>SAGE_DATA</code>. Apparently that is not the case for John's Sage installations, and thus I'll remove that test.
</li></ul><ul><li>There is one test where non-filter-regular but algebraically independent parameters are not found in the degrees that are expected according to the doc tests. That is because algebraically <em>dependent</em> parameters can be found with a smaller degree sum. Hence, the completion test of Peter Symonds is used, and the program does not bother to try and find the smallest possible independent parameters. So, that test has to change.
</li></ul><p>
I am now preparing an update of the package and test it against sage-4.7.1.rc2. Until that's done, the ticket should be "needs work".
</p>
TicketSimonKingThu, 21 Jul 2011 10:50:08 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:40
https://trac.sagemath.org/ticket/9894#comment:40
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
For the record: One failure was due to a change in the <code>pivots()</code> method of Sage's matrices: They used to return a list, but apparently now it is a tuple. I took care of it.
</p>
<p>
The package is updated, so <code>sage -f http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.1.spkg</code> should now give a better result...
</p>
TicketSimonKingThu, 21 Jul 2011 10:53:02 GMTstatus, work_issues changed
https://trac.sagemath.org/ticket/9894#comment:41
https://trac.sagemath.org/ticket/9894#comment:41
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
changed from <em>fix doc tests</em> to <em>fix documentation</em>
</li>
</ul>
<p>
It turns out that the documentation does not build fine. So, the reviewing should be stalled until that's fixed as well.
</p>
TicketSimonKingThu, 21 Jul 2011 12:35:11 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/9894#comment:42
https://trac.sagemath.org/ticket/9894#comment:42
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>fix documentation</em> deleted
</li>
</ul>
<p>
I am now running the test suite, but I think it should be ready for review now.
</p>
<p>
It turns out that the trouble that I had with building the documentation can hardly be avoided:
</p>
<ul><li>If one has Cython code then Python can not determine the argspec.
</li><li>Hence, sage.misc.sageinspect.sage_getargspec tries to parse the argspec by reading the source file.
</li><li>Here, the sources are in an spkg, and thus sage_getargspec can not read the sources.
</li><li>By consequence, the argument list can not be figured out.
</li></ul><p>
Since I define the arguments in the doc string, it is fine though, and it can't be changed anyway.
</p>
TicketSimonKingThu, 21 Jul 2011 13:10:14 GMT
https://trac.sagemath.org/ticket/9894#comment:43
https://trac.sagemath.org/ticket/9894#comment:43
<p>
On my machine, all tests pass. The package is updated, so, feel free to do
</p>
<pre class="wiki">sage -f http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.1.spkg
</pre><p>
now. Also I have updated the <a class="ext-link" href="http://sage.math.washington.edu/home/SimonKing/Cohomology/"><span class="icon"></span>documentation</a>
</p>
TicketjhpalmieriTue, 02 Aug 2011 16:54:03 GMT
https://trac.sagemath.org/ticket/9894#comment:44
https://trac.sagemath.org/ticket/9894#comment:44
<p>
On the two OpenSolaris machines I have access to (David Kirkby's machine hawk, and the skynet machine fulvia), I'm getting one doctest failure:
</p>
<pre class="wiki">File "/export/home/palmieri/.sage/temp/hawk/619/dir_0/file_14.py", line 8:
sage: if sys.byteorder == 'little':
print hash(M) == Integer(7606091044269354279) # indirect doctest
else:
print hash(M) == Integer(1060097699) # indirect doctest
Expected:
True
Got:
False
</pre><p>
Otherwise, all tests pass on various platforms.
</p>
TicketSimonKingSun, 05 Feb 2012 18:21:43 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/9894#comment:45
https://trac.sagemath.org/ticket/9894#comment:45
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>make it work with the latest Sage version; perhaps 2.1.2</em>
</li>
</ul>
<p>
It turns out that the package does not work with the latest sage version: It fails to install, since apparently "singular" is undefined in one method, and the new version of Cython complains if stuff is not defined. I think this is going to be 2.1.2, also with some improvements in the underlying meataxe wrapper.
</p>
TicketSimonKingMon, 06 Feb 2012 07:22:08 GMT
https://trac.sagemath.org/ticket/9894#comment:46
https://trac.sagemath.org/ticket/9894#comment:46
<p>
In fact, there are several reasons for this spkg to fail in the current Sage version. The first is the new Cython version, as explained above.
</p>
<p>
The second is the new Singular version: I see a many errors of the form
</p>
<pre class="wiki">// ** int division with `/`: use `div` instead in line >> sage3687[1,tmp_i]=sage3687[1,tmp_i]**(COHO5dvNew[tmp_i]/COHO5dvOld[tmp_i]); <<
</pre><p>
raised by Singular.
</p>
<p>
The third is signal handling: Most doctest failures just complain about the sig_on/sig_off count (they are supposed to come in pairs, but apparently I sometimes forgot to insert sig_off in the correct place. Thus, it seems that the doctest framework did not count sig_on/sig_off yet, when I last tested the cohomology spkg.
</p>
TicketSimonKingThu, 09 Feb 2012 20:40:11 GMTstatus, description, summary changed; work_issues deleted
https://trac.sagemath.org/ticket/9894#comment:47
https://trac.sagemath.org/ticket/9894#comment:47
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>make it work with the latest Sage version; perhaps 2.1.2</em> deleted
</li>
<li><strong>description</strong>
modified (<a href="/ticket/9894?action=diff&version=47">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Group cohomology spkg, version 2.1.1</em> to <em>Group cohomology spkg, version 2.1.2</em>
</li>
</ul>
<p>
I have created a new version 2.1.2, available as stated in the ticket description.
</p>
<p>
There were three independent problems:
</p>
<ul><li>Singular upgrade: Some commands have changed, and so I had to rewrite some parts of my code
</li><li>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.
</li><li>Coercion and category framework: Some recent changes in <a class="closed ticket" href="https://trac.sagemath.org/ticket/9138" title="defect: Categories for all rings (closed: fixed)">#9138</a> or <a class="closed ticket" href="https://trac.sagemath.org/ticket/11900" title="defect: Serious regression caused by #9138 (closed: fixed)">#11900</a> 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.
</li></ul><p>
For me, the spkg test suite works. I didn't test on t2 or related machines, though.
</p>
<p>
Anyway, ready for review again!
</p>
TicketjhpalmieriTue, 20 Mar 2012 21:37:41 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:48
https://trac.sagemath.org/ticket/9894#comment:48
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
With sage-5.0.beta8-gcc, testing seems to hang on sage.math:
</p>
<pre class="wiki">
Successfully installed p_group_cohomology-2.1.2
Running the test suite for p_group_cohomology-2.1.2...
Testing the package pGroupCohomology...
Will use 9 parallel processes
pGroupCohomology.dickson has no doctest
pGroupCohomology.dickson.DICKSON.__cmp__ passes in 5.80 s
pGroupCohomology.dickson.DICKSON.__call__ passes in 5.79 s
pGroupCohomology.dickson.DICKSON.__init__ passes in 5.89 s
pGroupCohomology.dickson.DICKSON.V passes in 5.92 s
pGroupCohomology.dickson.DICKSON passes in 6.71 s
</pre><p>
At this point it didn't do anything for half an hour, so I killed it.
</p>
<p>
On an OS X 10.7 box, same Sage release, I got one doctest failure:
</p>
<pre class="wiki">There were doctest failures:
pGroupCohomology.cohomology.COHO:
sage -t -optional -long "/Users/palmieri/.sage/temp/jpalmieri538.math.washington.edu/74551/dir_0/file_25.py"
**********************************************************************
File "/Users/palmieri/.sage/temp/jpalmieri538.math.washington.edu/74551/dir_0/file_25.py", line 104:
sage: H = CohomologyRing(8,3, from_scratch=True)
Expected:
Computing from scratch
Group data are rooted at ...
Initialize cohomology ring of D8
Computing data for Small Group number 3 of order 8
> export action matrices
Inserting SmallGroup(2,1) as a subgroup
Inserting SmallGroup(4,2) as a subgroup
Computing Dickson invariants in elementary abelian subgroup of rank 2
Got:
Computing from scratch
Group data are rooted at /Users/palmieri/.sage/temp/jpalmieri538.math.washington.edu/6162/tmp_0/
Initialize cohomology ring of D8
Computing data for Small Group number 3 of order 8
> export action matrices
Inserting SmallGroup(2,1) as a subgroup
Inserting SmallGroup(4,2) as a subgroup
The state of this cohomology ring is expected to be provided at /Users/palmieri/.sage/temp/jpalmieri538.math.washington.edu/6162/tmp_0/4gp2/dat/State.sobj
Computing Dickson invariants in elementary abelian subgroup of rank 2
</pre><p>
This one looks pretty innocuous to me...
</p>
<p>
I'm going to run doctests on OpenSolaris soon.
</p>
TicketjhpalmieriWed, 21 Mar 2012 02:56:25 GMT
https://trac.sagemath.org/ticket/9894#comment:49
https://trac.sagemath.org/ticket/9894#comment:49
<p>
A number of failures on OpenSolaris. Here is a <a class="ext-link" href="http://boxen.math.washington.edu/home/palmieri/misc/p_group_cohomology-2.1.2.log"><span class="icon"></span>log file</a>.
</p>
TicketSimonKingWed, 21 Mar 2012 15:23:59 GMT
https://trac.sagemath.org/ticket/9894#comment:50
https://trac.sagemath.org/ticket/9894#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:49" title="Comment 49">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
A number of failures on OpenSolaris. Here is a <a class="ext-link" href="http://boxen.math.washington.edu/home/palmieri/misc/p_group_cohomology-2.1.2.log"><span class="icon"></span>log file</a>.
</p>
</blockquote>
<p>
It seems that <em>all</em> tests fail, since there is a very basic problem:
</p>
<pre class="wiki">ValueError: Can not create a symbolic link to the public database. Please remove /export/home/palmieri/.sage/pGroupCohomology/db/64gp158/
</pre><p>
Why can the symbolic link not be created? Is that an openSolaris problem?
</p>
<p>
The rationale for introducing symbolic links was as follows:
</p>
<ul><li>The package comes with a data base, that is installed into <code>SAGE_DATA/pGroupCohomology</code>. The package may be installed by root. But even in that case, it should be possible for <em>all</em> users to read from the database, and to extend partial computations found in the data base.
</li><li>While reading from the data base should not be a problem, extending partial computations IS a problem, if the user has no writing permission in <code>SAGE_DATA</code>.
</li><li>However, the user has writing permission in his/her home directory, in particular in DOT_SAGE. So, the basic idea is to put all new data there (in a sub-folder), but get existing data from <code>SAGE_DATA</code>.
</li><li>It would be a wast of storage space to actually <em>copy</em> the data from <code>SAGE_DATA</code> into <code>DOT_SAGE</code>. Therefore I only create links in <code>DOT_SAGE</code> that point to data in <code>SAGE_DATA</code>.
</li><li>Hard links are problematic, because it may happen that <code>DOT_SAGE</code> and <code>SAGE_DATA</code> belong to different partitions, but hard links have to stay in one partition. That restriction does not apply to symbolic links.
</li></ul><p>
So, that is why I work with symbolic links. And when I tried on T2 (which is now not available), it did work. Do you know a reason why it fails on your i386-pc-solaris2.11?
</p>
<p>
Since the error message suggests to remove something from <code>/export/home/palmieri/.sage/pGroupCohomology/db/</code>, could you perhaps try to empty that folder, and repeat the tests?
</p>
TicketSimonKingWed, 21 Mar 2012 15:38:29 GMT
https://trac.sagemath.org/ticket/9894#comment:51
https://trac.sagemath.org/ticket/9894#comment:51
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:48" title="Comment 48">jhpalmieri</a>:
</p>
<blockquote class="citation">
<blockquote>
<p>
Inserting <a class="missing wiki">SmallGroup?</a>(4,2) as a subgroup
</p>
<blockquote>
<p>
The state of this cohomology ring is expected to be provided at /Users/palmieri/.sage/temp/jpalmieri538.math.washington.edu/6162/tmp_0/4gp2/dat/State.sobj
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
Hm. That message sounds like data have been moved accross directories.
</p>
<p>
Anyway. I just see that I get a couple of failures on sage-5.0.beta8, built with the gcc spkg from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12369" title="task: Add a gcc package (closed: fixed)">#12369</a>. In some cases, problems with symbolic links are mentioned, or with files that can't be opened. Not good.
</p>
<p>
The good news is that I don't need to build Sage on <code>OpenSolaris</code> in order to replicated the trouble with symbolic links...
</p>
TicketjhpalmieriWed, 21 Mar 2012 21:00:24 GMT
https://trac.sagemath.org/ticket/9894#comment:52
https://trac.sagemath.org/ticket/9894#comment:52
<p>
On OpenSolaris, I deleted the ./sage/pGroupCohomology directory and reran self-tests. I got just a few failures: see <a class="ext-link" href="http://sage.math.washington.edu/home/palmieri/misc/p_group_cohomology-2.1.2-new.log"><span class="icon"></span>the log file</a>. I may be misreading it, but these look like optional doctests failing.
</p>
TicketSimonKingThu, 22 Mar 2012 13:58:34 GMT
https://trac.sagemath.org/ticket/9894#comment:53
https://trac.sagemath.org/ticket/9894#comment:53
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:52" title="Comment 52">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
On OpenSolaris, I deleted the ./sage/pGroupCohomology directory and reran self-tests. I got just a few failures: see <a class="ext-link" href="http://sage.math.washington.edu/home/palmieri/misc/p_group_cohomology-2.1.2-new.log"><span class="icon"></span>the log file</a>. I may be misreading it, but these look like optional doctests failing.
</p>
</blockquote>
<p>
All but one error comes from a test that requires internet connection and tests whether the package can read download data from some repository on sage.math - and now I wonder: Isn't sage.math down at the moment?
</p>
<p>
I have just tried myself, but it failed:
</p>
<pre class="wiki">sage: from pGroupCohomology import CohomologyRing
sage: H=CohomologyRing.web_db('8gp3')
---------------------------------------------------------------------------
ReadError Traceback (most recent call last)
...
ReadError: file could not be opened successfully
</pre><p>
Indeed, the problem is on the side of sage.math, and also it doesn't help to change to boxen.math. Namely, Sage is supposed to get a g-zipped tar file out of the data base, but what it receives is an html page saying that the requested page can not be found on the server. I will ask on sage-devel what happened.
</p>
<p>
One test is about the hash of matrices. The original aim was to test against a specific value, but perhaps that was a bad idea. After all, the specific value depends on whether the machine is big or little endian, and whether it is 32 or 64 bit. So, we have four possible values.
</p>
<p>
I think the natural solution is to not test against a specific value, but against the construction of the hash.
</p>
TicketSimonKingThu, 22 Mar 2012 16:13:09 GMTowner deleted
https://trac.sagemath.org/ticket/9894#comment:54
https://trac.sagemath.org/ticket/9894#comment:54
<ul>
<li><strong>owner</strong>
changed from <em>SimonKing</em> to <em>(none)</em>
</li>
</ul>
<p>
For the record: William said that the data base at sage.math.washington.edu/home/lmfdb is lost.
</p>
<p>
I hope I find some backup files, either in my home directory on sage.math, or in Jena.
</p>
TicketSimonKingTue, 27 Mar 2012 13:28:37 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:55
https://trac.sagemath.org/ticket/9894#comment:55
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I have updated the spkg (at the old location).
</p>
<p>
Changes: I modified the hash function of my <code>MeatAxe</code> matrix wrapper. Before, the hash was based on the triple given by the modulus of the finite field, the dimensions of the matrix, and the contents of the memory block describing the matrix. Now, it is <em>only</em> based on the memory block describing the matrix.
</p>
<p>
Rationale:
</p>
<ul><li>In our applications, the field is fixed, and so it does not add useful information to the hash.
</li><li>The size of the block of memory describing the matrix gives some information about the dimensions of the matrix, such that including the <em>exact</em> dimensions is not so important.
</li></ul><p>
Also it is faster in that way:
</p>
<pre class="wiki">sage: from pGroupCohomology.mtx import MTX
sage: M = MTX(5, [[randint(0,4) for _ in range(15)] for __ in range(15)])
sage: M.set_immutable()
sage: %timeit n = hash(M)
# With the new version
625 loops, best of 3: 750 ns per loop
# With the old version
625 loops, best of 3: 1.61 µs per loop
</pre><p>
The doc test for the <code>__hash__</code> method should now be machine independent. In order to provide an indirect test, I added a method that returns a string that corresponds to the block of memory describing the matrix.
</p>
<p>
On my computer, all tests pass. Concerning the doctests marked "optional - internet": Apparently they are run by the test suite, and they pass for me as well - even though the group cohomology data base in the Sage cluster is not available anymore. Fortunately, for the single purpose of testing my package, I stored one cohomology ring at sage.math.washington.edu/home/SimonKing/Cohomology/ - and that's enough for the tests to work.
</p>
<p>
Back to "needs review", then!
</p>
TicketjhpalmieriTue, 27 Mar 2012 22:28:18 GMT
https://trac.sagemath.org/ticket/9894#comment:56
https://trac.sagemath.org/ticket/9894#comment:56
<p>
A few questions:
</p>
<ul><li>Is it possible (and easy) to build the documentation locally? If so, it would be nice to implement that in spkg-install, using the environment variable <code>SAGE_SPKG_INSTALL_DOCS</code> (see <a class="closed ticket" href="https://trac.sagemath.org/ticket/10823" title="enhancement: environment variable SAGE_SPKG_INSTALL_DOCS to build and install spkg docs (closed: fixed)">#10823</a>).
</li></ul><ul><li>Also, can you provide the code for producing an on-line database, in case people want to host their own? Can people then set a variable to point to a different web site?
</li></ul><ul><li>I think a better way to disable parallel building is <code>export MAKE="$MAKE -j 1"</code>. Appending the <code>-j 1</code> at the end should override any earlier <code>-j</code> flags. But this would require testing. I also think that since you call <code>make</code> instead of <code>$MAKE</code>, maybe this is irrelevant anyway? This is all pretty minor, since it works as is.
</li></ul><p>
On sage.math and on an OS X Lion box (running the version of Sage from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12369" title="task: Add a gcc package (closed: fixed)">#12369</a>), all tests passed. On OpenSolaris, I'm getting a few doctest failures. Several are due to the internet tests, and this machine seems to have a very slow internet connection, so I'm not going to worry about that. The remaining failure:
</p>
<pre class="wiki">pGroupCohomology.mtx.MTX.__hash__:
sage -t -optional -long "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py"
**********************************************************************
File "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py", line 8:
sage: if sys.byteorder == 'little':
print hash(M) == Integer(7606091044269354279) # indirect doctest
else:
print hash(M) == Integer(1060097699) # indirect doctest
Expected:
True
Got:
False
**********************************************************************
</pre><p>
Any ideas about this one?
</p>
TicketSimonKingWed, 28 Mar 2012 00:47:46 GMT
https://trac.sagemath.org/ticket/9894#comment:57
https://trac.sagemath.org/ticket/9894#comment:57
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:56" title="Comment 56">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
A few questions:
</p>
<ul><li>Is it possible (and easy) to build the documentation locally? If so, it would be nice to implement that in spkg-install, using the environment variable <code>SAGE_SPKG_INSTALL_DOCS</code> (see <a class="closed ticket" href="https://trac.sagemath.org/ticket/10823" title="enhancement: environment variable SAGE_SPKG_INSTALL_DOCS to build and install spkg docs (closed: fixed)">#10823</a>).
</li></ul></blockquote>
<p>
Currently, it is not possible.
</p>
<p>
For creating the docs, I am using a script that is derived from the script that builds the Sage documentation. It would, of course, be possible to include the script in the spkg
</p>
<p>
However, that would not be enough. The docs should provide the argument list of each method. In order to determine the argspec of Cython methods, it is needed to be able to read the source code (see sage.misc.sageinspect). This is of course a problem for code that is outside the Sage library. My solution: I patched sage.misc.sageinspect, such that it would find the unpacked source of the spkg locally on my computer. But other users wouldn't have the unpacked spkg lying around.
</p>
<p>
Hm. I am just thinking: If the documentation is created <em>during installation</em>, then one <em>does</em> have the unpacked spkg. Still, I wouldn't like to patch sage.misc.sageinspect for that purpose. But perhaps the documentation builder script could hook into sage.misc.sageinspect.sage_getargspec?
</p>
<p>
Anyway, it would not be a straight forward solution.
</p>
<blockquote class="citation">
<ul><li>Also, can you provide the code for producing an on-line database, in case people want to host their own?
</li></ul></blockquote>
<p>
There is no ready-made method for that purpose. What one needs to do:
</p>
<ul><li>Compute the cohomology (by default, the result is stored on disk). Make sure that the computation is "from_scratch" (there is an option of that name).
</li><li>In case of a p-group, the data are for a single cohomology ring are distributed into many different files in a directory. Create a gzipped tar of that directory (for each group separately, I mean). This tar file is then put into the data base.
</li><li>In case of groups that are not of prime power order, the cohomology ring is stored in a single file, and it should be this file that is put into the data base.
</li></ul><p>
Do you think the following syntax (to be implemented) would be a nice addition?
</p>
<pre class="wiki">sage: H = CohomologyRing(G, to_database="/path/to/database_folder")
sage: H.make() # would compute the ring and create an entry in the database_folder
</pre><blockquote class="citation">
<p>
Can people then set a variable to point to a different web site?
</p>
</blockquote>
<p>
Yes! See the method <code>CohomologyRing.set_web_db(...)</code>.
</p>
<blockquote class="citation">
<ul><li>I think a better way to disable parallel building is <code>export MAKE="$MAKE -j 1"</code>. Appending the <code>-j 1</code> at the end should override any earlier <code>-j</code> flags. But this would require testing. I also think that since you call <code>make</code> instead of <code>$MAKE</code>, maybe this is irrelevant anyway?
</li></ul></blockquote>
<p>
Do I? I thought I had changed it into <code>$MAKE</code>. At least, I had the intention at some point.
</p>
<blockquote class="citation">
<p>
pGroupCohomology.mtx.MTX.<span class="underline">hash</span>:
sage -t -optional -long "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py"
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
File "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py", line 8:
</strong></p>
<blockquote>
<p>
sage: if sys.byteorder == 'little':
</p>
<blockquote>
<p>
print hash(M) == Integer(7606091044269354279) # indirect doctest
</p>
</blockquote>
<p>
else:
</p>
<blockquote>
<p>
print hash(M) == Integer(1060097699) # indirect doctest
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
That's the <em>old</em> version of the test. Yesterday, I posted an update of the spkg, which contains a different (machine independent) test for the hash. Could you reforce installation, making sure you get the current version?
</p>
TicketjhpalmieriWed, 28 Mar 2012 04:26:39 GMT
https://trac.sagemath.org/ticket/9894#comment:58
https://trac.sagemath.org/ticket/9894#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:57" title="Comment 57">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:56" title="Comment 56">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
A few questions:
</p>
<ul><li>Is it possible (and easy) to build the documentation locally? If so, it would be nice to implement that in spkg-install, using the environment variable <code>SAGE_SPKG_INSTALL_DOCS</code> (see <a class="closed ticket" href="https://trac.sagemath.org/ticket/10823" title="enhancement: environment variable SAGE_SPKG_INSTALL_DOCS to build and install spkg docs (closed: fixed)">#10823</a>).
</li></ul></blockquote>
<p>
Currently, it is not possible.
</p>
</blockquote>
<p>
Perhaps for a future version you might consider it, depending on how much work it would be. A simple short-term solution would be to just include html docs in the spkg; they shouldn't add too much to the size. (Maybe a top-level directory <code>docs</code>, not under revision control.)
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Also, can you provide the code for producing an on-line database, in case people want to host their own?
</li></ul></blockquote>
</blockquote>
<blockquote class="citation">
<p>
Do you think the following syntax (to be implemented) would be a nice addition?
</p>
<pre class="wiki">sage: H = CohomologyRing(G, to_database="/path/to/database_folder")
sage: H.make() # would compute the ring and create an entry in the database_folder
</pre></blockquote>
<p>
Yes, that sounds good. Maybe also a list somewhere of which specific calculations would make a good database.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>I think a better way to disable parallel building is <code>export MAKE="$MAKE -j 1"</code>. Appending the <code>-j 1</code> at the end should override any earlier <code>-j</code> flags. But this would require testing. I also think that since you call <code>make</code> instead of <code>$MAKE</code>, maybe this is irrelevant anyway?
</li></ul></blockquote>
<p>
Do I? I thought I had changed it into <code>$MAKE</code>. At least, I had the intention at some point.
</p>
</blockquote>
<p>
The spkg-install file says, for example
</p>
<pre class="wiki">MAKE=make; export MAKE;
cd src
make
</pre><blockquote class="citation">
<blockquote class="citation">
<p>
pGroupCohomology.mtx.MTX.<span class="underline">hash</span>:
sage -t -optional -long "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py"
<strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong></strong><strong>
File "/export/home/palmieri/.sage/temp/hawk/17706/dir_0/file_14.py", line 8:
</strong></p>
<blockquote>
<p>
sage: if sys.byteorder == 'little':
</p>
<blockquote>
<p>
print hash(M) == Integer(7606091044269354279) # indirect doctest
</p>
</blockquote>
<p>
else:
</p>
<blockquote>
<p>
print hash(M) == Integer(1060097699) # indirect doctest
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
That's the <em>old</em> version of the test. Yesterday, I posted an update of the spkg, which contains a different (machine independent) test for the hash. Could you reforce installation, making sure you get the current version?
</p>
</blockquote>
<p>
You're right, I don't know how that happened. Anyway, all tests passed this time, including the internet ones.
</p>
<p>
I'm going to browse the source a bit more, but it all looks very good right now.
</p>
TicketSimonKingWed, 28 Mar 2012 05:41:05 GMT
https://trac.sagemath.org/ticket/9894#comment:59
https://trac.sagemath.org/ticket/9894#comment:59
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:58" title="Comment 58">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Perhaps for a future version you might consider it, depending on how much work it would be. A simple short-term solution would be to just include html docs in the spkg; they shouldn't add too much to the size. (Maybe a top-level directory <code>docs</code>, not under revision control.)
</p>
</blockquote>
<p>
It is 3.4MB.
</p>
<blockquote class="citation">
<p>
Yes, that sounds good. Maybe also a list somewhere of which specific calculations would make a good database.
</p>
</blockquote>
<p>
Or perhaps another syntax would be better. My previous suggestion was: "Declare during creation of a specific cohomology ring that it should go into a data base." But the computation of one ring typically involves the computation of rings for several subgroups (elementary abelian, Sylow, ...), and it would be reasonable to have them ALL in the data base.
</p>
<p>
Therefore, I think it would be better to have a <em>global</em> switch, for example
</p>
<pre class="wiki">sage: CohomologyRing.create_database("/path/to/data_base")
</pre><p>
with the effect that all subsequent cohomology computations will work as they usually do, but would additionally write the tar files into the given data base folder.
</p>
<blockquote class="citation">
<p>
The spkg-install file says, for example
</p>
<pre class="wiki">MAKE=make; export MAKE;
</pre></blockquote>
<p>
Oops. I will try what happens with parallel make - after all, the comment "Building in parallel is bad" is probably there for a reason (but I can't recall).
</p>
<blockquote class="citation">
<p>
I'm going to browse the source a bit more, but it all looks very good right now.
</p>
</blockquote>
<p>
OK. Would it be OK to postpone the doc and data base additon, or would you strongly prefer to have it in 2.1.2 already?
</p>
TicketSimonKingWed, 28 Mar 2012 14:10:56 GMT
https://trac.sagemath.org/ticket/9894#comment:60
https://trac.sagemath.org/ticket/9894#comment:60
<p>
One question: If <code>$MAKE</code> is <code>make -jN</code>, how can one find the number N?
</p>
TicketSimonKingWed, 28 Mar 2012 16:06:03 GMT
https://trac.sagemath.org/ticket/9894#comment:61
https://trac.sagemath.org/ticket/9894#comment:61
<p>
I have updated th spkg on the old location (hence, if you download it again, make sure that you have the correct version, because sometimes wget is cached!).
</p>
<p>
Changes:
</p>
<ul><li>If <code>SAGE_SPKG_INSTALL_DOCS=yes</code> then the documentation is locally created, and copyied into SAGE_ROOT/local/share/doc/p_group_cohomology/html.
</li><li>I tried to allow parallel make, but <code>MeatAxe</code> would fail. I do not have the energy to fix it right now. At least, I am now reverting the old setting of <code>MAKE</code> as soon as <code>MeatAxe</code> is built, but apparently for installing the Cython modules it doesn't help.
</li></ul><p>
Ready for review, anyway.
</p>
TicketSimonKingWed, 28 Mar 2012 16:14:49 GMT
https://trac.sagemath.org/ticket/9894#comment:62
https://trac.sagemath.org/ticket/9894#comment:62
<p>
PS: Concerning docs, you will find that certain files such as builder.py, sageinspect.py and sage_autodoc.py are modified versions of the corresponding files from Sage. They are not doctested here. The difference to the files from Sage is that the modified versions are able to find the source files of my cohomology spkg.
</p>
TicketjhpalmieriThu, 29 Mar 2012 18:38:43 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/9894#comment:63
https://trac.sagemath.org/ticket/9894#comment:63
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Karl-Dieter Crisman</em> to <em>Karl-Dieter Crisman, John Palmieri</em>
</li>
</ul>
<p>
This looks great! Positive review. I appreciate having the documentation locally, too.
</p>
<p>
At least one thing which ought to be easy to implement in a future version: <code>additive_order</code> for elements: <code>a.additive_order()</code> should be either <code>1</code> (if <code>a==0</code>) or <code>p</code> (the characteristic of the ground field. If you ever construct cohomology rings over non-fields, you could leave it unimplemented in that case.
</p>
<p>
I found this a little strange:
</p>
<pre class="wiki">sage: H0 = CohomologyRing(8,3)
sage: (H0.2 * H0.3).is_zero()
True
sage: (H0.2 * H0.3) == 0
False
</pre><p>
Maybe comparisons or <code>__eq__</code> need to be implemented, too.
</p>
TicketSimonKingThu, 29 Mar 2012 19:06:49 GMT
https://trac.sagemath.org/ticket/9894#comment:64
https://trac.sagemath.org/ticket/9894#comment:64
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:63" title="Comment 63">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
This looks great! Positive review.
</p>
</blockquote>
<p>
Thank you very much! Finally, the old version (broken with recent Sage) can be replaced!
</p>
<blockquote class="citation">
<p>
sage: (H0.2 * H0.3).is_zero()
True
sage: (H0.2 * H0.3) == 0
False
Maybe comparisons or <code>__eq__</code> need to be implemented, too.
</p>
</blockquote>
<p>
I think that the answers are consistent, for the following reasons:
</p>
<ul><li><code>H0.2*H0.3</code> is zero in the cohomology <em>group</em> H<sup>2</sup>(D8). As elements of that group, the product is zero, hence "is_zero()" returns True.
</li><li>However, even though the product vanishes and thus represents a relation of the cohomology ring, it still is a cocycle of degree 2. Thus, it is not equal to <code>H0.zero_element()</code>, which is a cocycle of degree 2. Hence, the comparison with the zero of the cohomology <em>ring</em> returns False.
</li></ul>
TicketSimonKingThu, 29 Mar 2012 21:28:03 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:65
https://trac.sagemath.org/ticket/9894#comment:65
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
Dear John,
</p>
<p>
I am sorry for being late, but I have one question: Would you allow one last-minute change?
</p>
<p>
Namely, with the package you just reviewed, the computation of the cohomology ring of the Sylow 2-subgroup of some double cover of Suzuki group 8 (this is group number 836 of order 128), the completion test à la Peter Symonds is very time consuming - the problem was in the computation of a small subset of generators over which the ring is finite-dimensional. I found a way to speed it up. Also, I'd like to add protocol output to the method that computes it (which also means I will have to change the expected protocol output in some doc tests).
</p>
<p>
I think these changes are minor, but helpful. If you say that you would try to install it and run the test suite again, then I would update the spkg a bit later. I would also accept to postpone that change for a later spkg version.
</p>
<p>
What do you prefer?
</p>
TicketjhpalmieriThu, 29 Mar 2012 21:51:03 GMT
https://trac.sagemath.org/ticket/9894#comment:66
https://trac.sagemath.org/ticket/9894#comment:66
<p>
Hi Simon,
</p>
<p>
I can run the test suite in the next day or two, once you update the spkg. So it's fine with me if you want to update it. If you do, could you also post a diff here, so I can see the changes? (Just <code>hg export tip > ...</code> and post the resulting patch file.)
</p>
TicketSimonKingThu, 29 Mar 2012 23:55:57 GMTattachment set
https://trac.sagemath.org/ticket/9894
https://trac.sagemath.org/ticket/9894
<ul>
<li><strong>attachment</strong>
set to <em>cohomology-pkg.diff</em>
</li>
</ul>
<p>
Diff of the latest changes in the spkg. For reviewing only
</p>
TicketSimonKingFri, 30 Mar 2012 00:14:39 GMT
https://trac.sagemath.org/ticket/9894#comment:67
https://trac.sagemath.org/ticket/9894#comment:67
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9894#comment:66" title="Comment 66">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I can run the test suite in the next day or two, once you update the spkg. So it's fine with me if you want to update it. If you do, could you also post a diff here, so I can see the changes?
</p>
</blockquote>
<p>
I have updated my spkg (old location) and have attache a diff with respect to the version that you have reviewed earlier.
</p>
<p>
Here are the changes:
</p>
<ul><li>The <code>useSlimgb</code> resp. <code>useStd</code> options had been used only in one location: There were several places where the default 'groebner' method of Singular would be used, regardless of the options. That has changed in the last revision.
</li><li>The protocol output of some methods (e.g., <code>dependent_parameters()</code>) are now providing protocol output <em>before</em> a potentially time-consuming Gröbner basis computation is started. Background: When I computed the cohomology of <code>SmallGroup(128,836)</code> with the previous revision, I thought that it hangs in the computation of the Gröbner basis of the relation ideal - but in fact the problem was in <code>dependent_parameters()</code>, which has not been clear from the protocoll output.
</li><li>In Symonds' criterion, parameters in degree one won't contribute to the degree in which the criterion detects completeness. Hence, adding all degree one generators to a given list of parameters will not change the degree bound -- but it may make the computation easier, because killing degree one generators greatly reduces the difficulty of Gröbner basis computations. Thus my changes in <code>dependent_parameters</code>
</li></ul>
TicketjhpalmieriFri, 30 Mar 2012 21:01:57 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:68
https://trac.sagemath.org/ticket/9894#comment:68
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
TicketjhpalmieriFri, 30 Mar 2012 21:02:31 GMTstatus changed
https://trac.sagemath.org/ticket/9894#comment:69
https://trac.sagemath.org/ticket/9894#comment:69
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Okay, still looks good.
</p>
TicketjdemeyerMon, 02 Apr 2012 11:38:26 GMTdescription changed
https://trac.sagemath.org/ticket/9894#comment:70
https://trac.sagemath.org/ticket/9894#comment:70
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/9894?action=diff&version=70">diff</a>)
</li>
</ul>
TicketschillyMon, 02 Apr 2012 11:57:12 GMT
https://trac.sagemath.org/ticket/9894#comment:71
https://trac.sagemath.org/ticket/9894#comment:71
<p>
spkg updated on the server + mirros.
</p>
TicketjdemeyerMon, 02 Apr 2012 21:10:06 GMTstatus changed; resolution set
https://trac.sagemath.org/ticket/9894#comment:72
https://trac.sagemath.org/ticket/9894#comment:72
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
Ticket