Hi John,
Your question is a good one, to look at the places where the notion that 0 has
no degree
causes extra effort. I have strong memories of having to go through minor but
annoying contortions to deal with this, both in sage and in MAGMA, for decades
now,
but don't have examples fresh in mind. That's why I haven't responded yet.
As a practical matter, implementing a full Gr(C) or Gr(category=C,index=N)
solution
would require far too much effort, as appealing as it is aesthetically.
I will try to see if I can retrieve some examples for you. Sverre may beat me
to it.
We had hoped, perhaps over-optimistically, that it might not be too hard to
assign
degrees to solve the problem Sverre described succinctly in his initial post:
if g is an
element of degree 0 and we make the assignment x = (Sq(1)*Sq(1))*g, the module
code has no way to recognize that x has degree 2, since the Steenrod algebra
code
does not view Sq(1)*Sq(1) as having degree 2.
This means that one has to resort to circumlocutions like
if x == 0 then A else B
when, mathematically and conceptually, it should be possible to simply say
B
Bob
________________________________________
From: sage-devel@googlegroups.com <sage-devel@googlegroups.com> on behalf of
John H Palmieri <jhpalmier...@gmail.com>
Sent: Sunday, July 19, 2020 3:04 PM
To: sage-devel
Subject: Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The
degree of zero elements
Hi Bob,
Mathematically, a classical example of a graded object is a polynomial ring,
and non-topologists often consider nonhomogeneous polynomials, for reasons that
are beyond me. But once you do that, it seems that you're forced to live in a
direct sum. Sage could have two different structures, although they would need
names: an indexed family of objects and a direct sum of objects. I don't really
want to start a fight over which deserves to be called "graded objects," though.
Let me go back to a question I asked Sverre: what happens in your code if you
allow nonhomogeneous elements? It may not be something you would ever want to
do, but maybe it would just work without breaking anything, then that's an easy
way around.
- John
On Sunday, July 19, 2020 at 2:25:38 AM UTC-7, 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.
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.
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/712aa5ef-4aac-49f9-9ac9-e80b7449b700o%40googlegroups.com<https://groups.google.com/d/msgid/sage-devel/712aa5ef-4aac-49f9-9ac9-e80b7449b700o%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/DM6PR11MB3755028956F43BD9959FF84DEA7A0%40DM6PR11MB3755.namprd11.prod.outlook.com.
