On Sunday, January 8, 2017 at 3:43:27 AM UTC-5, Travis Scrimshaw wrote: > > 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). >
sounds reasonable. I trust your judgement. > >> 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)? > Not sure. Actually, at risk of exposing my ignorance, let me just admit that I'm not sure what "portable" means here. > >> 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. > Indeed. In the *finite dimensional* case, if we want a one-to-one correspondence between root data and groups, what we want to do is take *split* *connected *groups. I would start with those. I think that in the finite dimensional case, one knows how to attach additional data which distinguishes nonisomorphic groups with the same root datum, but I don't know the details. In the infinite dimensional case, I don't honestly know whether the classification problem is solved over general fields. But we have a split group attached to a root datum and a presentation for it given in a paper of Tits. Long story short my thinking is to start with split connected groups such that the Cartan matrix is positive definite and build out from there. >> 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. > > Thanks. I'll try to have a look. Best, Joe 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.
