Opened 6 years ago
Closed 6 years ago
#18350 closed task (duplicate)
Adams operator
Reported by:  elixyre  Owned by:  

Priority:  major  Milestone:  sageduplicate/invalid/wontfix 
Component:  categories  Keywords:  
Cc:  nthiery, virmaux, jhpalmieri, nborie, mshimo, tscrim, amypang, alauve  Merged in:  
Authors:  JeanBaptiste Priez  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/elixyre/ticket/18350 (Commits, GitHub, GitLab)  Commit:  fc8726a50725479d84aa9a07f55e28e1f879880a 
Dependencies:  Stopgaps: 
Description
Hello every one,
I offer to append a generic operator on Hopf algebra: the coproduct and the product iterate k times. (I assume that operation is called the Adams operation but... it seems to be totally something else in the sage Sym... so... I'm not sure about the name of this operation)
sage: h = SymmetricFunctions(QQ).h() sage: h[5].adams_operator(2) 2*h[3, 2] + 2*h[4, 1] + 2*h[5] sage: tensor([h,h]).module_morphism(on_basis=lambda c: h(c[0])*h(c[1]), codomain=h)(h[5].coproduct()) 2*h[3, 2] + 2*h[4, 1] + 2*h[5]
Cheers, JeanBaptiste
Change History (26)
comment:1 Changed 6 years ago by
 Branch set to u/elixyre/ticket/18350
 Commit set to a685ad1c5acbb5dc1451e06809ce74955d54d53c
comment:2 Changed 6 years ago by
 Status changed from new to needs_review
comment:3 Changed 6 years ago by
 Cc jhpalmieri added
comment:4 Changed 6 years ago by
I don't know how standard the name is  I'd never heard it  so you might provide references: I found http://www.math.cornell.edu/~maguiar/adams.pdf and http://preprints.ihes.fr/2006/M/M0640.pdf, for example. By the way, I object to the notation \Delta^1 = Id
: I think most people would expect \Delta^1 = \Delta
and \Delta^0 = Id
. Same for \mu
, of course.
comment:5 Changed 6 years ago by
 Commit changed from a685ad1c5acbb5dc1451e06809ce74955d54d53c to fc8726a50725479d84aa9a07f55e28e1f879880a
Branch pushed to git repo; I updated commit sha1. New commits:
fc8726a  ticket 18350: revision following comments

comment:6 followup: ↓ 9 Changed 6 years ago by
 Cc nborie mshimo added
Salut JeanBaptiste,
Thanks for the proof of concept!
Computing n
fold products and coproducts is a generally useful
feature, so I would abstract it away. Probably with an API such as:
sage: H = MyFavoriteHopfAlgebra() sage: coprodk = H.nfold_coproduct(n); phi A morphism from H to H # ... # H sage: muk = H.mu(n); muk A morphism from H # ... # H to H sage: mu = H.mu(); mu # default value A morphism from H # H to H sage: adams = H.adams_operator(n); adams A morphism from H to H
I don't have a strong opinion for what n
should stand for. At first
sight it feels natural to have H.nfold_coproduct(n)
go from H
the
n
fold tensor product of H
, and reciprocally for H.mu
. But this
does not match with Dima's suggestion since H.coproduct
would be
H.nfold_coproduct(2)
.
Possibly with shorthands to call those from the elements:
sage: h = H().an_element() sage: h.nfold_coproduct(n) # in Coalgebras.TensorProducts.ElementMethods sage: h.adams(n) # in HopfAlgebras.TensorProducts.ElementMethods? sage: tensor([h,h,h]).mu() # in Algebras.TensorProducts.ElementMethods?
This approach also has the advantage of constructing the morphisms only once.
H.adams_operator
can be simply defined as `H.mu(n) *
H.nfold_coproduct(n).
H.mu` can be defined straightforwardly on the
basis. H.nfold_coproduct
indeed has to be defined recursively as
you did. We might as well use binary exponentiation. For example,
H.nfold_coproduct(2*n)
can be defined as:
tensor([H.coproduct(n), H.coproduct(n)]) * H.coproduct
So altogether this should require no more code (possibly less) than what you have already.
One small feature we are missing in Sage 6.6: constructing tensor products of morphisms. Luckily we do have code for this: #15832 (Nicolas Borie also has code for this somewhere; Nicolas: could you provide us with a pointer? Thanks). It's a small feature that we really want to have anyway, so that can be a good occasion to get it merged in.
Cheers,
Nicolas
comment:7 Changed 6 years ago by
 Cc tscrim added
comment:8 followup: ↓ 10 Changed 6 years ago by
Hi,
That is easy to implement an ugly nfold_coproduct
(as I did) but I don't know how to implement an nfold_product
. Where implements it?
Furthermore, if you want to go in this way it seems to be great to be able to do that:
sage: h = MyFavoriteHopfAlgebras(QQ) sage: id = h.identity_map sage: mu = h.product sage: op = tensor([mu, id]) sage: a,b,c = h.some_three_elements() sage: op(tensor([a,b,c])) a*b # c
This feature exists? If this exists I'm agree to implement those nfold_coproduct
and nfold_product
operators but otherwise I assume this feature should be implemented before.
comment:9 in reply to: ↑ 6 Changed 6 years ago by
Sorry... I'm a bad reader... You already answer to my last question... #15832.
Thanks. I will look at it
comment:10 in reply to: ↑ 8 Changed 6 years ago by
Replying to elixyre:
That is easy to implement an ugly
nfold_coproduct
(as I did) but I don't know how to implement annfold_product
. Where implements it?
Typically a method in Algebras.ParentMethods? whose code would be along the following lines (not tested!):
T = tensor([self]*n) T.module_morphism(lambda t: self.product(self.monomial(i) for i in t), codomain=self)
Btw: I looked at the code of #15832: there are many other things in the branch attached to the ticket; I'll try to extract a branch with just the ticketrelevant feature tomorrow.
Cheers,
Nicolas
comment:11 Changed 6 years ago by
I'm not too fond of the name nfold_coproduct
as I think it will be hard to discover. How about instead coproduct_power
?
comment:12 Changed 6 years ago by
Or iterated_coproduct
? I guess you're thinking about tabcompletion, which won't help for my suggestion...
comment:13 Changed 6 years ago by
Yeah, I see your point. I am not super keen on "coproduct power"
either, as it's really the analogue (in fact essentially the dual) of
nary products (which of course are computed iteratively from binary
products), and less so of powering (for
composition/multiplication). In particular, n
is more related to the
number of factors in the tensor than to the number of times the
coproduct needs to be iterated.
I agree that tabcompletionwise it would be nice to have a name such
as coproduct_...
. I could live with coproduct_nfold
. But any
better suggestion is welcome!
Cheers,
Nicolas
comment:14 followups: ↓ 15 ↓ 17 Changed 6 years ago by
Another nondiscoverableviatabcompletion way: have coproduct
take an optional argument n
(default 1) and then a.coproduct(n)
will return the nfold coproduct.
comment:15 in reply to: ↑ 14 ; followup: ↓ 16 Changed 6 years ago by
Replying to jhpalmieri:
Another nondiscoverableviatabcompletion way: have
coproduct
take an optional argumentn
(default 1) and thena.coproduct(n)
will return the nfold coproduct.
I think this would be a good solution. For the most part, we don't implement a coproduct()
, but use the general one with a coproduct_on_basis
(in fact, I don't know of a place where we have a custom coproduct
). So it will be discoverable using code inspection.
I thought of coproduct_power
by thinking of it as a module morphism which was repeatedly applied, but I see your point. Although for that we'd only have the ambiguity for bialgebras, right? Anyways coproduct_nfold
would be acceptable to me, and I think iterated_coproduct
is also something somewhat natural and is acceptable.
comment:16 in reply to: ↑ 15 Changed 6 years ago by
Replying to jhpalmieri:
Another nondiscoverableviatabcompletion way: have
coproduct
take an optional argumentn
(default 1) and thena.coproduct(n)
will return the nfold coproduct.
I think this comfortable to have some alias but it is also important to have a real name method (alias are syntactic sugar). I am agree with the alias coproduct(n)
.
Replying to tscrim:
I thought of
coproduct_power
by thinking of it as a module morphism which was repeatedly applied, but I see your point. Although for that we'd only have the ambiguity for bialgebras, right? Anywayscoproduct_nfold
would be acceptable to me, and I thinkiterated_coproduct
is also something somewhat natural and is acceptable.
I think iterated_coproduct
is hard to discover. Is this totally nonsense to have coproduct_iterated
? I let you choose a good name... My english is to bad to find relevant names.
comment:17 in reply to: ↑ 14 Changed 6 years ago by
Replying to jhpalmieri:
Another nondiscoverableviatabcompletion way: have
coproduct
take an optional argumentn
(default 1) and thena.coproduct(n)
will return the nfold coproduct.
You mean for a
an element, right? (at the level of the parent, the syntax is h.coproduct(x)
so this would require something like h.coproduct(x,n)
.
The logic for the standard coproduct and the iterated coproduct is
quite different. Keeping the methods separate makes it easier to
override just one or the other. That being said, if we decide that the
coproduct and iterated coproduct should always be implemented in the
parent (but I am not sure about it), then that would be fine to have a
single method a.coproduct(...)
on the element side that just acts as
an alias.
Cheers,
Nicolas
comment:18 Changed 6 years ago by
So it seems like the solution we are all unhappy with, but can live with (which makes a good compromise :P) is coproduct_nfold
. Any objections to this?
comment:19 Changed 6 years ago by
I vote for iterated_coproduct
.
comment:20 Changed 6 years ago by
Aaron and I vote for coproduct_iterated
.
Also, about n: there are two conventions (number of factors in the codomain, or one less than this). We prefer n being the number of factors in the codomain (so the usual coproduct is n=2), and mu^{n} Delta^{n} goes from H to H.
We understand there is overlap with ticket #18678.
comment:21 Changed 6 years ago by
 Cc amypang added
comment:22 Changed 6 years ago by
I will be merging with ticket #18678 over the next few days. In the meantime, some comments for people intheknow to weighin on (will repeat in #18678 when updates appear)...
.adams_operator()
should be moved tobialgebras.py
, then inhopf_algebras.py
one should overwrite the bialgebras version, allowing for negative integer powers. (E.g., the (2)nd convolution power of the identity is none other than the 2nd power of the antipode.)
 In fact, while adams operators naturally belong in
bialgebras.py
, the present codein ticket #18678 and #18350actually belongs inbialgebras_with_basis.py
as it uses.module_morphism()
and.apply_multilinear_morphism()
but this would require more rewriting than I feel qualified to handle.
 More tickets needed! When poking around for an algebra without basison which to test my codeI noticed that Sage doesn't know that
QQ[x]
is a module overQQ
(and hence, one cannot buildQQ[x].tensor(QQ[x])`. Crazy.
 Similarly, even though
B = FreeAlgebra(QQ,a,b)
is robust enough thatB.tensor(B)
doesn't throw errors, quotients are outofbounds again. PuttingC = B.quotient_ring((a*bb^2,))
, I get an AttributeError? when asking forC.tensor(C)
.
 One could also add the following functionality: given linear morphisms R,S,T for a bialgebra B, create their convolution product, a new morphism, via
RST = B.convolution_product(R,S,T)
or perhaps, defined only at the level of a distinguished basis m for B,RST = m.convolution_product(R,S,T)
. However, it seems ticket #15832 will have a lot of overlap with such code, so I'll hold off on implementing it unless somebody suggests otherwise.
P.S. Any final votes regarding Amy Pang's recent comment?
comment:23 Changed 6 years ago by
 Cc alauve added
comment:24 Changed 6 years ago by
 Milestone changed from sage6.7 to sageduplicate/invalid/wontfix
This ticket should be marked as duplicate and closed in light of #18678.
comment:25 Changed 6 years ago by
 Status changed from needs_review to positive_review
comment:26 Changed 6 years ago by
 Resolution set to duplicate
 Status changed from positive_review to closed
New commits:
new operator
new operator: iterate coproduct and product k times