Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
John,
On Sunday, July 19, 2020 at 9:04:26 PM UTC+2 John H Palmieri wrote:
> 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.
Off the top of my head I couldn't say how much trouble it would cause. The
package is really focused on graded maps and homological algebra (free
resolutions, kernels, cokernels etc.) and this issue of the zeros has only
come up now when we have been finishing the documentation and tests.
So, I have never considered it seriously before, but I will and see if it
could be useful.
Thanks!
- Sverre
- 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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
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 on behalf of John H Palmieri 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 pr
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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
On Jul 18, 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)
The problem of thinking that graded Abelian groups and graded modules are not
abelian groups, and similarly graded Algebras are not Algebras, in the context
of Sage, is that the whole category framework is in place, and your classes
will not be able to use this. A parent defined as above cannot be a parent in
the category of graded modules. This means that you have to double whatever
code is already in place in the category framework and this should lead to
more programming errors than the ones that may be solved by having a zero on
each degree instead of checking for zero before using degree().
R.
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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
On 19.07.20 01:01, John H Palmieri wrote: 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? I don't think zero makes much sense here. The suggestion seems to be to have in Sage an A[n] that represents homotopy classes of maps from a fixed suspension of HF2 to HF2. If this is the goal then elements of A[n] should always have x.degree() = n, and we would also need a multiplication A[n] * A[m] -> A[n+m]. Currently that product map does not exist in Sage: sage: A=SteenrodAlgebra(2) sage: A[3].an_element() * A[4].an_element() --- TypeError Traceback (most recent call last) TypeError: unsupported operand parent(s) for *: 'Vector space spanned by (Sq(0,1), Sq(3)) over Finite Field of size 2' and 'Vector space spanned by (Sq(1,1), Sq(4)) over Finite Field of size 2' Also, a quick test suggests that the M[n] notation is not part of a general framework in Sage, and that degrees of inhomogeneous elements are handled somewhat liberally in other places. This might just reflect a "cultural" difference between topologists and combinatorialists, of course: sage: S=SymmetricFunctions(QQ) sage: S.an_element().degree() 2 sage: for x in S.an_element().monomials(): : print (x, x.degree()) : s[] 0 s[1] 1 s[2] 2 sage: S.zero().degree() 0 sage: S.graded_algebra() is S True -- 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/7d4b8529-56ff-d40b-da5d-99186f109ae0%40nullhomotopie.de.
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
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
Re: [sage-devel] Re: Graded modules over the Steenrod algebra: The degree of zero elements
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
