Opened 6 years ago

Closed 6 years ago

Reported by: Owned by: elixyre major sage-duplicate/invalid/wontfix categories nthiery, virmaux, jhpalmieri, nborie, mshimo, tscrim, amypang, alauve Jean-Baptiste Priez N/A u/elixyre/ticket/18350 fc8726a50725479d84aa9a07f55e28e1f879880a

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()
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, Jean-Baptiste

comment:1 Changed 6 years ago by elixyre

• Branch set to u/elixyre/ticket/18350

New commits:

 ​aeefa26 new operator ​a685ad1 new operator: iterate coproduct and product k times

comment:2 Changed 6 years ago by elixyre

• Status changed from new to needs_review

comment:4 Changed 6 years ago by jhpalmieri

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/M-06-40.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 git

• 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 follow-up: ↓ 9 Changed 6 years ago by nthiery

Salut Jean-Baptiste,

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

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: 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:8 follow-up: ↓ 10 Changed 6 years ago by elixyre

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 elixyre

Thanks. I will look at it

comment:10 in reply to: ↑ 8 Changed 6 years ago by nthiery

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?

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 ticket-relevant feature tomorrow.

Cheers,

Nicolas

comment:11 Changed 6 years ago by tscrim

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 jhpalmieri

Or iterated_coproduct? I guess you're thinking about tab-completion, which won't help for my suggestion...

comment:13 Changed 6 years ago by nthiery

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 n-ary 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 tab-completion-wise 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 follow-ups: ↓ 15 ↓ 17 Changed 6 years ago by jhpalmieri

Another non-discoverable-via-tab-completion way: have coproduct take an optional argument n (default 1) and then a.coproduct(n) will return the n-fold coproduct.

comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 6 years ago by tscrim

Another non-discoverable-via-tab-completion way: have coproduct take an optional argument n (default 1) and then a.coproduct(n) will return the n-fold 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 elixyre

Another non-discoverable-via-tab-completion way: have coproduct take an optional argument n (default 1) and then a.coproduct(n) will return the n-fold 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).

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.

I think iterated_coproduct is hard to discover. Is this totally non-sense 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 nthiery

Another non-discoverable-via-tab-completion way: have coproduct take an optional argument n (default 1) and then a.coproduct(n) will return the n-fold 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 tscrim

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?

Last edited 6 years ago by tscrim (previous) (diff)

comment:19 Changed 6 years ago by saliola

I vote for iterated_coproduct.

comment:20 Changed 6 years ago by amypang

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 mun Deltan goes from H to H.

We understand there is overlap with ticket #18678.

Last edited 6 years ago by amypang (previous) (diff)

comment:22 Changed 6 years ago by alauve

I will be merging with ticket #18678 over the next few days. In the meantime, some comments for people in-the-know to weigh-in on (will repeat in #18678 when updates appear)...

1. .adams_operator() should be moved to bialgebras.py, then in hopf_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.)
1. In fact, while adams operators naturally belong in bialgebras.py, the present code---in ticket #18678 and #18350---actually belongs in bialgebras_with_basis.py---as it uses .module_morphism() and .apply_multilinear_morphism()---but this would require more rewriting than I feel qualified to handle.
1. More tickets needed! When poking around for an algebra without basis---on which to test my code---I noticed that Sage doesn't know that QQ[x] is a module over QQ (and hence, one cannot build QQ[x].tensor(QQ[x]). Crazy.
1. Similarly, even though B = FreeAlgebra(QQ,a,b) is robust enough that B.tensor(B) doesn't throw errors, quotients are out-of-bounds again. Putting C = B.quotient_ring((a*b-b^2,)), I get an AttributeError? when asking for C.tensor(C).
1. 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:24 Changed 6 years ago by saliola

• Milestone changed from sage-6.7 to sage-duplicate/invalid/wontfix

This ticket should be marked as duplicate and closed in light of #18678.

comment:25 Changed 6 years ago by aapitzsch

• Status changed from needs_review to positive_review

comment:26 Changed 6 years ago by vbraun

• Resolution set to duplicate
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.