On Feb 10, 1:34 pm, Daniel Bump <b...@match.stanford.edu> wrote:
> Here are some comments on #10744.
>
> Very nice!
>
> I do have some comments.
Thanks, and I appreciate the feedback!
>
> sage: A2=WeylCharacterRing("A2",style="coroots")
> sage: a2=WeightRing(A2)
> sage: rp=a2(A2(2,1))
> sage: rp.plot()
>
> Frequently one will want to call this for the character of
> a representation. It would be good if one could:
>
> A2(2,1).plot()
>
> without having to create the weight ring. Of course some
> times one might also want to be able to call it on an
> element of the weight ring that is not W invariant (and
> which could therefore not be coerced into the WeylCharacterRing).
>
> I guess to accomplish this one could have to move some of the code
> into an auxiliary method of the WeylCharacterRing that would be
> called by plot methods of both the Weyl character ring and the
> weight ring.
I agree, it would be good to be able to call `plot` directly on a
WeylCharacter. I guess one option would be to add a `plot` method to
that class which creates a WeightRingElement and returns the plot from
there. Or maybe it would make more sense to house the code for plot
outside of both classes? The data that plot needs is basically the
multiplicity list and the CartanType.
Where do people think the main code for plotting should go? In
WeightRingElement, WeylCharacterRing, or in weyl_character.py but
outside of any class (and have plot methods in both classes that call
this function?)
>
> Here is a more serious criticism.
>
> A grid is shown whose vertices are the weights.
>
> But this grid is not invariant under the action of the Weyl group!
> Although the grid that you've shown does pass through the weight
> lattice, it is sort of unnatural for this reason. The grid
> you've shown is one whose fundamental domain is the
> parallelogram spanned by the fundamental weights, but since it is
> not W invariant I think it is bad to use this grid.
>
> A more natural and useful grid would be the one that passes through
> the hyperplanes where the coroots take integer values. This is the
> Stieffel diagram for the dual weight root system. Like the
> grid you showed it is a grid whose vertices are the weights, but
> unlike the one your code displays it is W-invariant.
>
> It would also be good to be able to see the hyperplanes where the
> roots take integer values. This is the Stieffel diagram. Then
> you can see pictures of the fundamental alcoves.
>
> It would be good to be able to see these grids, but not by default,
> since I think they make things too cluttered. Since I'm proposing
> two optional methods showing the fundamental alcoves and dual
> alcoves, maybe the name should be changed.
You're absolutely right. I should have thought about this more
carefully. This is a simple change I can make. How about having two
options `alcoves` and `dual_alcoves`, both of which default to False
and produce a grid in a similar style (each having different colors)
when set to True?
>
> It seems to me (in the A2 case) that the root arrows are perfectly
> placed, but the pink arrows corresponding to the fundamental
> weights fall short of where they should. Especially the second
> fundamental weight which points straight up. And maybe the pink
> arrows are too thick.
>
> It seems to me that the pictures are wider than tall. This is
> particularly obvious for B2 and C2 since the lattices are
> supposedly square.
I think the issue here is the aspect_ratio of the plots. In the
docstring examples I call show( ..., aspect_ratio=1 ) and the pictures
look proportionally correct to me (B2 and C2 are square). I should
just enforce the aspect_ratio = 1 when returning the plots. The pink
arrows are probably too thick, that's an easy change.
> I looked at the B2,C2 and G2 pictures of irreducible
> characters. For G2 the weight multiplicities get large fast, and
> I'm not sure whether some tuning of the default dot size might be
> profitable, at least for G2. One idea would be that the dot size
> could be proportional to the square root of the multiplicity.
> (I'm not sure how well this would work, just an idea.)
The G2 multiplicities do grow quickly. This is what I intended the
`mult_scale` option is for, so for example you could call
ch.plot( mult_scale = lambda m: ceil(5*sqrt(m)) )
or something like that. I think it would make sense to set the default
scaling based on the Cartan type. I'll play around with different
scalings for each type and see what makes sense.
>
> Dan
Thanks again for the input. I'll report back with some changes.
--
Benjamin Jones
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
