Sage: Ticket #10052: Improve the implementation of the Steenrod algebra
https://trac.sagemath.org/ticket/10052
<p>
The attached patch does several things:
</p>
<ul><li>it moves the Steenrod algebra code to a subdirectory of algebras. For one thing, there are already 4 files, and for another, I hope that more will be added: several people are working on related projects.
</li></ul><ul><li>it reimplements the Steenrod algebra using <code>CombinatorialFreeModule</code>, which provides a number of conveniences: scalar multiplication is already defined, as are tensor products, etc. Then for example the antipode or the coproduct can be defined just on basis elements, and the linear extension to all elements is handled automatically.
</li></ul><ul><li>it implements another way of computing products, using admissible sequences and the Adem relations. This provides a good way of checking for bugs: with two completely different algorithms for computing products, one can compute the same product two ways and compare answers.
</li></ul><ul><li>it implements sub-Hopf algebras of the Steenrod algebra. These were classified 35 years ago, and for some applications people want to use sub-Hopf algebras rather than the whole thing.
</li></ul><ul><li>the <code>TestSuite</code> has been improved: all components now pass, whereas before, we had some failures. From the <em>old</em> steenrod_algebra.py:
<pre class="wiki"> sage: TestSuite(A).run() # todo: fix category inheritance for elements of A
Failure in _test_category:
...
------------------------------------------------------------
The following tests failed: _test_category
Failure in _test_elements
The following tests failed: _test_elements
</pre>From the new one:
<pre class="wiki"> sage: TestSuite(SteenrodAlgebra()).run()
sage: TestSuite(SteenrodAlgebra(profile=[4,3,2,2,1])).run()
sage: TestSuite(SteenrodAlgebra(basis='adem')).run()
sage: TestSuite(SteenrodAlgebra(basis='wall')).run()
sage: TestSuite(SteenrodAlgebra(basis='arnonc')).run() # long time
sage: TestSuite(SteenrodAlgebra(basis='woody')).run() # long time
sage: A3 = SteenrodAlgebra(3)
sage: A3.category()
Category of graded hopf algebras with basis over Finite Field of size 3
sage: TestSuite(A3).run()
sage: TestSuite(SteenrodAlgebra(basis='adem', p=3)).run()
sage: TestSuite(SteenrodAlgebra(basis='pst_llex', p=7)).run() # long time
sage: TestSuite(SteenrodAlgebra(basis='comm_deg', p=5)).run() # long time
</pre>Not only are there no failures, but there are many more executions of the suite. This yields some repetition, but the method <code>an_element</code> varies depending on the values of <code>basis</code> and <code>p</code>, so there are also new tests run with each execution.
</li></ul><p>
Unfortunately, since the patch moves files around, it is large. It also trivially affects a few doctests in sageinspect, which means that it requires a patch to sagenb.
</p>
<h2 id="Apply">Apply</h2>
<ol><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-steenrod.rebased.patch" title="Attachment 'trac_10052-steenrod.rebased.patch' in Ticket #10052">trac_10052-steenrod.rebased.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-steenrod.rebased.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-sagenb.patch" title="Attachment 'trac_10052-sagenb.patch' in Ticket #10052">trac_10052-sagenb.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-sagenb.patch" title="Download"></a>
</li></ol>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/10052
Trac 1.1.6jhpalmieriFri, 01 Oct 2010 22:43:35 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-sagenb.patch</em>
</li>
</ul>
<p>
patch for sagenb repo
</p>
TicketjhpalmieriFri, 01 Oct 2010 22:44:42 GMTstatus, description changed; keywords set
https://trac.sagemath.org/ticket/10052#comment:1
https://trac.sagemath.org/ticket/10052#comment:1
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>keywords</strong>
<em>steenrod</em> <em>notebook</em> added
</li>
<li><strong>description</strong>
modified (<a href="/ticket/10052?action=diff&version=1">diff</a>)
</li>
</ul>
TicketjvkerschWed, 06 Oct 2010 03:48:00 GMTcc set
https://trac.sagemath.org/ticket/10052#comment:2
https://trac.sagemath.org/ticket/10052#comment:2
<ul>
<li><strong>cc</strong>
<em>jvkersch</em> added
</li>
</ul>
TicketnilesSun, 10 Oct 2010 19:47:30 GMTcc, status changed
https://trac.sagemath.org/ticket/10052#comment:3
https://trac.sagemath.org/ticket/10052#comment:3
<ul>
<li><strong>cc</strong>
<em>niles</em> added
</li>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
I seem to be missing something; here's what I get after applying <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-steenrod.patch" title="Attachment 'trac_10052-steenrod.patch' in Ticket #10052">trac_10052-steenrod.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-steenrod.patch" title="Download"></a> to sage 4.6.alpha2:
</p>
<pre class="wiki">sage: SteenrodAlgebra(5)
Traceback (most recent call last)
...
TypeError: __init__() got an unexpected keyword argument 'scalar_mult'
</pre><p>
Are there other patches I should have applied?
</p>
<p>
Moreover, the notebook patch doesn't apply at all -- I don't know where the directory <code></code>sagenb<code></code> is, let alone the file <code></code>sageinspect.py<code></code>. Any ideas what I could be missing?
</p>
TicketjhpalmieriMon, 11 Oct 2010 15:57:20 GMTstatus, description changed
https://trac.sagemath.org/ticket/10052#comment:4
https://trac.sagemath.org/ticket/10052#comment:4
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/10052?action=diff&version=4">diff</a>)
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:3" title="Comment 3">niles</a>:
</p>
<blockquote class="citation">
<p>
I seem to be missing something; here's what I get after applying <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-steenrod.patch" title="Attachment 'trac_10052-steenrod.patch' in Ticket #10052">trac_10052-steenrod.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-steenrod.patch" title="Download"></a> to sage 4.6.alpha2:
</p>
</blockquote>
<p>
Oops, sorry, my fault. This patch depends on the one at <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>, so please apply that first.
</p>
<blockquote class="citation">
<p>
Moreover, the notebook patch doesn't apply at all -- I don't know where the directory <code></code>sagenb<code></code> is, let alone the file <code></code>sageinspect.py<code></code>. Any ideas what I could be missing?
</p>
</blockquote>
<p>
As of Sage 4.6.alpha2, this is a little complicated, but with 4.6.alpha3, you can do <code>hg_sagenb.import_patch("...path_to_patch_file...")</code> from within Sage to apply it. (The sagenb patch on this ticket is pretty minor, just to make some doctests pass: there are some doctests in the patched file which return the path to one of the files which implements the Steenrod algebra, and since the files got moved around, the doctests fail without the sagenb patch.)
</p>
TicketjhpalmieriMon, 11 Oct 2010 15:57:56 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.patch</em>
</li>
</ul>
<p>
depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>
</p>
TicketjhpalmieriMon, 11 Oct 2010 15:58:57 GMT
https://trac.sagemath.org/ticket/10052#comment:5
https://trac.sagemath.org/ticket/10052#comment:5
<p>
(I attached the same patch so I could add the note about it depending on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>.)
</p>
TicketjhpalmieriMon, 11 Oct 2010 19:56:32 GMT
https://trac.sagemath.org/ticket/10052#comment:6
https://trac.sagemath.org/ticket/10052#comment:6
<p>
Also re the sagenb patch: the patched file "sagenb/misc/sageinspect.py" is a modified version of "sage/misc/sageinspect.py", present so that sagenb can function as a standalone project, independent of the rest of Sage. So any changes to the sage file necessitate corresponding changes to the sagenb file. So without actually applying the sagenb patch, you should be able to verify that the patch looks okay. (Eventually, of course, you should apply it and run "make ptestlong" to run the sagenb tests as well as the sage ones...)
</p>
TicketjhpalmieriWed, 03 Nov 2010 23:56:19 GMT
https://trac.sagemath.org/ticket/10052#comment:7
https://trac.sagemath.org/ticket/10052#comment:7
<p>
I just attached a new version of the patch. This should be essentially equivalent, except that the new version records the fact that various files have been renamed, and so in theory the change history for the files (like the old algebras/steenrod_algebra.py, now renamed to algebras/steenrod/steenrod_algebra.py) should remain intact. Two files (steenrod_milnor_multiplication.py and steenrod_milnor_multiplication_odd.py) were combined, and this was recorded as the first being renamed and the second removed.
</p>
TicketjhpalmieriFri, 19 Nov 2010 23:50:01 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.v2.patch</em>
</li>
</ul>
<p>
version 2. depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>
</p>
TicketnilesWed, 01 Dec 2010 14:03:59 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/10052#comment:8
https://trac.sagemath.org/ticket/10052#comment:8
<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>minor docstring issues, problems with sub-Hopf algebras</em>
</li>
</ul>
<p>
Hi John,
</p>
<p>
I've finally had a chance to look over this patch. The functionality is really great, and I think the documentation is fantastic! I noticed a couple of minor issues, and then some larger problems related to sub-Hopf algebras; here goes:
</p>
<ul><li>I really like the <a href="http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.verbose">sage.misc.misc.verbose</a> module; I just wanted to remind you about it for <code>steenrod_algebra_bases.steenrod_basis_error_check</code>. For a lengthy demonstration, try
<pre class="wiki">sage: set_verbose(1)
sage: EllipticCurve('11a1').sha().an_padic(5)
</pre></li></ul><ul><li>Two minor doctest failures; the first occurs because -1 = 10 in GF(11), and Sage prints 10; the second occurs because the way dicts are printed may vary -- to fix that one I suggest testing that the output of the function is equal to the given dict.
<pre class="wiki">sage -t sage/algebras/steenrod/steenrod_algebra.py
**********************************************************************
File "/Applications/sage/devel/sage-main/sage/algebras/steenrod/steenrod_algebra.py", line 1340:
sage: SteenrodAlgebra(p=11).Q(0,2).coproduct()
Expected:
1 # Q_0 Q_2 + Q_0 # Q_2 + Q_0 Q_2 # 1 - Q_2 # Q_0
Got:
1 # Q_0 Q_2 + Q_0 # Q_2 + Q_0 Q_2 # 1 + 10*Q_2 # Q_0
**********************************************************************
File "/Applications/sage/devel/sage-main/sage/algebras/steenrod/steenrod_algebra.py", line 3080:
sage: d._basis_dictionary('arnonc')
Expected:
{(7,): 1, (2, 5): 1, (4, 2, 1): 1, (4, 3): 1}
Got:
{(7,): 1, (2, 5): 1, (4, 3): 1, (4, 2, 1): 1}
**********************************************************************
</pre></li></ul><ul><li>The docstring for <code>.gens()</code>, last sentence before EXAMPLES::, should mention the <code>Q_n</code>'s too, since both <code>.gen()</code> and <code>.ngens()</code> mention them.
</li></ul><ul><li><code>.gen()</code> fails for pst basis: The following returns an error:
<pre class="wiki">sage: SteenrodAlgebra(p=5, profile=[[2,1], [2,2,2]], basis='pst').gen(2)
</pre></li></ul><ul><li>In the docstring for <code>.milnor_multiplication_odd()</code>, could you give a reference for Monks Maple package?
</li></ul><ul><li>I think the description of <code>.homogeneous_component()</code> is a little misleading: I expected it to return the vector space of elements of homogeneous degree <code>n</code>, and thus was surprised to get different answers depending on which basis I used. Of course this was clarified by the description of the algorithm, but maybe the description could be clarified.
<pre class="wiki">sage: G = SteenrodAlgebra(p=5, profile=[[2,1], [2,2,2]], basis='pst')
sage: H = SteenrodAlgebra(p=5, profile=[[2,1], [2,2,2]])
sage: [H[n].dimension() - G[n].dimension() for n in range(100)]
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 1, 4, 2, 0, 0, 0, 0, 0, 1, 4, 3, 0, 0, 0, 0, 0, 1, 4, 3, 0, 0, 0, 0, 0, 1, 4, 3, 0, 0, 0, 0, 0, 1, 4, 3, 0, 0, 0, 0, 0, 2, 6, 4, 0]
</pre></li></ul><ul><li><code>.an_element()</code> sometimes returns an element which may not be in sub algebra:
<pre class="wiki">sage: H = SteenrodAlgebra(profile=[1,2,1,1])
sage: H.an_element()
Sq(2,1)
sage: H.an_element() in H
False
</pre></li></ul><ul><li>For sub algebras, <code>.Q()</code> should throw an error for elements not in the sub algebra (as with <code>.P()</code>):
<pre class="wiki">sage: H = SteenrodAlgebra(p=5, profile=[[2,1], [2,2,2]])
sage: H.Q(4) in H
False
sage: H.Q(4)
Q_4
sage: H.Q(4).parent() is H
True
</pre></li></ul><ul><li>There is a problem with <code>.antipode()</code> for sub algebras:
<pre class="wiki">sage: A = SteenrodAlgebra(2)
sage: A.Sq(2,1).antipode()
Sq(2,1)
sage: H = SteenrodAlgebra(profile=[2,2,1])
sage: H.Sq(2,1).antipode()
Traceback (most recent call last):
...
ValueError: Element does not lie in this Steenrod algebra
</pre></li></ul><ul><li>problems with coercion:
<pre class="wiki">sage: H.Sq(2,1) == A.Sq(2,1)
True
sage: H.Sq(2,1).coproduct() == A.Sq(2,1).coproduct()
False
sage: A.Sq(2,1).coproduct().parent() is A.tensor_square()
sage: A.tensor_square()(H.Sq(2,1).coproduct())
Traceback (most recent call last):
...
NotImplementedError:
</pre></li></ul><ul><li>printing of elements: to be consistent with the rest of sage, perhaps multiplication should print as <code>*</code>:
<pre class="wiki">sage: A = SteenrodAlgebra(13)
sage: A.an_element()
12 Q_1 Q_3 P(2,1)
sage: PolynomialRing(GF(13),'x',5).random_element()
5*x1^2 + x0*x2 + x2*x4 - x4^2 - 5*x2
</pre></li></ul><ul><li>it's too bad that elements do not print in a way that can be typed directly into Sage (I think I read somewhere that this should be done whenever possible). This could be fixed by allowing the user to declare Sq, P, Q as global functions (e.g. P = A.P) -- perhaps by using the .inject_variables() function -- and changing the Q_i to print as Q(i). Of course this would work for only one Steenrod algebra (or sub algebra) at a time, but would still be useful for basic testing/playing.
</li></ul>
TicketjhpalmieriThu, 02 Dec 2010 06:05:59 GMT
https://trac.sagemath.org/ticket/10052#comment:9
https://trac.sagemath.org/ticket/10052#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:8" title="Comment 8">niles</a>:
</p>
<p>
Thanks a lot for all the work and careful comments. Among other things, you've found some bugs in the code, which I think I've fixed. I'm attaching a new patch, but I'm leaving it as "needs work" while I keep looking at it to see if I can see other issues which need fixing.
</p>
<blockquote class="citation">
<ul><li>I really like the <a href="http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.verbose">sage.misc.misc.verbose</a> module; I just wanted to remind you about it for <code>steenrod_algebra_bases.steenrod_basis_error_check</code>.
</li></ul></blockquote>
<p>
That's a good idea; I've implemented it.
</p>
<blockquote class="citation">
<ul><li>Two minor doctest failures; the first occurs because -1 = 10 in GF(11), and Sage prints 10; the second occurs because the way dicts are printed may vary
</li></ul></blockquote>
<p>
I don't see these, on either sage.math or on OS X. What platform are you using?
</p>
<blockquote class="citation">
<ul><li>The docstring for <code>.gens()</code>, last sentence before EXAMPLES::, should mention the <code>Q_n</code>'s too, since both <code>.gen()</code> and <code>.ngens()</code> mention them.
</li></ul></blockquote>
<p>
Fixed.
</p>
<blockquote class="citation">
<ul><li><code>.gen()</code> fails for pst basis:
</li></ul></blockquote>
<p>
Fixed, plus a new doctest for it.
</p>
<blockquote class="citation">
<ul><li>In the docstring for <code>.milnor_multiplication_odd()</code>, could you give a reference for Monks Maple package?
</li></ul></blockquote>
<p>
Done, and also in milnor_multiplication().
</p>
<blockquote class="citation">
<ul><li>I think the description of <code>.homogeneous_component()</code> is a little misleading: I expected it to return the vector space of elements of homogeneous degree <code>n</code>, and thus was surprised to get different answers depending on which basis I used.
</li></ul></blockquote>
<p>
Me, too. It should give vector spaces of the same dimension regardless of the basis. This turned out to be a bug in the basis algorithm (with profile functions, I was accidentally setting a variable n inside a loop "for n in range(...)", so n was being reset in the middle of the loop, causing it to end too early). This is fixed, and I've added some tests for it, both in homogeneous_component and in steenrod_basis_error_check.
</p>
<blockquote class="citation">
<ul><li><code>.an_element()</code> sometimes returns an element which may not be in sub algebra:
</li></ul></blockquote>
<p>
Fixed. If the algebra has a profile function, return <code>1</code> if the algebra is just the base field, and otherwise return its first generator. The old behavior, returning some arbitrarily chosen element, is still there for the full Steenrod algebra.
</p>
<blockquote class="citation">
<ul><li>For sub algebras, <code>.Q()</code> should throw an error for elements not in the sub algebra (as with <code>.P()</code>):
</li></ul></blockquote>
<p>
Fixed, along with a new doctest.
</p>
<blockquote class="citation">
<ul><li>There is a problem with <code>.antipode()</code> for sub algebras:
</li></ul></blockquote>
<p>
I don't see this one, although it may have been fixed by one of the other fixes. I've added a doctest for it anyway.
</p>
<blockquote class="citation">
<ul><li>problems with coercion:
</li></ul></blockquote>
<pre class="wiki">sage: H.Sq(2,1) == A.Sq(2,1)
True
sage: H.Sq(2,1).coproduct() == A.Sq(2,1).coproduct()
False
sage: A.Sq(2,1).coproduct().parent() is A.tensor_square()
sage: A.tensor_square()(H.Sq(2,1).coproduct())
Traceback (most recent call last):
...
NotImplementedError:
</pre><p>
I don't know how to fix this: it has to do with the implementation (or lack thereof) of tensor products. I don't think it's particular to the Steenrod algebra, so I'd like to have it dealt with on another ticket.
</p>
<blockquote class="citation">
<ul><li>printing of elements: to be consistent with the rest of sage, perhaps multiplication should print as <code>*</code>:
</li></ul></blockquote>
<p>
I understand what you're saying, but I think that printing this way is ugly. (This was one of the reasons for <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>.) If you really want, I can change it, but I'd rather not.
</p>
<blockquote class="citation">
<ul><li>it's too bad that elements do not print in a way that can be typed directly into Sage (I think I read somewhere that this should be done whenever possible). This could be fixed by allowing the user to declare Sq, P, Q as global functions (e.g. P = A.P) -- perhaps by using the .inject_variables() function -- and changing the Q_i to print as Q(i). Of course this would work for only one Steenrod algebra (or sub algebra) at a time, but would still be useful for basic testing/playing.
</li></ul></blockquote>
<p>
This is a very interesting idea, but I don't know how to do it right now. Can <code>inject_variables</code> be used to define functions, not just variables? I'll think about it, but I may want to defer it to a later ticket.
</p>
TicketnilesThu, 02 Dec 2010 16:07:35 GMTdescription changed
https://trac.sagemath.org/ticket/10052#comment:10
https://trac.sagemath.org/ticket/10052#comment:10
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10052?action=diff&version=10">diff</a>)
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:9" title="Comment 9">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:8" title="Comment 8">niles</a>:
</p>
<p>
Thanks a lot for all the work and careful comments. Among other things, you've found some bugs in the code, which I think I've fixed. I'm attaching a new patch, but I'm leaving it as "needs work" while I keep looking at it to see if I can see other issues which need fixing.
</p>
</blockquote>
<p>
Glad to help; I'll keep looking too. For now, some continued discussion of printing and <code>.inject_variables()</code> . . .
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Two minor doctest failures
</li></ul></blockquote>
<p>
I don't see these, on either sage.math or on OS X. What platform are you using?
</p>
</blockquote>
<p>
I'm using OS X, but Sage 4.5.2 for the first round of reviewing -- maybe recent changes have fixed these problems.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>problems with coercion:
</li></ul></blockquote>
<p>
I don't know how to fix this: it has to do with the implementation (or lack thereof) of tensor products. I don't think it's particular to the Steenrod algebra, so I'd like to have it dealt with on another ticket.
</p>
</blockquote>
<p>
That sounds reasonable -- I'll try to work out the issue and put up a ticket (unless you already know what the problem is).
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>printing of elements: to be consistent with the rest of sage, perhaps multiplication should print as <code>*</code>:
</li></ul></blockquote>
<p>
I understand what you're saying, but I think that printing this way is ugly. (This was one of the reasons for <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>.) If you really want, I can change it, but I'd rather not.
</p>
</blockquote>
<p>
Well, I'm not sure if this is a decision that should depend solely on my opinion or yours; my thinking is that we should opt for consistency over aesthetics unless there is a really good reason not to. Every other ring in Sage prints multiplication as <code>*</code> -- do you have a good reason to reverse that convention for the Steenrod algebra? (As you point out, this is related to the question of whether or not <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a> is a good idea -- something I'm not sure of yet.) In particular, printing <code>*</code> is consistent with the way Sage requires input to be typed (although note my further comments on that topic below).
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>it's too bad that elements do not print in a way that can be typed directly into Sage (I think I read somewhere that this should be done whenever possible).
</li></ul></blockquote>
</blockquote>
<p>
After some looking, I think what I was remembering is this section of the <a href="http://www.sagemath.org/doc/tutorial/interactive_shell.html#saving-and-loading-individual-objects">interactive shell tutorial</a>, which mentions this idea as a possible way for printing objects, but one which Sage does not enforce -- rather it suggests using un/pickling to store and retrieve objects. Nevertheless, I think printing as closely as possible to valid input is useful, especially for new users.
</p>
<blockquote class="citation">
<p>
Can <code>inject_variables</code> be used to define functions, not just variables? I'll think about it, but I may want to defer it to a later ticket.
</p>
</blockquote>
<p>
Fair enough; something like this does work for <a href="http://www.sagemath.org/doc/reference/sage/rings/polynomial/infinite_polynomial_element.html">infinite polynomial rings</a>:
</p>
<pre class="wiki">sage: R = InfinitePolynomialRing(ZZ,'t')
sage: R
Infinite polynomial ring in t over Integer Ring
sage: R.inject_variables()
Defining t
sage: R.gens()
(t_*,)
sage: t[2]
t_2
sage: t[3]
t_3
sage: t[2]*t[3] - 4*t[11] + 8
-4*t_11 + t_3*t_2 + 8
sage: t[2]*t[3] - 4*t[11] + 8 in R
True
</pre><p>
I think the way this is implemented is by defining a <code>__getitem__</code> method for the generator, but the same should work by defining a <code>__call__</code> method. (And I did notice, by the way, that the objects don't print in the same way that they have to be input.) For infinite polynomial rings, <code>.inject_variables()</code> is inherited from <code>sage.structure.category_object.CategoryObject</code>:
</p>
<pre class="wiki"> def inject_variables(self, scope=None, verbose=True):
"""
Inject the generators of self with their names into the
namespace of the Python code from which this function is
called. Thus, e.g., if the generators of self are labeled
'a', 'b', and 'c', then after calling this method the
variables a, b, and c in the current scope will be set
equal to the generators of self.
NOTE: If Foo is a constructor for a Sage object with generators, and
Foo is defined in Cython, then it would typically call
``inject_variables()`` on the object it creates. E.g.,
``PolynomialRing(QQ, 'y')`` does this so that the variable y is the
generator of the polynomial ring.
"""
vs = self.variable_names()
gs = self.gens()
if scope is None:
scope = globals()
if verbose:
print "Defining %s"%(', '.join(vs))
for v, g in zip(vs, gs):
scope[v] = g
</pre><p>
So if you want to use it, you would have to re-think what is returned by <code>.gens()</code>, especially in the case of finitely-generated sub algebras. Of course you could make a new definition of <code>.inject_variables()</code>, but it's not clear this is a good idea either . . . I think this is worth a little more thought, but shouldn't derail the rest of this ticket.
</p>
TicketjhpalmieriFri, 03 Dec 2010 23:48:01 GMTstatus changed
https://trac.sagemath.org/ticket/10052#comment:11
https://trac.sagemath.org/ticket/10052#comment:11
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:10" title="Comment 10">niles</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ul><li>problems with coercion:
</li></ul></blockquote>
<p>
I don't know how to fix this: it has to do with the implementation (or lack thereof) of tensor products. I don't think it's particular to the Steenrod algebra, so I'd like to have it dealt with on another ticket.
</p>
</blockquote>
<p>
That sounds reasonable -- I'll try to work out the issue and put up a ticket (unless you already know what the problem is).
</p>
</blockquote>
<p>
I don't know what the ticket is, although some of the sage-combinat people probably do.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ul><li>printing of elements: to be consistent with the rest of sage, perhaps multiplication should print as <code>*</code>:
</li></ul></blockquote>
<p>
I understand what you're saying, but I think that printing this way is ugly. (This was one of the reasons for <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>.) If you really want, I can change it, but I'd rather not.
</p>
</blockquote>
<p>
Well, I'm not sure if this is a decision that should depend solely on my opinion or yours; my thinking is that we should opt for consistency over aesthetics unless there is a really good reason not to. Every other ring in Sage prints multiplication as <code>*</code> -- do you have a good reason to reverse that convention for the Steenrod algebra?
</p>
</blockquote>
<p>
I would interpret this another way: you include a <code>*</code> when you need to in order to prevent ambiguity. In a situation where you can have polynomial generators called 'xy' and 'yx' (which would be terrible choices, but anyway), you have to include <code>*</code> so that you you can read <code>xy * yx</code> properly. So you need <code>*</code> in a polynomial algebra, or in any algebra in which the generators have user-specified names. But for the Steenrod algebra, there are no such possibilities of ambiguity, so you don't need the <code>*</code>.
</p>
<p>
That's my justification, anyway.
</p>
<p>
A different way to interpret it: symbols like "Q_<a class="missing report" title="report does not exist">{0}</a> Q_<a class="report" href="https://trac.sagemath.org/report/1">{1}</a> P(1,3,2)" could be viewed as atomic: they are basis elements for the Steenrod algebra. So it's reasonable to print them without asterisks. Then the question is whether to insist on a <code>*</code> between a scalar and a basis element, which I just think looks bad, although it is mostly the convention in Sage.
</p>
<p>
A third view: the existing implementation of the Steenrod algebra doesn't use <code>*</code>. I haven't heard any comment about this before, so I don't think it's confused anyone so far. So for consistency :), we should keep it as is.
</p>
<hr />
<p>
I'll keep thinking about the <code>inject_variables</code> issue, also. Meanwhile, I'm attaching a revised version of the v3 patch; compared to the last one, this just fixes some typos and cleans up the documentation a little. It also changes the file sage/categories/coalgebras_with_basis.py, to get rid of a warning when building the docs. This passes all tests on sage.math, and it passes selected tests on OS X and Solaris. (I haven't had time to run a full test suite on these other platforms, but tests pass on all files which I think should be affected.)
</p>
TicketjhpalmieriFri, 03 Dec 2010 23:48:35 GMT
https://trac.sagemath.org/ticket/10052#comment:12
https://trac.sagemath.org/ticket/10052#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:11" title="Comment 11">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I don't know what the ticket is, although some of the sage-combinat people probably do.
</p>
</blockquote>
<p>
Sorry, I meant to say "I don't know what the issue is..."
</p>
TicketjhpalmieriSat, 04 Dec 2010 16:43:50 GMT
https://trac.sagemath.org/ticket/10052#comment:13
https://trac.sagemath.org/ticket/10052#comment:13
<p>
For the buildbot:
</p>
<p>
apply trac_10052-steenrod.v3.patch, trac_10052-sagenb.patch
</p>
TicketnilesSat, 04 Dec 2010 19:55:47 GMT
https://trac.sagemath.org/ticket/10052#comment:14
https://trac.sagemath.org/ticket/10052#comment:14
<p>
For the buildbot:
</p>
<p>
Depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>
</p>
TicketnilesSat, 11 Dec 2010 17:21:22 GMTreviewer set; work_issues deleted
https://trac.sagemath.org/ticket/10052#comment:15
https://trac.sagemath.org/ticket/10052#comment:15
<ul>
<li><strong>reviewer</strong>
set to <em>Niles Johnson</em>
</li>
<li><strong>work_issues</strong>
<em>minor docstring issues, problems with sub-Hopf algebras</em> deleted
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:11" title="Comment 11">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I would interpret this another way: you include a <code>*</code> when you need to in order to prevent ambiguity. In a situation where you can have polynomial generators called 'xy' and 'yx' (which would be terrible choices, but anyway), you have to include <code>*</code> so that you you can read <code>xy * yx</code> properly. So you need <code>*</code> in a polynomial algebra, or in any algebra in which the generators have user-specified names. But for the Steenrod algebra, there are no such possibilities of ambiguity, so you don't need the <code>*</code>.
</p>
</blockquote>
<p>
ok, fair enough
</p>
<p>
I've started looking at this again, and I get two errors trying to apply the v3 patch (sage 4.6); here are the contents of the .rej file:
</p>
<pre class="wiki">--- coalgebras_with_basis.py
+++ coalgebras_with_basis.py
@@ -91,7 +91,7 @@
@lazy_attribute
def coproduct(self):
"""
- If :meth:`.coproduct_on_basis` is available, construct the
+ If :meth:`coproduct_on_basis` is available, construct the
coproduct morphism from ``self`` to ``self`` `\otimes`
``self`` by extending it by linearity
@@ -115,7 +115,7 @@
@lazy_attribute
def counit(self):
"""
- If :meth:`.counit_on_basis` is available, construct the
+ If :meth:`counit_on_basis` is available, construct the
counit morphism from ``self`` to ``self`` `\otimes`
``self`` by extending it by linearity
</pre><p>
I'll keep looking at the patch, since these won't affect the functionality.
</p>
TicketjhpalmieriSat, 11 Dec 2010 19:20:25 GMT
https://trac.sagemath.org/ticket/10052#comment:16
https://trac.sagemath.org/ticket/10052#comment:16
<p>
The patch bot can't seem to apply that patch either. I think I based this on 4.6.1.alpha2, so there must be some additional dependency. I'll try to track it down today.
</p>
TicketjhpalmieriSat, 11 Dec 2010 20:29:58 GMT
https://trac.sagemath.org/ticket/10052#comment:17
https://trac.sagemath.org/ticket/10052#comment:17
<p>
Depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/8589" title="enhancement: New feature : Hopf algebra structure on group algebras (closed: fixed)">#8589</a>.
</p>
<p>
(The second of these was merged into 4.6.1.alpha0.)
</p>
TicketjhpalmieriWed, 15 Dec 2010 18:40:22 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.delta2to3.patch</em>
</li>
</ul>
<p>
Diff between v2 and v3 (for reference only)
</p>
TicketjhpalmieriWed, 15 Dec 2010 18:41:25 GMT
https://trac.sagemath.org/ticket/10052#comment:18
https://trac.sagemath.org/ticket/10052#comment:18
<p>
Here is a slightly modified v3 patch, fixing a little documentation and (more importantly) a bug in the validity checking for profile functions, pointed out by Bob Bruner.
</p>
TicketjhpalmieriThu, 16 Dec 2010 21:46:57 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.v3.patch</em>
</li>
</ul>
<p>
version 3. depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>
</p>
TicketjhpalmieriThu, 16 Dec 2010 21:48:53 GMT
https://trac.sagemath.org/ticket/10052#comment:19
https://trac.sagemath.org/ticket/10052#comment:19
<p>
The "delta2to3" patch is now slightly out of date. If I have time, I'll fix this, but for now, the last line in
</p>
<pre class="wiki"> if truncation_type > 0:
k = k + [2]
else:
k = k + [1]
</pre><p>
(from <code>is_valid_profile</code> in steenrod_algebra_misc.py) has been changed:
</p>
<pre class="wiki"> if truncation_type > 0:
k = k + [2]
else:
k = k + [1]*len(profile[0])
</pre>
TicketnilesMon, 20 Dec 2010 18:36:12 GMTdescription changed
https://trac.sagemath.org/ticket/10052#comment:20
https://trac.sagemath.org/ticket/10052#comment:20
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10052?action=diff&version=20">diff</a>)
</li>
</ul>
<p>
For the buildbot:
</p>
<p>
Depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/8589" title="enhancement: New feature : Hopf algebra structure on group algebras (closed: fixed)">#8589</a>.
</p>
<p>
Apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-steenrod.v3.patch" title="Attachment 'trac_10052-steenrod.v3.patch' in Ticket #10052">trac_10052-steenrod.v3.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-steenrod.v3.patch" title="Download"></a>, <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/10052/trac_10052-sagenb.patch" title="Attachment 'trac_10052-sagenb.patch' in Ticket #10052">trac_10052-sagenb.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/10052/trac_10052-sagenb.patch" title="Download"></a>
</p>
<p>
(p.s. I haven't forgotten about this :)
</p>
TicketnilesMon, 20 Dec 2010 18:38:28 GMT
https://trac.sagemath.org/ticket/10052#comment:21
https://trac.sagemath.org/ticket/10052#comment:21
<p>
Apply trac_10052-steenrod.v3.patch, trac_10052-sagenb.patch
</p>
TicketnilesThu, 10 Mar 2011 18:54:20 GMTstatus changed
https://trac.sagemath.org/ticket/10052#comment:22
https://trac.sagemath.org/ticket/10052#comment:22
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I'm ready to give this a positive review, but now (Sage 4.6.2) I'm getting a failing doctest with <code>latex</code> on a coproduct (note the missing <code>1</code> at the end of the latex string):
</p>
<pre class="wiki">sage: A7 = SteenrodAlgebra(7)
sage: c = Sq(2).change_basis('adem').coproduct()
sage: c
1 # Sq^2 + Sq^1 # Sq^1 + Sq^2 # 1
sage: latex(c)
1 \otimes \text{Sq}^{2} + \text{Sq}^{1} \otimes \text{Sq}^{1} + \text{Sq}^{2} \otimes
</pre><p>
This is probably related to bugs in the code for tensor products of algebras, but I haven't been able to track down the precise problem.
</p>
TicketjhpalmieriFri, 11 Mar 2011 22:28:27 GMT
https://trac.sagemath.org/ticket/10052#comment:23
https://trac.sagemath.org/ticket/10052#comment:23
<p>
Thanks for keeping an eye on this. The latex/coproduct bug is because of <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>, not because of anything here. I think I know how to fix it.
</p>
<p>
Meanwhile, there may be a bug in profile functions for the odd primary Steenrod algebra, so give me a few days to check it out and fix it. (I'm leaving this as "needs work" until I get it straightened out.)
</p>
TicketjhpalmieriWed, 16 Mar 2011 20:30:26 GMTstatus changed
https://trac.sagemath.org/ticket/10052#comment:24
https://trac.sagemath.org/ticket/10052#comment:24
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
<a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a> has a positive review, and the most recent patch there fixes the coproduct bug. Meanwhile, there was a bug with profile functions. The new "v4" patch fixes it. I've also included a delta patch to help with reviewing. (The delta patch may not be completely accurate; I may have tinkered with some doctests for <code>normalize_profile</code> and those changes may not be recorded in the delta patch because I got lazy.)
</p>
<p>
Apply only trac_10052-steenrod.v4.patch.
</p>
<p>
Depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>.
</p>
TicketjhpalmieriWed, 16 Mar 2011 20:31:08 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.delta3to4.patch</em>
</li>
</ul>
<p>
Diff between v3 and v4 (for reference only)
</p>
TicketjhpalmieriWed, 16 Mar 2011 20:31:23 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.v4.patch</em>
</li>
</ul>
<p>
version 4. depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/9370" title="enhancement: customize printing of elements in CombinatorialFreeModules (closed: fixed)">#9370</a>
</p>
TicketnilesThu, 28 Apr 2011 13:45:09 GMT
https://trac.sagemath.org/ticket/10052#comment:25
https://trac.sagemath.org/ticket/10052#comment:25
<p>
Patchbot: apply trac_10052-steenrod.v4.patch
</p>
TicketnilesTue, 31 May 2011 07:29:20 GMTstatus changed
https://trac.sagemath.org/ticket/10052#comment:26
https://trac.sagemath.org/ticket/10052#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Ok, I've finally gotten back to looking at this. With the following, I'm giving this a positive review
</p>
<ul><li>The patchs apply cleanly to Sage 4.7, and pass all (long) tests for me.
</li></ul><ul><li>The documentation builds without warning, looks good
</li></ul><ul><li>Complete doctest coverage
</li></ul><ul><li>The previous issues I noticed (<a class="ticket" href="https://trac.sagemath.org/ticket/10052#comment:8" title="Comment 8">comment:8</a>) have all been addressed, as well as some others, and now I see no problems with the functionality
</li></ul><ul><li>The code is free from obvious inefficiencies (e.g. in memory management, error handling)
</li></ul><ul><li>In general, this is well-written, well-documented, and a substantial improvement!
</li></ul>
TicketjdemeyerWed, 08 Jun 2011 20:58:25 GMTstatus changed
https://trac.sagemath.org/ticket/10052#comment:27
https://trac.sagemath.org/ticket/10052#comment:27
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This needs to be rebased to sage-4.7.1.alpha2.
</p>
TicketjhpalmieriWed, 08 Jun 2011 23:00:10 GMTattachment set
https://trac.sagemath.org/ticket/10052
https://trac.sagemath.org/ticket/10052
<ul>
<li><strong>attachment</strong>
set to <em>trac_10052-steenrod.rebased.patch</em>
</li>
</ul>
<p>
rebased to 4.7.1.alpha2
</p>
TicketjhpalmieriWed, 08 Jun 2011 23:01:03 GMTstatus, description changed
https://trac.sagemath.org/ticket/10052#comment:28
https://trac.sagemath.org/ticket/10052#comment:28
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/10052?action=diff&version=28">diff</a>)
</li>
</ul>
TicketjdemeyerThu, 09 Jun 2011 11:56:08 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/10052#comment:29
https://trac.sagemath.org/ticket/10052#comment:29
<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>
<li><strong>merged</strong>
set to <em>sage-4.7.1.alpha3</em>
</li>
</ul>
Ticket