Hey Joe, Sorry for the delayed response (I've been traveling the past few days). > > > Sorry for posting and then disappearing for a bit. Thanks for your > answers. I will be very happy to have your help with the project to the > extent that you have time, and even just any quick suggestions and advice. >
Just cc "tscrim" on the tickets, and I will help when and where I can. > > My thinking was to do something that would cover arbitrary split connected > reductive algebraic groups using their classification by root data, and > associated presentations. For this one needs cases where the character > lattice is neither the root lattice nor the weight lattice. Maybe something > in between (like SO(n)) maybe something of higher rank (Like GL(n), > similitude groups, GSpin groups). > I think we should create classes for the character lattices similar to the root and weight lattices as I suspect a number of those methods could be lifted (or generalized to a common base class). > > It's not clear that this desire to do something general is that well > grounded in practical applications. In my old java project I implemented > only the five simply connected exceptional groups and mostly got by just > fine. Still, that was the idea. I noticed that reductive Kac-Moody groups > have a similar classification (and presentations) with root data. > Somewhat of a side question, but how much of your java code do you think is portable to Sage (or C++ that we can create bindings to with Cython)? > > So, I think the implementation of root and weight lattices for a root > system is a good source of ideas but would be directly applicable only to > simply connected/adjoint semisimple groups. > Essentially, I would say the character lattice should generalize the behaviors of the root and weight lattices. So they should be simple to implement. > > My thinking was that a based root datum can be easily passed as a pair of > matrices A,B. The rows of A represent the simple roots in terms of some > basis for the character lattice, and the rows of B represent the simple > coroots in terms of the dual basis of the cocharacter lattice. (One has to > work out the equivalence relation on matrix pairs that corresponds to > isomorphism of algebraic groups, but it's not too hard.) At that point one > has to choose bases for the two lattices in order to specify the object, so > they get an identification with ZZ^r essentially for free. Working out the > matrices for the two W-actions of simple reflections on ZZ^r from A and B > is pretty easy too. > We probably could associate this to some simple data like a group classification (or perhaps the groups themselves) for both ease of use and to help make sure the user data is consistent. Perhaps maybe we should restrict ourselves to some "good" class of groups, at least for an initial implementation. Although for full disclosure, I am slightly beyond my knowledge for more general algebraic groups as I primarily focus on (symmetrizable complex) Kac-Moody Lie algebras. So I am going to have to rely a bit on you for some of the more technical points. > > One thing I noticed is: it appears that the root and weight lattices are > implemented as ZZ-modules with a method .weyl_action, but not as > ZZ[W]-modules. Is there a reason for this choice? Naively, I thought "well, > what I have has the structure of a ZZ[W]-module so I guess I should > implement that structure." But you're both more experienced with Sage. > This should be easy to implement by using an _acted_upon_ that handles the W action by sending it to weyl_action. So this should not be too difficult to do. I suspect the reason this wasn't done was because it wasn't originally done in the MuPAD code or perhaps when they were implemented, actions weren't as well developed as they currently are. There might be a small technical issue with left vs. right actions, but I think we can easily work around it. Nicolas, any comments on this? > > I had been thinking to try to write something general which would take, as > input, a finitely presented group and a tuple of square integer matrices of > the same size. It would then check that mapping the generators in the > presentation to the matrices in order extends to a representation of the > group, i.e., to a ZZ[W]-module structure on ZZ^r for the relevant value of > r. Having done this checking it would then return that ZZ[W]-module. I > don't know whether that sounds like a good/bad approach to either of you. > > I think this thing would be a great way to create representations in general (something Sage sorely lacks). I have some code that constructed representations in a slightly different way, see: sage: S = SymmetricGroup(4) sage: R = S.regular_representation() However, I tried to make it somewhat general to be adapted to other uses. So perhaps you can start with that. The other thought that comes to my mind is to extend MatrixGroup. Best, Travis -- 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+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
