~$ docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --rm -it cnassau/yacop-sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 8.2, Release Date: 2018-05-05 │
│ Type "notebook()" for the browser-based notebook interface. │
│ Type "help()" for help. │
└────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│ Imported package Yacop (version 2.0) │
└────────────────────────────────────────────────────────────────────┘
sage: from yacop.modules.dickson import DicksonAlgebra
sage: D=DicksonAlgebra(2,3)
sage: D
Dickson algebra D(3) for prime 2
sage: for g in D.graded_basis(tmax=10):
....: print g, g.t, g.degree()
....:
d4 4 region(e = 0, s = 0, t = 4)
1 0 region(e = 0, s = 0, t = 0)
d4*d6 10 region(e = 0, s = 0, t = 10)
d6 6 region(e = 0, s = 0, t = 6)
d7 7 region(e = 0, s = 0, t = 7)
d4**2 8 region(e = 0, s = 0, t = 8)
sage: suspension(D,t=8)
suspension (8,0,0) of Dickson algebra D(3) for prime 2
sage: from yacop.modules.functors import truncation
sage: truncation(D,tmax=10)
truncation to region(-Infinity < t <= 10) of Dickson algebra D(3) for prime 2
sage: D.zero().degree()
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
...
ValueError: degree of zero is undefined
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/50bab31f-182c-448e-bf35-b1bac90a8a75o%40googlegroups.com.
sage: A=SteenrodAlgebra(2)This suggests that "A[18].zero().degree()" could give 18, and the fact that it currently gives a ValueError might be considered a bug.
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
--
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+...@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.
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.
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)This suggests that "A[18].zero().degree()" could give 18, and the fact that it currently gives a ValueError might be considered a bug.
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
To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.
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)This suggests that "A[18].zero().degree()" could give 18, and the fact that it currently gives a ValueError might be considered a bug.
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
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
To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.
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 theseinto 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]
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 ...
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@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.
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-...@googlegroups.com <sage-...@googlegroups.com> on behalf of John H Palmieri <jhpalm...@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,
- John
Best,
Christian
or
Similar for graded A-modules.
Regards,
Sverre
Regards,
Sverre Lunøe-Nielsen
--
John
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+...@googlegroups.com<mailto:sage-devel+...@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>.
Can you give a specific example of a computation in which you care about the degree where your zero element lives? Or where you can't just recover it from its component elements (if ab=0, then you have an element in degree = deg(a) + deg(b)). I'm struggling to understand this.
> 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.