On 19.07.20 00:34, rrbold wrote:
Hi Christian and John,
Christian, your first sentence puts the finger on the correct spot:
I take the position that a graded abelian group is not an abelian
group. It is a sequence of abelian groups.
For any category C, one can consider Gr(C), the category of graded
objects in C, which has objects the functions from your grading
monoid, frequently the natural numbers, to Obj(C), and morphisms the
sequences of morphisms of C. There is no need for C to have a direct
sum or categorical coproduct which will allow you to combine these
into a single object in C, in order to consider such things.
Mathematically, consider singular n-cochains on a space X with values
in a module M. These are functions from the set Top(\Delta_n,X) of
continuous maps \Delta_n --> X into the module M, i.e., elements of
Set(Top(\Delta_n,X),M), given the natural module structure inherited
from M. If n \neq k, then there is no sensible relation between
the zero function Top(\Delta_n, X) --> M and the zero function
Top(\Delta_k,X). Only inductive generalization or habit would
suggest that sending all the elements of Top(\Delta_n,X) to zero \in
M means you should also do this to all the elements in the entirely
different set Top(Delta_k,X).
The fact that this causes difficulties in the programming is a hint
that we make an error in thinking of graded objects as their direct
sum. I think it is better to take the mathematically sensible
solution, and accept that there is a different 0 in each degree of a
graded module.
Hi Bob,
I think treating graded objects as sequences/disjoint unions of their
homogeneous components is a perfectly legitimate point of view, and Sage
could and should strive to make it possible to follow that philosophy in
user code. I also stand by my suggestion that this is already *almost*
possible, using the A[n] in place of A. Essentially you would just need
to redefine the Sq function or whatever you use to generate a Steenrod
operation:
sage: def Sq(*R):
....: A = SteenrodAlgebra(2)
....: a = A.Sq(*R)
....: return A[a.degree()].monomial(R)
....:
sage: Sq(1,1)+Sq(4)
milnor[(1, 1)] + milnor[(4,)]
This way, your Sq(R) live in different parents depending on their
degree, and the association element -> parent -> degree allows to
recover the degree from all elements.
When you try to add those Sq(R) from different degrees, you also get the
expected errors:
sage: Sq(1,1)+Sq(5)
---------------------------------------------------------------------------
TypeError Traceback (most recent
call last)
...
TypeError: unsupported operand parent(s) for +: 'Vector space
spanned by (Sq(1,1), Sq(4)) over Finite Field of size 2' and 'Vector
space spanned by (Sq(2,1), Sq(5)) over Finite Field of size 2'
Using that approach in practice would need some (minor) fixes to Sage,
but these are not nearly as radical as suggesting multiple zeroes in the
SteenrodAlgebra itself:
TODOs:
1) missing multiplication A[n] * A[m] -> A[n+m]
2) A[n].zero().degree() should be n
3) the printing of A[n] and of its elements is a bit unexpected: I
would support changing this to the usual printing with respect to the
basis that is chosen in the usual SteenrodAlgebra
4) missing cast from A to A[n]
Best,
Christian
PS: the different approaches to gradings seem to mirror the distinction
between classical and quantum physics. The enlightened quantum
perspective just acepts as a fact of nature that elements of a graded
module usually exist in a superposition of pure states, i.e. that they
might have no fixed degree (for inhomogeneous elements) or every degree
(the zero element). I find this mostly just as good in my programming.
In practical terms this just shifts the responsibilities a bit: the
result of a computation (e.g. multiplication) will not in general know
its degree; therefore the piece of user code that triggered the
multiplication must keep a memory of the grading that it's workign at.
PPS: among illuminated minds, no posting is complete without a hint of
self-contradiction, so I feel obliged to disclose that in my Steenrod
Tcl library I actually made a similar choice about the representation of
matrices as lists of lists of entries, and here my choice was clearly
wrong and has given me a lot of headachesever since: the point is that I
cannot recover the M from a matrix of dimensions 0xM or Mx0 ...
Best,
Bob (rrb - old)
On Saturday, July 18, 2020 at 5:57:21 PM UTC-4, Christian Nassau wrote:
Hi Sverre,
I don't think it's a good idea to have different zeroes in an
algebraic structure that is also categorized as an abelian group,
unless you take the point that a "graded abelian group" should not
be an "abelian group".
But let me also point out that something similar to what you want
already exists: you can take a homogeneous component of the
Steenrod algebra and look at its zero:
sage: A=SteenrodAlgebra(2)
sage: A[18]
Vector space spanned by (Sq(0,1,0,1), Sq(3,0,0,1), Sq(1,1,2),
Sq(4,0,2), Sq(2,3,1), Sq(5,2,1), Sq(8,1,1), Sq(11,0,1),
Sq(0,6), Sq(3,5), Sq(6,4), Sq(9,3), Sq(12,2), Sq(15,1),
Sq(18)) over Finite Field of size 2
sage: A[18].zero() == A.zero()
True
sage: A[18].zero() == A[17].zero()
False
This suggests that "A[18].zero().degree()" could give 18, and the
fact that it currently gives a ValueError might be considered a bug.
Best,
Christian
On 18.07.20 23:35, Sverre Lunøe-Nielsen wrote:
Hi,
Thank you for your comments so far. I feel I need to expand some
more on the issue of zero elements which is the central thing for
the problem we are adressing.
It is mathematically equivalent to think of a graded k-algebra A
as either
1) a direct sum A = \bigosum_i A_i, together with a graded
k-linear map from
the graded tensor product A\tensor_k A --> A,
or
2) a sequence of k-vectorspaces {A_i}_i, together with a set of
structure maps
\{ A_i \tensor_R A_j --> A_{i+j} \}_{i,j}.
(In both cases the structure maps should satisfy usual algebraic
conditions.)
Similar for graded A-modules.
The implementation of the SteenrodAlgebra package takes the
approach of 1), and never speaks about the zero element z_i \in
A_i for any i. Rather, they are all identified in A via the
canonical injection A_i --> A. It is tradition not to worry too
much about this since you can "figure it out" if you have to, and
know how you ended up with a zero.
However, it is arguably better, specially when writing software,
to avoid this simplifaction since it leads to a corner case which
has to be dealt with over and over again. A great share of the
bugs I have corrected in the package I have been editing have
been caused by the wrongful assumption that all elements have an
integer degree. Having not to worry about this would make our
code cleaner, and so will all future code building on it.
I was being rather vague about making proposals for change in the
SteenrodAlgebra package in my last post, so to be clear let me
propose a specific change and invite anyone to share their
opinion on it:
Change SteenrodAlgebra such that _all_ homogeneous elements have
a well defined degree. For the user, this means in particular
that when constructing the zero element, its degree must be given:
sage: A = SteenrodAlgebra(p=2)
sage: z = A.zero(degree=2)
sage: Sq(1)*Sq(1) == z
True
sage: Sq(2)*Sq(1)*Sq(1) == z
False
This involves adding the degree as internal data to zero
elements, and change the behaviour of degree() such that it
raises an exception only for inhomogeneous elements.
I hope I have clearified that I am not seeking a strange new
definition of graded module or algebra, and that I am merely
wanting to discuss the possibility of changing the implementation
of SteenrodAlgebra.
E.g. are there perhaps unwanted software ramifications that our
proposal would bring about?
Regards,
Sverre
On Saturday, July 18, 2020 at 11:31:43 PM UTC+2, John H Palmieri
wrote:
On Saturday, July 18, 2020 at 2:31:01 AM UTC-7, Sverre
Lunøe-Nielsen wrote:
Dear list,
I have been involved in preparing a package by M.
Catanzaro and R. Bruner lately, which implements finitely
presented modules over the mod `p` Steenrod algebra.
We have encountered a conflict regarding how to present
graded objects, and I am writing to the list to get other
people's opinion on how to proceed on this matter.
Briefly, the issue is that the Steenrod algebra allows
inhomogeneous elements and our graded modules do not.
Thus, the Steenrod algebra has a single zero element with
no well defined degree, while our modules could
potentially have one zero element for each degree.
My wish is to allow degreewise zero elements in our
graded modules, so that x.degree() would return an
integer for every element x. But because the unique zero
in the Steenrod algebra has no well defined degree, I am
forced to let degree() treat all zero elements in our
modules the same way and return ``None``.
A more precise description of the issue is found in the
Sphinx note below.
My questions to the list are: Has similar issues been
discussed and/or resolved before? And more specificly:
What acceptable changes could be made to the Steenrod
algebra package to achieve what I want?
Regards,
Sverre Lunøe-Nielsen
.. NOTE::
Our implementation treats a graded module as the disjoint
union, rather than a
direct sum, of vectorspaces of homogeneous elements.
Elements are therefore
always homogeneous, which also implies that sums between
elements of different
degrees are not allowed. This also means that acting by
an inhomogeneous
element of the Steenrod algebra makes no sense.
In this setting there is no single zero element, but
rather a zero for every
degree. It follows that, in theory, all elements,
including the zero elements,
have a well defined degree.
This way of representing a graded object differs from the
way the graded
Steenrod algebra is represented by
:class:`sage.algebras.steenrod` where inhomogeneous
elements are allowed and there is only a single zero
element. Consequently,
this zero element has no well defined degree.
Thus, because of the module action, we are forced to
follow the same convention
when it comes to the degree of zero elements in a
module: The method
:meth:`sage.modules.finitely_presented_over_the_steenrod_algebra.module.fp_element.FP_Element.degree'
returns the value ``None`` for zero elements.
An example which highlights this problem is the following::
sage: F = FPA_Module([0], SteenrodAlgebra(p=2)) #
The free module on a single generator in degree 0.
sage: g = F.generator(0)
sage: x1 = Sq(1)*g
sage: x2 = Sq(1)*x1
Clearly, the code implementing the module action has all
the information it needs
to conclude that the element ``x2`` is the zero element
in the second degree.
However, because of the module action, we cannot
distinguish it from the element::
sage: x2_ = (Sq(1) * Sq(1))*g
The latter is equal to the action of the zero element of
the Steenrod
algebra on `g`, but since the zero element has no degree
in the Steenrod algebra,
the module class cannot deduce what degree the zero
element `x2_` should belong
to.
In my experience, algebraic topologists often think of graded
objects as disjoint unions, and you can often get away with
this, but really they're not — they're direct sums. I think
you should use Sage's categories framework, graded modules
with basis or whatever, to set these up. In any case where
the degree matters, you should first test whether an element
is zero (in which case it won't have a degree) and then
perhaps whether it is homogeneous. If not, you can raise an
error (to keep someone from multiplying a module element by
Sq(1) + Sq(2), for example). If it is homogeneous, you can
proceed the way you want.
--
John
--
You received this message because you are subscribed to the
Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to sage-...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/816f808f-0c55-4d3c-946e-b3c2d6cbe56fo%40googlegroups.com
<https://groups.google.com/d/msgid/sage-devel/816f808f-0c55-4d3c-946e-b3c2d6cbe56fo%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-devel+unsubscr...@googlegroups.com
<mailto:sage-devel+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/75adcfa9-e7cc-4613-abb8-7bf85a28f016o%40googlegroups.com
<https://groups.google.com/d/msgid/sage-devel/75adcfa9-e7cc-4613-abb8-7bf85a28f016o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/82cc29b7-3d0c-2d63-5786-d719f0841ae9%40nullhomotopie.de.
