Opened 7 years ago

Closed 7 years ago

#16819 closed enhancement (duplicate)

Implement categories for Lie algebras

Reported by: tscrim Owned by: tscrim
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: categories Keywords: lie algebras
Cc: Merged in:
Authors: Reviewers: Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: public/categories/lie_algebras-16819 (Commits, GitHub, GitLab) Commit: eb3b058689ffe114ef62c8b4389e784fad8d176c
Dependencies: Stopgaps:

Status badges

Description

Part of #14901. This implements a basic version of the categories:

  • Lie algebras
    • With basis
    • Finite dimensional

and examples for each.

Change History (62)

comment:1 Changed 7 years ago by tscrim

  • Milestone set to sage-6.4

comment:2 Changed 7 years ago by tscrim

  • Branch set to public/categories/lie_algebras-16819
  • Commit set to 1e1a6a706e7eb99254de586d6702774934c1c4ff
  • Component changed from algebra to categories
  • Keywords lie algebras added
  • Status changed from new to needs_review

Yay, the first part of Lie algebras that is ready for review!!! Next up will be #16820.


New commits:

9cbd3bdInitial import from #14901 and started another example.
16aaa72Better implementation of Lie algebra examples.
aae396bFinished 2 of the 3 examples for Lie algebras.
1544ff7Moved lie_algebra_element.py into the example directly.
a5d05e4Started on finite dim lie alg with basis.
663e1aeSome more work to FD Lie Alg with basis.
8d6084eFixes, improvements, and changes to FD Lie algebras with basis.
100e8c4Merge branch 'develop' into public/categories/lie_algebras-16819
78579bdSome more fixes and changes to FD Lie algebras with basis.
1e1a6a7Now we are at full coverage and working examples.

comment:3 Changed 7 years ago by git

  • Commit changed from 1e1a6a706e7eb99254de586d6702774934c1c4ff to b302cc1c9ebc9466b6cabc6f6e95cd1461de0855

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

cbfbb87Merge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
ed93f29Created category for subalgebras of FD Lie algebras with basis.
b302cc1Added free_module abstract method.

comment:4 Changed 7 years ago by tscrim

#16820 is also ready for review (so a "real" implementation that can be reviewed simultaneously).

comment:5 Changed 7 years ago by git

  • Commit changed from b302cc1c9ebc9466b6cabc6f6e95cd1461de0855 to 65c1f5451f4f496fa0f52d66606de806dda60a43

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

330497bMerge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
65c1f54Removed the LiftMorphism.section map.

comment:6 Changed 7 years ago by darij

+ The Killing form is defined as the matrix corresponding to the
+ action of `\mathrm{ad}_x \circ \mathrm{ad}_y` in the basis
+ of ``self``.

You mean "Killing matrix".

(Mainly posting this to get cc.)

comment:7 Changed 7 years ago by git

  • Commit changed from 65c1f5451f4f496fa0f52d66606de806dda60a43 to 980545eafb913863a66a06f1e4d5d2e61141490a

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

becabaaMerge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
980545eFixed the doc.

comment:8 Changed 7 years ago by git

  • Commit changed from 980545eafb913863a66a06f1e4d5d2e61141490a to 9b08311a7902b9c3d7d62518b2b52d38743b81a8

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

8a6950aMerge branch 'public/categories/lie_algebras-16819' of git://trac.sagemath.org/sage into lie1
9b08311a few questions to boot

comment:9 Changed 7 years ago by git

  • Commit changed from 9b08311a7902b9c3d7d62518b2b52d38743b81a8 to 5a0bc7df31648bbde2ab8f5181f4930ea74feee5

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

5a0bc7dAnswering some questions.

comment:10 Changed 7 years ago by git

  • Commit changed from 5a0bc7df31648bbde2ab8f5181f4930ea74feee5 to 144a5a5e6432062279a8600f8acd24f7083051f9

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

144a5a5Small fix for the doc.

comment:11 Changed 7 years ago by tscrim

Something to note is that each of the examples are meant to be minimal.

Specifically I made the general LieAlgebras example be the algebra generated by a set of elements in order to avoid not having to worry about if the associative algebra does not have a good basis method. However this is easy enough to change if you feel strongly about it. Same for the WithBasis example.

comment:12 Changed 7 years ago by git

  • Commit changed from 144a5a5e6432062279a8600f8acd24f7083051f9 to 198f8a8db695921d8f7ae5fdabc4a6bdd7388f7b

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

198f8a8Added new categories to documentation.

comment:13 Changed 7 years ago by darij

The lie_algebra_generators is currently a lie, so yes, it should be changed. About the names, thanks for accepting a number -- that's a good step -- but I'm still unsure why I am supposed to provide names if I provide a module, and what these names are used for. But we can talk about it in Davis, which I guess will be easier.

comment:14 follow-up: Changed 7 years ago by darij

Actually, I was stupid. The Lie algebra generators are fine, since LieAlgebraFromAssociative is defined to be the Lie superalgebra generated by gens, not the whole associative algebra. I should have actually read your post, if not the doc :/

On the other hand, I would expect to see the whole associative algebra implemented in a visible place. Is this in one of the followup tickets?

Last edited 7 years ago by darij (previous) (diff)

comment:15 in reply to: ↑ 14 Changed 7 years ago by tscrim

Replying to darij:

Actually, I was stupid. The Lie algebra generators are fine, since LieAlgebraFromAssociative is defined to be the Lie superalgebra generated by gens, not the whole associative algebra. I should have actually read your post, if not the doc :/

On the other hand, I would expect to see the whole associative algebra implemented in a visible place. Is this in one of the followup tickets?

It's in #16820, but feel free to change it here if you want.

comment:16 Changed 7 years ago by git

  • Commit changed from 198f8a8db695921d8f7ae5fdabc4a6bdd7388f7b to f7ba301d312cd2e8e10dd23afde638d557aab949

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

f716d74Merge branch 'public/categories/lie_algebras-16819' of git://trac.sagemath.org/sage into lie1
6b3a623review of src/sage/categories/examples/lie_algebras.py
f7ba301rest

comment:17 Changed 7 years ago by git

  • Commit changed from f7ba301d312cd2e8e10dd23afde638d557aab949 to 3f07d055c8fb0a7da1d1ef7d2eaddb7d177fa6b8

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

3f07d05fixing another doctest

comment:18 Changed 7 years ago by darij

Please ignore ​f7ba301 "rest". That's an unfinished set of changes on the abelian Lie algebra example that causes 2 mysterious bugs.

comment:19 Changed 7 years ago by git

  • Commit changed from 3f07d055c8fb0a7da1d1ef7d2eaddb7d177fa6b8 to 898b24a46b1064369fdef931a09f9b7f8b22fbed

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

898b24aanonymizing AbelianLieAlgebra example

comment:20 Changed 7 years ago by darij

I've removed the names now, but I'm anything but sure of the resulting code's correctness; I still need to actually review it.

There is a weird doctest failure now in the lift method, but I find the fact that it used to work before even weirder. Moreover it wasn't working correctly to begin with, since the lift would end up living in a noncommutative(!) multivariate polynomial ring. The universal enveloping algebra of an abelian Lie algebra is the commutative multivariate polynomial ring. But I have no idea where in the code the construction of the universal envelope is...

comment:21 Changed 7 years ago by git

  • Commit changed from 898b24a46b1064369fdef931a09f9b7f8b22fbed to b0abe90e740a849113871306f7275ba376aa17aa

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

b0abe90a few more fixes(?)

comment:22 Changed 7 years ago by darij

Actually, my fixes probably break more stuff than they fix. Need to discuss where we are going with this after the talk.

comment:23 Changed 7 years ago by tscrim

The universal_enveloping_algebra code is in the category and it calls the lift, which calls the _construct_UEA method (where the actual construction occurs). In the case of this Abelian Lie algebra, is it calls the generic code, which it returns something which thinks it's noncommutative, but the relations should make it commutative polynomial ring. Again, I was thinking minimial implementation, but it might be useful to implement this explicitly for the example...

comment:24 Changed 7 years ago by git

  • Commit changed from b0abe90e740a849113871306f7275ba376aa17aa to ee7b9cd107a53be39b4660c146332be157abea69

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

0341c9aMerge branch 'public/categories/lie_algebras-16819' of git://trac.sagemath.org/sage into lie1
ee7b9cdcleaning fallout from removing the names in abelian Lie algebra example

comment:25 Changed 7 years ago by darij

Question on categories/lie_algebras.py: if the (underscored) _bracket_ method is optional, shouldn't the other methods rely on bracket rather than _bracket_?

Also, should I keep removing unused imports found by pyflakes, or do they become necessary in further patches? e.g.: from sage.structure.sage_object import have_same_parent

Last edited 7 years ago by darij (previous) (diff)

comment:26 Changed 7 years ago by git

  • Commit changed from ee7b9cd107a53be39b4660c146332be157abea69 to 7ad90c037c5b22d96383ffbf480079e13ac6e300

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

7ad90c0trivial doc correction

comment:27 Changed 7 years ago by tscrim

Strictly speaking we don't want the user to override bracket, but instead call _bracket_. So it would probably be best to make _bracket_ on the elements be a non-optional @abstract_method.

You can do the pyflakes cleanup as they can be added back in if they are needed elsewhere (they probably aren't).

comment:28 Changed 7 years ago by git

  • Commit changed from 7ad90c037c5b22d96383ffbf480079e13ac6e300 to 3084981752c2869399b05fd91705178f1101329b

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

3084981making _bracket_ required and bracket optional (was the other way round, which could lead to attributeerrors)

comment:29 Changed 7 years ago by git

  • Commit changed from 3084981752c2869399b05fd91705178f1101329b to aabf5405d5472a0fad8782e506e96e382596f96f

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

b4a5b84Merge branch 'develop' into public/categories/lie_algebras-16819
a65bfc5Merge branch 'develop' into public/categories/lie_algebras-16819
64ca61dMerge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
896028aA y for an x.
6ca7acaFixing some parts of _construct_UEA.
d35b756Adding a default _basis_ordering and _dense_free_module
e95d67cMore fixes to fin-dim w/ basis category.
aabf540Fixing coefficient division.

comment:30 Changed 7 years ago by git

  • Commit changed from aabf5405d5472a0fad8782e506e96e382596f96f to 2128184c6460fa03b8d4a90e97792315202d9805

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

2128184yet another stupid question

comment:31 Changed 7 years ago by tscrim

universal_enveloping_algebra automatically constructs the lift morphism and the coercion by calling the (lazy_attribute) lift, whereas _construct_UEA simply constructs the object. I did things this way so that the user doesn't have to worry about constructing the coercion, but if the user wants to not have a coercion, then one can just implement universal_enveloping_algebra.

comment:32 Changed 7 years ago by git

  • Commit changed from 2128184c6460fa03b8d4a90e97792315202d9805 to 8eda1040915249308c40dd286dd6436fefb3408c

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

8eda104some more changes

comment:33 Changed 7 years ago by darij

Thanks for the explanation!

comment:34 Changed 7 years ago by tscrim

AFAIK, we don't really have any support for non-free modules. Also I use the free module for finite dimensional with basis to do the linear algebra for the algorithms. However I don't think I need it except in that category. So I'm okay with changing the name or removing the method since in fin-dim w/ basis since I added _dense_free_module for compatibility with CombinatorialFreeModule(Element) methods.

comment:35 Changed 7 years ago by git

  • Commit changed from 8eda1040915249308c40dd286dd6436fefb3408c to c893945b300c3157485d4094fd2e72eadb65935d

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

6c18d07rename free_module as module
c893945review sage/categories/lie_algebras.py

comment:36 Changed 7 years ago by tscrim

The is_field can be removed; that was a holdover from when I first made this a subcategory of MagmaticAlgebras. Also we should separate the test for antisymmetry from the Jacobi as this gives more information when TestSuite fails.

comment:37 Changed 7 years ago by git

  • Commit changed from c893945b300c3157485d4094fd2e72eadb65935d to 37a1ece719c7de6fff56bcbbf88679e8d23763fd

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

37a1ecea few more changes

comment:38 Changed 7 years ago by git

  • Commit changed from 37a1ece719c7de6fff56bcbbf88679e8d23763fd to 464c131fcfa33e4e6a2172ee7e1fdf4144b0425d

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

464c131another appearance of free_module

comment:39 Changed 7 years ago by git

  • Commit changed from 464c131fcfa33e4e6a2172ee7e1fdf4144b0425d to 6608a1805869afd139d6c1c6361caf2542363b25

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

6608a18.module and .to_vector: I still don't get them

comment:40 Changed 7 years ago by tscrim

We have module and to_vector because the (fin-dim) Lie algebra (with basis) doesn't know how to do linear algebra (which requires the specialized implementations of FreeModule).

comment:41 Changed 7 years ago by darij

So, these methods become important when self does not belong to FreeModules(self.base_ring()) ?

But shouldn't WithBasis automatically force it to be a FreeModules parent?

comment:42 Changed 7 years ago by tscrim

We don't have a category of FreeModules (in fact, I don't really believe this should be a category), but the methods are important when doing things like finding (a basis for) the derived subalgebra.

comment:43 Changed 7 years ago by darij

Uhm... don't we?

sage: FreeModules(QQ)
Category of vector spaces with basis over Rational Field
sage: FreeModules(ZZ)
Category of modules with basis over Integer Ring

Can it be that what you want are *un-indexed* free modules, i.e., ones which consist of row vectors?

comment:44 Changed 7 years ago by tscrim

Duh, a module with a basis is a free module by definition...(Although that specific category is just an alias.) However in this case it is somewhat stronger of a category in that there is a distinguished basis (i.e., like sets with a marked point). Perhaps we need to lower the to_vector into the fin-dim w/ basis category (if it's not already there)?

comment:45 Changed 7 years ago by darij

OK, let me be lazy/stupid and just ask concretely what methods require to_vector and module to work and would break if these were removed. What do you mean by a "free module" that a FiniteDimensionalLieAlgebraWithBasis does not satisfy?

comment:46 Changed 7 years ago by tscrim

Basically anything in FiniteDimensionalLieAlgebraWithBasis since they are required to do things like echelonize a matrix constructed from a set of elements in the Lie algebra, and then pull back the rows of this matrix. Although to_vector doesn't strictly need to be a vector, but there needs to be a way to construct a list consistently to pass to a matrix. However having the to_vector gives better support for a forgetful functor if such a thing gets implemented. Although perhaps it should be _vector_ so it could be passed to to the vector() function...

comment:47 Changed 7 years ago by darij

OK... Do I then understand you correctly that to_vector should return a list or tuple (of coordinates) as opposed to a family or (say) an element of NSym? And module should return a free module in which these to_vectors live?

comment:48 Changed 7 years ago by tscrim

Yes and most likely yes. At least, my use cases are what I mentioned above which will come up more with #16820 and other follow-ups, and there, to_vector will return an element of module.

comment:49 Changed 7 years ago by git

  • Commit changed from 6608a1805869afd139d6c1c6361caf2542363b25 to 6201720759c9f35cb0349a3c71d7b178686ef346

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

106d75dMerge branch 'public/categories/lie_algebras-16819' of git://trac.sagemath.org/sage into lie1
6201720does this make sense?

comment:50 Changed 7 years ago by tscrim

I don't like stating that it is unindexed; in fact, it is typically indexed by [n]. Currently we don't have good support for other indexed instances of FreeModule, but this is something we want to change in the future. In that vein, I don't quite care for saying it is a column vector. Also I'd rather say that we pick an ordering of some basis if it exists, rather than saying if there exists one.

The reason I had an abstract method module in LieAlgebras was to say it was natural, but it was made optional for what I hope are obvious reasons.

I don't really like this paradigm of from_vector, but instead just wanted to use the basis and/or implementing a general _element_constructor_ in the ABC which handles the conversion (if such a conversion exists).

comment:51 Changed 7 years ago by darij

Can I require that (for L a Lie algebra and x an element of L)

  • the image x.to_vector() is an element of L.module(), and
  • elements of L.module(), or -- rather -- lists of them can be put into the matrix constructor, and
  • L(x.to_vector()) == x (I assume this is what you meant in the last paragraph)?
Last edited 7 years ago by darij (previous) (diff)

comment:52 Changed 7 years ago by tscrim

Yes, no, and yes. However for fin-dim, the second one should be a yes.

The reason why I don't want the second in general is perhaps someone wants a free module version of the Lie algebra because there are extra features there, such as taking tensor products (which I guess is currently the only really distinct feature).

comment:53 Changed 7 years ago by git

  • Commit changed from 6201720759c9f35cb0349a3c71d7b178686ef346 to b0e36fe84ece0690d7298cd913ec8b77a3c4f38b

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

ddc77b1Merge branch 'public/categories/lie_algebras-16819' of git://trac.sagemath.org/sage into lie1a
b0e36fechanges I forgot to commit a few weeks ago

comment:54 Changed 7 years ago by git

  • Commit changed from b0e36fe84ece0690d7298cd913ec8b77a3c4f38b to de608491bf98ce8209b719e2a1052e2f13f917f3

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

42e505edo not use pip to install mistune
b412977manual merge with 6.7.beta0
de60849I have no idea what I'm doing

comment:55 Changed 7 years ago by git

  • Commit changed from de608491bf98ce8209b719e2a1052e2f13f917f3 to 0c28f5fce7c81cdaaa177eff1672e6382803a615

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

0c28f5freverting parts of previous commit with fire

comment:56 Changed 7 years ago by git

  • Commit changed from 0c28f5fce7c81cdaaa177eff1672e6382803a615 to dfad36c9deb5a0b35b72dbefee3ac5290e9fd838

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

d952a7bMerge branch 'public/categories/lie_algebras-16819' into 6.7.b1
dfad36ctrac #16819 wrong inclusion into doc is corrected

comment:57 Changed 7 years ago by chapoton

  • Status changed from needs_review to needs_work

Doc does not build, now because of a double ref

comment:58 Changed 7 years ago by git

  • Commit changed from dfad36c9deb5a0b35b72dbefee3ac5290e9fd838 to eb3b058689ffe114ef62c8b4389e784fad8d176c

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

eb3b058hopefully fix doc bug

comment:59 Changed 7 years ago by tscrim

Frederic, do you remember which reference is duplicated?

comment:60 Changed 7 years ago by chapoton

I was meaning nothing else than this 'gens' problem.

comment:61 Changed 7 years ago by tscrim

  • Authors Travis Scrimshaw deleted
  • Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
  • Reviewers set to Travis Scrimshaw
  • Status changed from needs_work to positive_review

Okay, Darij also noticed this and corrected it.

Also after some discussion, we decided to just fold this into #16820 and do it all in one block.

comment:62 Changed 7 years ago by vbraun

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