Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subcategories and base class for nilpotent Lie algebras #26074

Closed
ehaka mannequin opened this issue Aug 16, 2018 · 29 comments
Closed

Subcategories and base class for nilpotent Lie algebras #26074

ehaka mannequin opened this issue Aug 16, 2018 · 29 comments

Comments

@ehaka
Copy link
Mannequin

ehaka mannequin commented Aug 16, 2018

Implementation of subcategories for nilpotent, graded and stratified Lie algebras, and a base class and constructor for nilpotent Lie algebras mimicking LieAlgebraWithStructureCoefficients.

CC: @tscrim

Component: categories

Keywords: Lie algebras, nilpotent, graded, stratified

Author: Eero Hakavuori, Travis Scrimshaw

Branch/Commit: 120c02a

Reviewer: Travis Scrimshaw, Eero Hakavuori

Issue created by migration from https://trac.sagemath.org/ticket/26074

@ehaka ehaka mannequin added this to the sage-8.4 milestone Aug 16, 2018
@ehaka ehaka mannequin added c: categories labels Aug 16, 2018
@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 16, 2018

comment:1

An initial working copy of the implementation is in the commits. Whether the category framework was used correctly I do not know. In particular the distinction between axioms like .Finite() and covariant functorial constructions as in sage.categories.graded_modules to implement .Graded() was not clear to me.

Currently, based on my understanding of http://doc.sagemath.org/html/en/reference/categories/sage/categories/primer.html#difference-between-axioms-and-regressive-covariant-functorial-constructions, I added Nilpotent as an axiom and Graded and Stratified as covariant constructions. Comments on these choices or correction suggestions about how to use the category framework correctly are very welcome. As it is now, all the implemented methods seem to work as they should, but I do not know if some kind of mistake is lurking beneath the surface.

Moreover, the examples are currently slightly hand-built (e.g. by forcing an extra category on a nilpotent Lie algebra constructor). The main issue that I do not how to solve is that even in the case when the e.g. the natural stratification can be deduced (as in the implementation of the degree_on_basis method in sage.categories.graded_lie_algebras.FiniteDimensionalStratifiedLieAlgebrasWithBasis) the easy construction to verify the extra properties uses the constructed object itself. That is, the correct category is very difficult to deduce until after the parent has been initialized, and computation with its elements is possible. How would one approach this kind of problem?

Additionally, as a minor tweak I added an extra parameter submodule to the lower_central_series method in sage.categories.finite_dimensional_lie_algebras_with_basis to compute the lower central series purely in terms of submodules as was already done in the product_space method. Otherwise the nilpotency testing would require implementing ideals or writing the already existing code again somewhere else.

@ehaka ehaka mannequin added the s: needs info label Aug 16, 2018
@tscrim
Copy link
Collaborator

tscrim commented Aug 17, 2018

comment:2

So Nilpotent is definitely an axiom and Graded is definitely a functorial construction. Now for Stratified, I am not certain it is not an axiom. It is somewhat like Connected for Hopf algebras, an axiom that only makes sense in the Graded category. I think if we have a Lie algebra that is some axiom X and stratified, then it is an X stratified Lie algebra.

Most of your implementation of the categories is good on a quick look-over. There are a few things that could be simplified that I can work on tomorrow to make the structures a little cleaner given the code that is currently in the categories. We can easily expand things out later if there is a use for them. I think the easiest way to explain things will be me making some commits with the changes with some comments here, but if you would rather me just give comments, then let me know.

As to realizing the correct category, there is a _refine_category method that you can call later once you have computed some properties. This is what Zmod(p) does:

sage: P = Zmod(5)
sage: P.category()
Join of Category of finite commutative rings and Category of subquotients of monoids and Category of quotients of semigroups and Category of finite enumerated sets
sage: P in Fields()
True
sage: P.category()
Join of Category of finite enumerated fields and Category of subquotients of monoids and Category of quotients of semigroups

I should caution that this has been known to cause issues in the past, but mostly because these get used as the base ring (and hence, parameterize the category) for other objects. Although for general purpose classes, I am inclined to force the user to ask for such a property (such as in the example above), which can include calling particular methods.

+1 for the added option to lower_central_series. That is good for optimization purposes (e.g., if you only need the length of the central series).

As previously mentioned, I will take a detailed look tomorrow. I am assuming I can otherwise treat the code as needs review.

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 17, 2018

comment:3

Feel free to make any changes, I agree that it is much easier to understand things with something concrete to look at. The Zmod example is also very good to know, I did not know that categories do not necessarily have to be 'stable' post-initialization.

Your final assumption is correct, other than my confusion about the categories, I would have classified the code as 'needs review'.

@tscrim
Copy link
Collaborator

tscrim commented Aug 21, 2018

comment:4

I have made it through and reworked the categories around a bit, but it is more in line with what should be done (at least as I have learned it). As some extra test cases, I made the Heisenberg Lie algebra(s) in the nilpotent category.

I have done a few other tweaks to the doc and code, including fixing some other cases for product_space(submodule=True) exposed by the matrix Heisenberg Lie algebra. I am not sure about the separate NilpotentLieAlgebra constructor as I feel like we should have a way to connect it with the general LieAlgebra constructor, perhaps via a nilpotent=True argument. That way we have fewer top-level entry points and gives better exposure to the user. I am also okay pushing that off to a later ticket, but I'd like to hear your thoughts on the matter.

Hopefully these changes (currently) will not cause you too many refactoring problems with later tickets.


New commits:

a571c1bReworking things in the categories.
9b6c1feAdding Heisenberg to nilpotent Lie algebras.
158bfdbFix to product_space() for when L is not a true subalgebra of A.
293901eFixed a test for _test_generated_by_degree_one().
8658e9dFixing print order for fin-dim nilpotent Lie algebras with basis.
726639fSome last little cleanup.
8b3c585A better failure example for _test_generated_by_degree_one and some more doc.

@tscrim
Copy link
Collaborator

tscrim commented Aug 21, 2018

@tscrim
Copy link
Collaborator

tscrim commented Aug 21, 2018

Changed author from Eero Hakavuori to Eero Hakavuori, Travis Scrimshaw

@tscrim
Copy link
Collaborator

tscrim commented Aug 21, 2018

Changed commit from 19c27eb to 8b3c585

@tscrim
Copy link
Collaborator

tscrim commented Aug 21, 2018

Reviewer: Travis Scrimshaw, Eero Hakavuori

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 21, 2018

comment:5

Thanks for the improvements, looks quite good to me. Probably you are right about the NilpotentLieAlgebra constructor that the logic would be better inside LieAlgebra instead. It would also make sense to include in this ticket I think.

I noticed in the edits the extra_super_categories of finite dimensional stratified Lie algebras with basis got dropped. Currently we have for example

sage: C = LieAlgebras(QQ).FiniteDimensional().WithBasis().Graded().Stratified()
sage: C is C.Nilpotent()
False

whereas mathematically this should be True. Then again this does not really depend on the basis, so if I understand correctly, the right place to add the extra_super_categories would be in GradedLieAlgebras.Stratified with an 'if finite dimensional' clause.
I will add this and move the NilpotentLieAlgebra constructor inside LieAlgebra later today.

Regarding the text presentation of the categories, the automatic printing is a bit cumbersome:

sage: LieAlgebras(QQ).FiniteDimensional().WithBasis().Graded().Stratified().Nilpotent()
Category of finite dimensional stratified nilpotent graded lie algebras with basis over Rational Field

It makes sense to have Stratified as an axiom under Graded, but the automatic terminology 'stratified graded' or 'stratified X graded' sounds clunky. Would it be valid to replace 'stratified graded' with just 'stratified'? If so, what would be the most convenient way to systematically make this change for all axiom permutations?

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 21, 2018

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

a1e1aceRefactored nilpotent Lie algebra constructor into Lie algebra constructor
14fcd30Deduction rule for the fact that finite dimensional stratified Lie algebras are nilpotent
f1a0b1eDocstring fix for indexing of grading of a stratification

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 21, 2018

Changed commit from 8b3c585 to f1a0b1e

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 21, 2018

comment:7

I removed the NilpotentLieAlgebra constructor and inserted the logic into LieAlgebra adding a new boolean parameter nilpotent, which currently only comes into play if the constructor is passed a dictionary of structural coefficients.

I added the 'finite dimensional + stratified => nilpotent' deduction to GradedLieAlgebras.Stratified.FiniteDimensional. At least now the following works

sage: C = LieAlgebras(QQ).FiniteDimensional().Graded().Stratified()
sage: C is C.Nilpotent()
True

and it didn't break the existing deduction

sage: C = LieAlgebras(GF(5)).Graded().Stratified().FiniteDimensional()
sage: C.is_subcategory(Sets().Finite())
True

so I assume adding the FiniteDimensional subclass didn't break anything.

I also fixed some doctests in sage.algebras.lie_algebras.LieAlgebra that were failing since I added the nilpotent category to abelian Lie algebras.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Changed commit from f1a0b1e to 0fa41ad

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

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

a3dccfdMerge branch 'public/lie_algebras/base_class_nilponent-26074' of git://trac.sagemath.org/sage into public/lie_algebras/base_class_nilponent-26074
0fa41adFixing doctests, making category an arugment, and other small tweaks.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Changed commit from 0fa41ad to 53a10be

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

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

53a10beAdding an extra doctest and fix for the category option.

@tscrim
Copy link
Collaborator

tscrim commented Aug 22, 2018

comment:10

Replying to @ehaka:

I removed the NilpotentLieAlgebra constructor and inserted the logic into LieAlgebra adding a new boolean parameter nilpotent, which currently only comes into play if the constructor is passed a dictionary of structural coefficients.

Thank you. Looks good. I added an extra option so that when given NilpotentLieAlgebras as a category, then it automatically considers nilpotent=True.

I added the 'finite dimensional + stratified => nilpotent' deduction to GradedLieAlgebras.Stratified.FiniteDimensional. At least now the following works

Sorry about loosing that. Yes, this is the correct way to do it.

I also fixed some doctests in sage.algebras.lie_algebras.LieAlgebra that were failing since I added the nilpotent category to abelian Lie algebras.

I fixed two others that were coming back from the patchbot.

I know the text representation of the category is not very good. I will see if I can make it better (I think you can, but I need to dig around a little and experiment), but beyond that, I am happy with things here.

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 22, 2018

comment:11

The edits all look good to me. I would be ok with marking this as positive review and handling the category repr improvements eventually in a later ticket as it is only a cosmetic fix.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

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

a5ec3adMoving the axioms around for better printing.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Changed commit from 53a10be to a5ec3ad

@tscrim
Copy link
Collaborator

tscrim commented Aug 22, 2018

comment:13

Here is the improvements to the category repr. The "stratified graded" -> "stratified" was a standard(ish) workaround. Removing the "nilpotent" was a bit more work, but mainly because we do not want to say "nilpotent finite dimensional Lie algebras". However, it falls under the same workaround as the other. So if these last changes are good, then positive review.

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 22, 2018

comment:14

Replying to @tscrim:

Here is the improvements to the category repr. The "stratified graded" -> "stratified" was a standard(ish) workaround. Removing the "nilpotent" was a bit more work, but mainly because we do not want to say "nilpotent finite dimensional Lie algebras". However, it falls under the same workaround as the other. So if these last changes are good, then positive review.

Very nice! The various combinations of finite dimensional, graded, stratified and nilpotent all printed quite well now in my opinion.

@ehaka ehaka mannequin removed the s: needs review label Aug 22, 2018
@ehaka ehaka mannequin added the s: positive review label Aug 22, 2018
@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:

8f7aac5Added missing files to documentation, removed non-existent one that was causing docbuild to fail

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Changed commit from a5ec3ad to 8f7aac5

@ehaka
Copy link
Mannequin Author

ehaka mannequin commented Aug 22, 2018

comment:16

Docbuild was failing because of the non-existent module sage/categories/examples/finite_dimensional_nilpotent_lie_algebras_with_basis which I assume was meant to be sage/categories/finite... as that link was missing. Also added the nilpotent_lie_algebra link to the Lie algebra index and corrected a typo that was causing the documentation to display strangely.

I'll leave the ticket as needs review until it is verified that the doc changes were correct as I have not tried to modify the automatic html reference before.

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

Changed commit from 8f7aac5 to 120c02a

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Aug 22, 2018

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

120c02aSome trivial fixes.

@tscrim
Copy link
Collaborator

tscrim commented Aug 22, 2018

comment:18

Yep, LGTM. Thank you for catching and fixing that. I made some trivial changes and am allowing myself to set this to a positive review (I changed the Vk to Lk to be consistent notationally; feel free to revert the positive review if you disagree).

@vbraun
Copy link
Member

vbraun commented Aug 26, 2018

Changed branch from public/lie_algebras/base_class_nilponent-26074 to 120c02a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants