symbolic computation with Chevalley generators for algebraic groups

[Joseph Hundley]

By "algebraic groups" I mean "split connected reductive algebraic groups equipped with a choice of maximal torus, Borel subgroup, and realization/pinning/epinglage." 

(Though I am interested in principle in removing unnecessary hypotheses.)

By "Chevalley generators" I mean 

 * elements of root subgroups (say, elements of the form x_a( expression ) where a is a root and x_a is the fixed isomorphism from the additive group scheme to the root subgroup)

 * elements of the fixed maximal torus

 * representatives for the simple reflections in the Weyl group which have been fixed in some natural way. (The choice of x_a's gives a couple obvious options.) 

Unless I've oversimplified here such elements generate and all the relations among them are determined by the Cartan matrix and the matrix of structure constants of the realization, but there is a fair amount of book-keeping to be done. 

I'm fairly regularly interested in forming two products of elements of root subgroups and conjugating one by the other (in exceptional groups where this generators and relations approach is perhaps easier than a matrix realization). Does Sage have some functionality for doing this sort of thing that I'm unaware of? Is there more that should be added? 

[Travis Scrimshaw]

Hey Joseph
   As far as I know, none of that functionality has been implemented in Sage. In a strongly related direction, at some point I hope to implement the classical Lie groups and what are known as geometric crystals (in the sense of Berenstein and Kazhdan). Groups of Lie type would also be something I am interested in having in Sage (at least to me, this seems to be more of what you are after). You might be interested in https://trac.sagemath.org/ticket/14901 as well (and tickets referenced therein).

Best,
Travis

[Joseph Hundley]

Thanks, Travis. 

I guess I am inclined to try to build this thing and see who is interested in it. The ticket you linked is very helpful to me. 

I'm interested to know more about your plans for Lie groups and Groups of Lie type. 

In some sense it seems to me that the objects I'm really working with are Group schemes defined using a certain presentation. If I have a group scheme I can take real points to get a lie group or points over a finite field to get a finite group of Lie type. On the other hand depending on what one wants to do with the Lie group/FGLT, this might have little to nothing to do with how one wants to think about them.

Joe

[Travis Scrimshaw]

Hey Joe,

I guess I am inclined to try to build this thing and see who is interested in it. The ticket you linked is very helpful to me. 

Let me know what you need from me wrt #14901 or any additional feature requests.

I'm interested to know more about your plans for Lie groups and Groups of Lie type. 

   Right now, I don't have any immediate plans as I have many other things to do at present (one of which is getting back to polishing #14901). I would like to have Lie groups (over CC) use the SageManifolds framework rather than being abstract parents, and introduce their representation theory. However, I would be happy to review and offer my thoughts.

In some sense it seems to me that the objects I'm really working with are Group schemes defined using a certain presentation. If I have a group scheme I can take real points to get a lie group or points over a finite field to get a finite group of Lie type. On the other hand depending on what one wants to do with the Lie group/FGLT, this might have little to nothing to do with how one wants to think about them.

   That is probably the best way to think about how to implement things: what do you want to be able to do with them or learn from the implementation (at least, this is one of the ways I learn new math things). From there, that can tell you what features and functionality you want, which will influence your design decisions.

Best,
Travis

[David Joyner]

Joe and Travis:
To add to all this: GAP has already implemented some related objects:
(1) Lie algebras
(http://www.gap-system.org/Manuals/doc/ref/chap64.html,
http://www.gap-system.org/Datalib/lie.html,
http://www.science.unitn.it/~degraaf/sla.html)
(2) real Lie groups (http://users.monash.edu/~heikod/corelg/),
(3) finite grps of Lie type
(http://www.gap-system.org/Manuals/doc/ref/chap50.html#X8674AAA578FE4AEE).
I'm sure I'm leaving some out.
- David

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Travis Scrimshaw]

Hey David,
   Thank you for the links.

To add to all this: GAP has already implemented some related objects:
(1) Lie algebras
(http://www.gap-system.org/Manuals/doc/ref/chap64.html,
http://www.gap-system.org/Datalib/lie.html,
http://www.science.unitn.it/~degraaf/sla.html)

Implementing an interface with GAP's Lie algebras and related objects is something on my todo list as well. When I started #14901, I was not as aware of GAP's capabilities, and I think we have much better linear algebra algorithms that we can leverage. Although my current implementation doesn't do a very good job of this...

I need to implement an optional spkg for QuaGroup and an interface to it. I guess this should also include SLA. A question is should the GAP packages be bundled together. I will start another thread about this.

Best,
Travis

[Joseph Hundley]

I recently looked at Computing in Groups of Lie Type by Cohen, Murray and Taylor. The basic approach to representation and calculation which is taken there is essentially the one I had in mind. Plus they've worked a number of details I thought I would have to work out. It appears that this article was written as the algorithms in question were being implemented in Magma. I wonder firstly whether it would be considered "kosher" to reimplement them in Sage, and secondly whether it would be considered desirable. Naively, it seems to me that the article would not have been written if the algorithms were to be treated as protected intellectual property. And I'd already stumbled across quite a bit of it independently by following my nose. Still I'm fairly new to programming and have not yet learned the ethos around such things. 

If I were going forward with this, I think a reasonable first step would be to equip root systems with the ability to compute a few key integral invariants of roots and pairs of roots. Including: 

(1) the (normalized integral) norm square (always 1 for short roots, 2 or three for long...)

(2) the largest integer k (given roots a and b) such that a+kb is a root.

(3) the smallest integer k (given roots a and b) such that a+kb is a root.

(4) integral structure constants of the Chevalley presentation. These are not uniquely determined by the system, but there is a fairly standard way of selecting them-- described for example in Cohen Murray Taylor or a 1988 article of Gilkey and Seitz-- which depends only on the system, and therefore seems to me like a method which should live in class "root system."

[Travis Scrimshaw]

On Tuesday, July 26, 2016 at 3:07:04 PM UTC-5, Joseph Hundley wrote:

I recently looked at Computing in Groups of Lie Type by Cohen, Murray and Taylor. The basic approach to representation and calculation which is taken there is essentially the one I had in mind. Plus they've worked a number of details I thought I would have to work out. It appears that this article was written as the algorithms in question were being implemented in Magma. I wonder firstly whether it would be considered "kosher" to reimplement them in Sage, and secondly whether it would be considered desirable.

Yes and possibly yes. It depends on how much of the algorithms depends on doing linear algebra (or other aspects of Sage). If the answer is very little to none, I would do it as a separate package in C++ for the speed and then construct an iterface to it using Sage. Although we can always do it in Sage and extract things out afterwards.
 

Naively, it seems to me that the article would not have been written if the algorithms were to be treated as protected intellectual property. And I'd already stumbled across quite a bit of it independently by following my nose. Still I'm fairly new to programming and have not yet learned the ethos around such things. 

Its a published research paper, so we (i.e., anyone) are free to provide our own implementation.

If I were going forward with this, I think a reasonable first step would be to equip root systems with the ability to compute a few key integral invariants of roots and pairs of roots. Including: 

(1) the (normalized integral) norm square (always 1 for short roots, 2 or three for long...)

This is essentially already in Sage; you just need to divide by 2:

sage: al = RootSystem(['B',4]).root_lattice().simple_roots()
sage: al[1].norm_squared()
4
sage: al[4].norm_squared()
2
sage: al = RootSystem(['G',2]).root_lattice().simple_roots()
sage: al[1].norm_squared()
2
sage: al[2].norm_squared()
6
 

(2) the largest integer k (given roots a and b) such that a+kb is a root.

(3) the smallest integer k (given roots a and b) such that a+kb is a root.

I've done these ad-hoc for the classical Lie algebras (see #16821), but it would be good to have these as general methods.
 

(4) integral structure constants of the Chevalley presentation. These are not uniquely determined by the system, but there is a fairly standard way of selecting them-- described for example in Cohen Murray Taylor or a 1988 article of Gilkey and Seitz-- which depends only on the system, and therefore seems to me like a method which should live in class "root system."

If I am understanding what you want, see the structure coefficients for the classical groups in #16821. We can probably extract that out as separate functions, but I would not have them be a method of a root system since it is specialized for Lie algebras and groups of Lie type.

We might be better at this point moving the discussion to a trac ticket.

Best,
Travis

[Joseph Hundley]

Awesome. Thank you!  

Out of curiosity is there a reason .norm_squared() doesn't just divide by 2 for us? 

Joe

[Travis Scrimshaw]

On Wednesday, July 27, 2016 at 2:39:48 PM UTC-5, Joseph Hundley wrote:

Awesome. Thank you!  

Out of curiosity is there a reason .norm_squared() doesn't just divide by 2 for us? 

Because it is just the (symmetric) inner product of the root with itself, and I was following Kac's book when I implemented it.

Best,
Travis

[Joseph Hundley]

Sorry. Bad question. I meant something more like "I always normalize the symmetric inner product so that the short roots have norm one. From what point of view is this different normalization natural?" I guess I can find the answer in Kac's book. Thanks for your answer.