Root Systems and Weyl Groups
Joel B. Mohler
I think this is probably all aimed at Mike Hansen.
I've started looking at combinat/root_systems.py and combinat/cartan_type.py.
It looks like there is still a lot to be done. I'm assuming that what needs
to be done should be done via the optional (made standard) package lie. I
have some questions.
What is the difference between RootSystem and CartanType? For example, what
methods should be in one class or the other? Or, should they all have
methods like weyl_group, list_roots, dynkin_diagram and call each other?
I like the dynkin diagram code that returns a DiGraph. However, to actually
display the diagram, this isn't so nice. The graph show code doesn't
indicate the double/triple bonds visually and so the graphics don't really
look very reminiscient of what you would see in a book. The plot really
shouldn't have axes. Perhaps this is all just a graph graphics bug.
For starters, I'd like to have two big pieces of new functionality. We need a
way to enumerate the Weyl Group and the set of positive roots for a root
system. I see that I can get this from lie so I think that makes sense as a
first implementation. It seems that the only way to get these things from
lie is to enumerate them all in memory as a list -- I'd rather have a more
incremental approach as the Weyl groups are not always small.
I'm a bit underwhelmed with lie as a software engineering project. It's one
of the most opaque hunks of code I've ever looked at. I'd like to see this
be faster than a p-expect interface too. Lie doesn't have a library and it
doesn't look like much fun to make such an interface either. Although, it is
a very small package so it wouldn't be impossible to just beat it into shape.
I'm curious if other people have thought about this.
--
Joel
Mike Hansen
I've actually done a fair amount of work on this since then. I'm
waiting to put my changes up until I upgrade the combinat branch to
2.10.3. Take a look here for what the interface to the root system
code will feel like:
http://mupad-combinat.sourceforge.net/Wiki/RootSystems . Also, The
problems with dynkin_diagram are primarily due to graph visualization.
--Mike
William Stein
>
> I think this is probably all aimed at Mike Hansen.
>
> I've started looking at combinat/root_systems.py and combinat/cartan_type.py.
> It looks like there is still a lot to be done. I'm assuming that what needs
> to be done should be done via the optional (made standard) package lie. I
> have some questions.
>
> What is the difference between RootSystem and CartanType? For example, what
> methods should be in one class or the other? Or, should they all have
> methods like weyl_group, list_roots, dynkin_diagram and call each other?
>
> I like the dynkin diagram code that returns a DiGraph. However, to actually
> display the diagram, this isn't so nice. The graph show code doesn't
> indicate the double/triple bonds visually and so the graphics don't really
> look very reminiscient of what you would see in a book. The plot really
> shouldn't have axes. Perhaps this is all just a graph graphics bug.
Graphics plotting doesn't support anything for displaying
multiple edges yet (except loops). I would also like to be able to display
multiple edges for drawing graphs of Hecke operators
constructed using supersingular j-invariants.
Personally, asap I think that G.plot() for G a graph should give an error
if there are any multiple edges, instead of silently succeeding and
giving the wrong graph. Maybe G.plot(some option) would allow
plotting badly.
> For starters, I'd like to have two big pieces of new functionality. We need a
> way to enumerate the Weyl Group and the set of positive roots for a root
> system. I see that I can get this from lie so I think that makes sense as a
> first implementation. It seems that the only way to get these things from
> lie is to enumerate them all in memory as a list -- I'd rather have a more
> incremental approach as the Weyl groups are not always small.
>
> I'm a bit underwhelmed with lie as a software engineering project. It's one
> of the most opaque hunks of code I've ever looked at. I'd like to see this
> be faster than a p-expect interface too. Lie doesn't have a library and it
> doesn't look like much fun to make such an interface either. Although, it is
> a very small package so it wouldn't be impossible to just beat it into shape.
> I'm curious if other people have thought about this.
Is it actively developed anymore?
It's still not in Sage for a reason, though at the moment
I'm not sure exactly what that reason is. (Maybe just
lack of demand.)
--William
David Joyner
>
> On Wed, Mar 12, 2008 at 5:24 AM, Joel B. Mohler <jo...@kiwistrawberry.us> wrote:
> >
>
> >
> > I like the dynkin diagram code that returns a DiGraph. However, to actually
> > display the diagram, this isn't so nice. The graph show code doesn't
> > indicate the double/triple bonds visually and so the graphics don't really
See
http://trac.sagemath.org/sage_trac/ticket/2023
> > look very reminiscient of what you would see in a book. The plot really
> > shouldn't have axes. Perhaps this is all just a graph graphics bug.
>
>
>
> Is it actively developed anymore?
According to
http://www-math.univ-poitiers.fr/~maavl/LiE/
it appears not. BTW, it is LGPL'd.
William Stein
>
> On Wed, Mar 12, 2008 at 10:55 AM, William Stein <wst...@gmail.com> wrote:
> >
> > On Wed, Mar 12, 2008 at 5:24 AM, Joel B. Mohler <jo...@kiwistrawberry.us> wrote:
> > >
> >
>
> > >
>
> > > I like the dynkin diagram code that returns a DiGraph. However, to actually
> > > display the diagram, this isn't so nice. The graph show code doesn't
> > > indicate the double/triple bonds visually and so the graphics don't really
>
> See
> http://trac.sagemath.org/sage_trac/ticket/2023
>
>
> > > look very reminiscient of what you would see in a book. The plot really
> > > shouldn't have axes. Perhaps this is all just a graph graphics bug.
> >
>
> >
>
>
> >
>
> > Is it actively developed anymore?
>
> According to
> http://www-math.univ-poitiers.fr/~maavl/LiE/
> it appears not. BTW, it is LGPL'd.
>
OK, I downloaded the source code tarball and looked at the sources:
teragon:LiE was$ ls -lt *.c *.h
-rw-r--r--@ 1 was was 180 Sep 2 2003 non-ANSI.c
-rw-r--r--@ 1 was was 4029 Dec 11 2000 output.c
-rw-r--r--@ 1 was was 8161 Jun 9 2000 ansi.h
-rw-r--r--@ 1 was was 8887 Apr 18 2000 poly.c
-rw-r--r--@ 1 was was 742 Apr 12 2000 creatop.c
-rw-r--r--@ 1 was was 1932 Apr 7 2000 getl.c
-rw-r--r--@ 1 was was 5827 Apr 4 2000 learn.c
-rw-r--r--@ 1 was was 12275 Apr 4 2000 bigint.c
-rw-r--r--@ 1 was was 4078 Aug 24 1999 binmat.c
-rw-r--r--@ 1 was was 519 Oct 24 1996 infolrn.h
-rw-r--r--@ 1 was was 85 Oct 23 1996 getl.h
-rw-r--r--@ 1 was was 40 Aug 30 1996 date.c
The time stamps for all but one of the files are 8 - 12 years old!
There's no way LiE -- as it is now -- is going to become a
standard package in Sage (optional is fine, of course).
The only way would be if somebody were to officially take over
the project and start making releases, etc.
-- William
Joel B. Mohler
> > I'm a bit underwhelmed with lie as a software engineering project. It's
> > one of the most opaque hunks of code I've ever looked at. I'd like to
> > see this be faster than a p-expect interface too. Lie doesn't have a
> > library and it doesn't look like much fun to make such an interface
> > either. Although, it is a very small package so it wouldn't be
> > impossible to just beat it into shape. I'm curious if other people have
> > thought about this.
>
> Is it actively developed anymore?
>
> It's still not in Sage for a reason, though at the moment
> I'm not sure exactly what that reason is. (Maybe just
> lack of demand.)
I don't know for sure about it's status, but it's web page seems to
acknowledge that 2000 was about the end for any serious work. It seems to be
the canonical computational reference for these topics for at least a few
people. I suppose that means it might be a worthwhile project to make a list
of the main features/algorithms and make sure that sage either includes them
or exceeds them so that we can state that sage is a viable migration path.
Given that the upstream maintenance appears sporadic (at best), I think it
might make sense to make a new release providing a C interface to the best
bits. Of course, someone has to care enough to give it this sort of love.
The best part about LiE is the manual.dvi found in the tarball. It is a very
comprehensible and comprehensive guide to computing with weight lattices and
weyl groups (and that probably should be taken with a grain of salt since
this is rather out of my circle of expertise.)
--
Joel
William Stein
>
> On Wednesday 12 March 2008 10:55, William Stein wrote:
> > > I'm a bit underwhelmed with lie as a software engineering project. It's
> > > one of the most opaque hunks of code I've ever looked at. I'd like to
> > > see this be faster than a p-expect interface too. Lie doesn't have a
> > > library and it doesn't look like much fun to make such an interface
> > > either. Although, it is a very small package so it wouldn't be
> > > impossible to just beat it into shape. I'm curious if other people have
> > > thought about this.
> >
> > Is it actively developed anymore?
> >
> > It's still not in Sage for a reason, though at the moment
> > I'm not sure exactly what that reason is. (Maybe just
> > lack of demand.)
>
> I don't know for sure about it's status, but it's web page seems to
> acknowledge that 2000 was about the end for any serious work. It seems to be
Yep. 2000 is the most recent change date on any of the files (except one).
> the canonical computational reference for these topics for at least a few
> people. I suppose that means it might be a worthwhile project to make a list
> of the main features/algorithms and make sure that sage either includes them
> or exceeds them so that we can state that sage is a viable migration path.
Excellent plan. Who knows, maybe we can do a much better job at implementing
the same functionality, given all that Sage already can do (i.e. fast
linear algebra,
etc.).
> Given that the upstream maintenance appears sporadic (at best),
Given the file timestamps I think there is no upstream maintenance at all.
> I think it
> might make sense to make a new release providing a C interface to the best
> bits. Of course, someone has to care enough to give it this sort of love.
Yes. But keep in mind it will remain an optional spkg.
> The best part about LiE is the manual.dvi found in the tarball. It is a very
> comprehensible and comprehensive guide to computing with weight lattices and
> weyl groups (and that probably should be taken with a grain of salt since
> this is rather out of my circle of expertise.)
That will be very helpful when creating a plan for what we would want in
a new version. Also, one should look closely at what Magma (and GAP?)
can do involving LiE groups. In particular, I bet Magma can do a lot,
though I've never personally looked -- it just seems like yet another one
of the sort of things that Magma would be "by far the best in the world" at.
Off Topic: By the way:
(1) Magma takes a very structured algebraic approach to mathematical
objects, while still being practical, and
(2) In a huge number of cases Magma is the best at the world at things.
There's probably a strong relation between (1) and (2). This is a good
argument in support of Sage following (1) for the most part, which Sage
does.
William
Justin C. Walker
I just tripped over this "package": AllTypes (<http://
www.alltypes.de>). It's entirely web-based, and it does not appear to
be open, but it seems to be kept up to date. It's referenced in
"Algorithmic Lie Theory for Solving Ordinary Differential
Equations" by F. Schwarz.
I don't think AllTypes is Lie-specific, but it might be worth finding
out what's behind it, and if there's anything there to be "shared".
The website gives you a "signup" option; filling in the details gets
you a response with a password, and you can use it (again: seems to be
only web-based).
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------
Daniel Bump
I'm cross-posting this to sage-devel and sage-combinat. I know
that's a mailing list no-no and I promise not to do it again
but I think there's people on both lists that I'm writing this to.
The original thread was started by Joel Mohler on March 12.
> For starters, I'd like to have two big pieces of new functionality. We need a
> way to enumerate the Weyl Group and the set of positive roots for a root
> system. I see that I can get this from lie so I think that makes sense as a
> first implementation. It seems that the only way to get these things from
> lie is to enumerate them all in memory as a list -- I'd rather have a more
> incremental approach as the Weyl groups are not always small.
Some of this is in Sage-3.0.alpha0.
sage: L = RootSystem(['E',8]).ambient_lattice()
sage: sage: L.positive_roots()
[(1, 1, 0, 0, 0, 0, 0, 0),
(1, 0, 1, 0, 0, 0, 0, 0),
(1, 0, 0, 1, 0, 0, 0, 0),
... snip ...
Second fundamental representation of F4:
sage: WeylDim(['F',4],[0,1,0,0])
1274
Currently (thanks to Justin for the exceptional groups) all root system
are in Sage. They use the Bourbaki convention, not the Dynkin one
for ordering the fundamental weights. These only differ for types
G and E.
You can also build the crystal graph of any representation
for Cartan types A,B,C,D, and G2. This allows you to do
tensor product decompositions, though I won't explain how
right here.
Enumerating the Weyl group would need to be implemented.
Nicolas Thiery wrote:
> > and from this, it seems that the alternatives above could both be
> > considered "canonical": the first is the Bourbaki numbering. The
> > second is the Dynkin numbering.
>
> So far in MuPAD-Combinat, we have taken the Kac convention (although I
> really don't like it for twisted affine). We should definitely add at
> some point an option Bourbaki that would give the other convention (by
> simply applying a permutation to the nodes of the dynkin diagram).
The rest of this message was posted to the sage-combinat
list, but here it is again.
One question is how Weyl characters are to be represented.
A Weyl character is essentially an element of the group
algebra for the weight lattice, which is an infinite abelian group.
This ring could also be represented as an element of a ring of
Laurent polynomials, and some start was made on Laurent
polynomials by Jason Bandlow, David Roe and Mike Hanson.
In any case, I would like the coefficient module to be
an arbitrary commutative ring rather than just ZZ.
In other words, if G is a Lie group of rank r, T its maximal
torus, the Weyl character lives in the group algebra
over X*(T) = ZZ^r, which is the group of rational characters
of T. Any W-invariant element of this group algebra
is a linear combination of Weyl characters. The group
algebra of X*(T) is isomorphic to the ring of Laurent
polynomials with ZZ coefficients, but I'd like the
coefficients to be allowed in an arbitrary commutative
ring, for example a polynomial ring in an auxiliary
variable q.
Once the ring in which the Weyl characters live is
implemented, they could be computed using the Freudenthal
multiplicity formula. There is also a map from the
crystal to X*(T), which is the weight map. It is
actually already implemented.
sage: C = CrystalOfLetters(['D',4])
sage: v = C.list()[0]
sage: v.weight()
(1, 0, 0, 0)
For small representations, the crystal could thus
be used to compute the Weyl character, but this
would be more efficiently done using the
Freudenthal multiplicity formula.
Dan