Opened 5 years ago

Closed 4 years ago

# Implement Lie algebra (co)homology

Reported by: Owned by: tscrim major sage-8.3 algebra lie algebras darij, bsalisbury1 Travis Scrimshaw Darij Grinberg, Ben Salisbury N/A 28accb5 28accb56804a4261fa377ed48000a24e2be46662

### Description

We implement the Lie algebra (co)homology for finite dimensional Lie algebras by constructing the Chevalley-Eilenberg complex.

### comment:1 Changed 5 years ago by tscrim

• Branch set to public/lie_algebras/homology-22883
• Commit set to 2f5a28f235a1b61cdb5c394bf5743d6c242afea6
• Status changed from new to needs_review

### comment:2 Changed 5 years ago by git

• Commit changed from 2f5a28f235a1b61cdb5c394bf5743d6c242afea6 to 6ef6f8c83c40af7fa483770f1b31bacbe6574b0e

Branch pushed to git repo; I updated commit sha1. New commits:

 ​6ef6f8c Implement Lie algebra (co)homology.

### comment:3 Changed 5 years ago by git

Branch pushed to git repo; I updated commit sha1. New commits:

 ​c493ba3 6ef6f8c manually inserted ​6bb5660 manual merge

### comment:4 follow-up: ↓ 11 Changed 5 years ago by darij

The doc of ChainComplex? ( http://doc.sagemath.org/html/en/reference/homology/sage/homology/chain_complex.html ) says that the syntax you're invoking ChainComplex? with ("a list/tuple/iterable of the form [d0,d1,d2,...] where each di is a matrix") only makes sense if degree is 1; but your degree is -1. Are you sure that this is legit? (I don't know ChainComplex? well, so this is just a question.)

The doc for cohomology uses left g-modules, whereas you have defined the Chevalley-Eilenberg complex for right g-modules. Of course, g being a Lie algebra, there is a 1-to-1 correspondence between those, but signs may get messed up. This is not a problem when the module is trivial, but it's worth checking that we aren't making something that will be a pain to deprecate.

Another reference: 10.1.3--10.1.6 of Loday's Cyclic Homology. He uses the opposite signs, though. Convention differences?

### comment:5 Changed 5 years ago by git

Branch pushed to git repo; I updated commit sha1. New commits:

 ​8c424dc review changes to Lie algebra cohomology

### comment:6 Changed 5 years ago by darij

The module case is waiting for a framework for Lie algebra modules, or do we have that already?

Apart from my previous comments, by the way, the patch is fine with me.

### comment:7 Changed 5 years ago by darij

• Reviewers set to Darij Grinberg

### comment:8 follow-up: ↓ 12 Changed 5 years ago by darij

PS. Do you know of an example where the Betti numbers aren't symmetric around the middle? I'm a bit paranoid about the degree; such an example would help ensure that we aren't secretly computing the dual complex and getting our homology and cohomology mixed up...

### comment:9 follow-up: ↓ 13 Changed 5 years ago by chapoton

Do not use .iteritems, please (for python3 compatibility).

### comment:10 Changed 5 years ago by git

• Commit changed from 8c424dc42c1f2345688ccb5693b85e3b02efab3d to 2adfffc48848ea67dfb064df66c49119624b2d5a

Branch pushed to git repo; I updated commit sha1. New commits:

 ​928374c Adding sparse option to Lie algebra homology. ​2adfffc Added options to compute Chevalley-Eilenberg chain complex in parallel.

### comment:11 in reply to: ↑ 4 Changed 5 years ago by tscrim

The doc of ChainComplex? ( http://doc.sagemath.org/html/en/reference/homology/sage/homology/chain_complex.html ) says that the syntax you're invoking ChainComplex? with ("a list/tuple/iterable of the form [d0,d1,d2,...] where each di is a matrix") only makes sense if degree is 1; but your degree is -1. Are you sure that this is legit? (I don't know ChainComplex? well, so this is just a question.)

I am not doing that. chain_data is a dict.

The doc for cohomology uses left g-modules, whereas you have defined the Chevalley-Eilenberg complex for right g-modules. Of course, g being a Lie algebra, there is a 1-to-1 correspondence between those, but signs may get messed up. This is not a problem when the module is trivial, but it's worth checking that we aren't making something that will be a pain to deprecate.

Since we do not currently support anything but the trivial module, this won't be a problem to change at a later point. However, there is a slight technical issue of left vs. right in that the cohomology should be a left g-module, but the homology is a right g-module. This would be something that would eventually be taken care of when general coefficient modules are implemented.

I added options to compute using sparse matrices (as I believe the matrices for the chain complex will generally be sparse) and to do the differential computation in parallel.

Another reference: 10.1.3--10.1.6 of Loday's Cyclic Homology. He uses the opposite signs, though. Convention differences?

Convention difference. The differential can always be multiplied by any (invertible) scalar as d(d(ax)) = d(a(dx)) = a d(d(x)) = 0 and scaling by a constant is homotopic to the identity map on chain complex (i.e., the resulting homology groups are isomorphic).

### comment:12 in reply to: ↑ 8 Changed 5 years ago by tscrim

PS. Do you know of an example where the Betti numbers aren't symmetric around the middle? I'm a bit paranoid about the degree; such an example would help ensure that we aren't secretly computing the dual complex and getting our homology and cohomology mixed up...

I do not, but I will try to construct such an example.

### comment:13 in reply to: ↑ 9 Changed 5 years ago by tscrim

Do not use .iteritems, please (for python3 compatibility).

That is for a vector object, so it is a well-defined method (for now).

Version 0, edited 5 years ago by tscrim (next)

### comment:14 Changed 5 years ago by chapoton

one failing doctest, see bot

### comment:15 Changed 5 years ago by git

• Commit changed from 2adfffc48848ea67dfb064df66c49119624b2d5a to 5c2ce780fca0bb68fc623900c366164e47e203bc

Branch pushed to git repo; I updated commit sha1. New commits:

 ​d5cce54 Merge branch 'public/lie_algebras/homology-22883' of trac.sagemath.org:sage into public/lie_algebras/homology-22883 ​5c2ce78 Fixing doctest due to basis order changing.

### comment:16 Changed 5 years ago by tscrim

Green patchbot.

@darij I could not construct an example that was not symmetric. However, I think we are okay. The left/right difference comes from the fact that we should be taking a dual module, but we don't see that for the trivial representation. So the care will have to be taken when that implementation is done, but I don't think we have to (or even can) worry about that here.

### comment:17 Changed 5 years ago by tscrim

• Milestone changed from sage-8.0 to sage-8.1

### comment:18 Changed 5 years ago by jhpalmieri

From https://mathoverflow.net/questions/184590/poincare-duality-for-cohomology-of-lie-algebras, a 2-dimensional Lie algebra for which the integral betti numbers do not satisfy \beta_k = \beta_{2-k}:

sage: d = {('x', 'y'): {'y': 2}}
sage: L.<x,y> = LieAlgebra(ZZ, d)
sage: L.cohomology()
{0: Z, 1: Z, 2: C2}


### comment:20 Changed 4 years ago by git

• Commit changed from 5c2ce780fca0bb68fc623900c366164e47e203bc to 660a2367579ebd1509c86fd042cbb37c905bca4c

Branch pushed to git repo; I updated commit sha1. New commits:

 ​f911259 Merge branch 'public/lie_algebras/homology-22883' of trac.sagemath.org:sage into public/lie_algebras/homology-22883 ​660a236 Adding example that does not have Poincare-type duality.

### comment:21 Changed 4 years ago by tscrim

I've added John's example from comment:18 (and its homology).

### comment:22 Changed 4 years ago by git

• Commit changed from 660a2367579ebd1509c86fd042cbb37c905bca4c to 28accb56804a4261fa377ed48000a24e2be46662

Branch pushed to git repo; I updated commit sha1. New commits:

 ​28accb5 words added to documentation

### comment:23 Changed 4 years ago by bsalisbury1

• Milestone changed from sage-8.1 to sage-8.3
• Reviewers changed from Darij Grinberg to Darij Grinberg, Ben Salisbury
• Status changed from needs_review to positive_review

### comment:24 Changed 4 years ago by vbraun

• Branch changed from public/lie_algebras/homology-22883 to 28accb56804a4261fa377ed48000a24e2be46662
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.