On Saturday, July 18, 2020 at 2:57:21 PM UTC-7, 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.
>
It could equally well give zero. Should A[18] remember that it's in degree
18, or should is just be an ungraded module?
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/02fe5764-4050-48ef-8b8d-3bb89a27914ao%40googlegroups.com.
