Opened 8 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: |
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 8 years ago by
- Milestone set to sage-6.4
comment:2 Changed 8 years ago by
- 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
comment:3 Changed 7 years ago by
- Commit changed from 1e1a6a706e7eb99254de586d6702774934c1c4ff to b302cc1c9ebc9466b6cabc6f6e95cd1461de0855
Branch pushed to git repo; I updated commit sha1. New commits:
cbfbb87 | Merge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
|
ed93f29 | Created category for subalgebras of FD Lie algebras with basis.
|
b302cc1 | Added free_module abstract method.
|
comment:4 Changed 7 years ago by
#16820 is also ready for review (so a "real" implementation that can be reviewed simultaneously).
comment:5 Changed 7 years ago by
- Commit changed from b302cc1c9ebc9466b6cabc6f6e95cd1461de0855 to 65c1f5451f4f496fa0f52d66606de806dda60a43
comment:6 Changed 7 years ago by
+ 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
- Commit changed from 65c1f5451f4f496fa0f52d66606de806dda60a43 to 980545eafb913863a66a06f1e4d5d2e61141490a
comment:8 Changed 7 years ago by
- Commit changed from 980545eafb913863a66a06f1e4d5d2e61141490a to 9b08311a7902b9c3d7d62518b2b52d38743b81a8
comment:9 Changed 7 years ago by
- Commit changed from 9b08311a7902b9c3d7d62518b2b52d38743b81a8 to 5a0bc7df31648bbde2ab8f5181f4930ea74feee5
Branch pushed to git repo; I updated commit sha1. New commits:
5a0bc7d | Answering some questions.
|
comment:10 Changed 7 years ago by
- Commit changed from 5a0bc7df31648bbde2ab8f5181f4930ea74feee5 to 144a5a5e6432062279a8600f8acd24f7083051f9
Branch pushed to git repo; I updated commit sha1. New commits:
144a5a5 | Small fix for the doc.
|
comment:11 Changed 7 years ago by
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
- Commit changed from 144a5a5e6432062279a8600f8acd24f7083051f9 to 198f8a8db695921d8f7ae5fdabc4a6bdd7388f7b
Branch pushed to git repo; I updated commit sha1. New commits:
198f8a8 | Added new categories to documentation.
|
comment:13 Changed 7 years ago by
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: ↓ 15 Changed 7 years ago by
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?
comment:15 in reply to: ↑ 14 Changed 7 years ago by
Replying to darij:
Actually, I was stupid. The Lie algebra generators are fine, since
LieAlgebraFromAssociative
is defined to be the Lie superalgebra generated bygens
, 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
- Commit changed from 198f8a8db695921d8f7ae5fdabc4a6bdd7388f7b to f7ba301d312cd2e8e10dd23afde638d557aab949
comment:17 Changed 7 years ago by
- Commit changed from f7ba301d312cd2e8e10dd23afde638d557aab949 to 3f07d055c8fb0a7da1d1ef7d2eaddb7d177fa6b8
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
3f07d05 | fixing another doctest
|
comment:18 Changed 7 years ago by
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
- Commit changed from 3f07d055c8fb0a7da1d1ef7d2eaddb7d177fa6b8 to 898b24a46b1064369fdef931a09f9b7f8b22fbed
Branch pushed to git repo; I updated commit sha1. New commits:
898b24a | anonymizing AbelianLieAlgebra example
|
comment:20 Changed 7 years ago by
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
- Commit changed from 898b24a46b1064369fdef931a09f9b7f8b22fbed to b0abe90e740a849113871306f7275ba376aa17aa
Branch pushed to git repo; I updated commit sha1. New commits:
b0abe90 | a few more fixes(?)
|
comment:22 Changed 7 years ago by
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
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
- Commit changed from b0abe90e740a849113871306f7275ba376aa17aa to ee7b9cd107a53be39b4660c146332be157abea69
comment:25 Changed 7 years ago by
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
comment:26 Changed 7 years ago by
- Commit changed from ee7b9cd107a53be39b4660c146332be157abea69 to 7ad90c037c5b22d96383ffbf480079e13ac6e300
Branch pushed to git repo; I updated commit sha1. New commits:
7ad90c0 | trivial doc correction
|
comment:27 Changed 7 years ago by
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
- Commit changed from 7ad90c037c5b22d96383ffbf480079e13ac6e300 to 3084981752c2869399b05fd91705178f1101329b
Branch pushed to git repo; I updated commit sha1. New commits:
3084981 | making _bracket_ required and bracket optional (was the other way round, which could lead to attributeerrors)
|
comment:29 Changed 7 years ago by
- Commit changed from 3084981752c2869399b05fd91705178f1101329b to aabf5405d5472a0fad8782e506e96e382596f96f
Branch pushed to git repo; I updated commit sha1. New commits:
b4a5b84 | Merge branch 'develop' into public/categories/lie_algebras-16819
|
a65bfc5 | Merge branch 'develop' into public/categories/lie_algebras-16819
|
64ca61d | Merge branch 'public/categories/lie_algebras-16819' of trac.sagemath.org:sage into public/categories/lie_algebras-16819
|
896028a | A y for an x.
|
6ca7aca | Fixing some parts of _construct_UEA.
|
d35b756 | Adding a default _basis_ordering and _dense_free_module
|
e95d67c | More fixes to fin-dim w/ basis category.
|
aabf540 | Fixing coefficient division.
|
comment:30 Changed 7 years ago by
- Commit changed from aabf5405d5472a0fad8782e506e96e382596f96f to 2128184c6460fa03b8d4a90e97792315202d9805
Branch pushed to git repo; I updated commit sha1. New commits:
2128184 | yet another stupid question
|
comment:31 Changed 7 years ago by
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
- Commit changed from 2128184c6460fa03b8d4a90e97792315202d9805 to 8eda1040915249308c40dd286dd6436fefb3408c
Branch pushed to git repo; I updated commit sha1. New commits:
8eda104 | some more changes
|
comment:33 Changed 7 years ago by
Thanks for the explanation!
comment:34 Changed 7 years ago by
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
- Commit changed from 8eda1040915249308c40dd286dd6436fefb3408c to c893945b300c3157485d4094fd2e72eadb65935d
comment:36 Changed 7 years ago by
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
- Commit changed from c893945b300c3157485d4094fd2e72eadb65935d to 37a1ece719c7de6fff56bcbbf88679e8d23763fd
Branch pushed to git repo; I updated commit sha1. New commits:
37a1ece | a few more changes
|
comment:38 Changed 7 years ago by
- Commit changed from 37a1ece719c7de6fff56bcbbf88679e8d23763fd to 464c131fcfa33e4e6a2172ee7e1fdf4144b0425d
Branch pushed to git repo; I updated commit sha1. New commits:
464c131 | another appearance of free_module
|
comment:39 Changed 7 years ago by
- 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
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
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
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
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
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
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
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
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_vector
s live?
comment:48 Changed 7 years ago by
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
- Commit changed from 6608a1805869afd139d6c1c6361caf2542363b25 to 6201720759c9f35cb0349a3c71d7b178686ef346
comment:50 Changed 7 years ago by
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
Can I require that (for L
a Lie algebra and x
an element of L
)
- the image
x.to_vector()
is an element ofL.module()
, and
- elements of
L.module()
, or -- rather -- lists of them can be put into thematrix
constructor, and
L(x.to_vector()) == x
(I assume this is what you meant in the last paragraph)?
comment:52 Changed 7 years ago by
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
- Commit changed from 6201720759c9f35cb0349a3c71d7b178686ef346 to b0e36fe84ece0690d7298cd913ec8b77a3c4f38b
comment:54 Changed 7 years ago by
- Commit changed from b0e36fe84ece0690d7298cd913ec8b77a3c4f38b to de608491bf98ce8209b719e2a1052e2f13f917f3
comment:55 Changed 7 years ago by
- Commit changed from de608491bf98ce8209b719e2a1052e2f13f917f3 to 0c28f5fce7c81cdaaa177eff1672e6382803a615
Branch pushed to git repo; I updated commit sha1. New commits:
0c28f5f | reverting parts of previous commit with fire
|
comment:56 Changed 7 years ago by
- Commit changed from 0c28f5fce7c81cdaaa177eff1672e6382803a615 to dfad36c9deb5a0b35b72dbefee3ac5290e9fd838
comment:57 Changed 7 years ago by
- 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
- Commit changed from dfad36c9deb5a0b35b72dbefee3ac5290e9fd838 to eb3b058689ffe114ef62c8b4389e784fad8d176c
Branch pushed to git repo; I updated commit sha1. New commits:
eb3b058 | hopefully fix doc bug
|
comment:59 Changed 7 years ago by
Frederic, do you remember which reference is duplicated?
comment:60 Changed 7 years ago by
I was meaning nothing else than this 'gens' problem.
comment:61 Changed 7 years ago by
- 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
- Resolution set to duplicate
- Status changed from positive_review to closed
Yay, the first part of Lie algebras that is ready for review!!! Next up will be #16820.
New commits:
Initial import from #14901 and started another example.
Better implementation of Lie algebra examples.
Finished 2 of the 3 examples for Lie algebras.
Moved lie_algebra_element.py into the example directly.
Started on finite dim lie alg with basis.
Some more work to FD Lie Alg with basis.
Fixes, improvements, and changes to FD Lie algebras with basis.
Merge branch 'develop' into public/categories/lie_algebras-16819
Some more fixes and changes to FD Lie algebras with basis.
Now we are at full coverage and working examples.