Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
On Sat, Mar 10, 2012 at 02:04:44PM +0100, Christian Stump wrote: Christian: I had to slightly rebase trac_11187-finite_reflection_groups-cs.patch for the doctests I just added to apply_simple_reflection and friends. This time I rebased nonnesting_partitions-cs.patch which was touching RootLatticeRealizations whose file got renamed and reindented. Hopefully the root system patch is now finished! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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.
Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
Hi Anne, On Fri, Mar 09, 2012 at 04:09:13PM -0800, Anne Schilling wrote: Impressive patch! Thanks for working on this. :-) Thanks so much for your very useful and quick review. I really appreciate that! Followup on http://trac.sagemath.org/sage_trac/ticket/6588 Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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.
Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
Christian: I had to slightly rebase trac_11187-finite_reflection_groups-cs.patch for the doctests I just added to apply_simple_reflection and friends. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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.
Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
Hi -- as you are currently discussing root systems (including 6588, thanks a lot for working on that!): here are some issues that made it very hard for me to work with root systems for finite reflection groups: # the first and the second seem to behave very differently: sage: x = CartanType([['A',4]]) sage: type(x) class 'sage.combinat.root_system.type_reducible.CartanType_with_superclass' sage: x.is_irreducible() False sage: x = CartanType(['A',4]) sage: type(x) class 'sage.combinat.root_system.type_A.CartanType' sage: x.is_irreducible() True # there is a typo here (a double ll in the middle): sage: x.is_crystalographic() True # the standard index set is not python/sage convention, is that on purpose? sage: x.index_set() [1, 2, 3, 4] # the convention for the exceptional node in types B/C is the other choice that in chevie (compare http://www.math.jussieu.fr/~jmichel/gap3/htm/chap071.htm): sage: x = CartanType(['B',4]) sage: x.dynkin_diagram() O---O---O==O 1 2 3 4 B4 # the roots are accessible only in the root space, my impression is that a root system has roots, why not having a method there calling them? # the order in which the roots are given comes from the backtracker: sage: x = CartanType(['A',4]) sage: r = x.root_system().root_space() sage:. r.positive_roots() sage.combinat.backtrack.TransitiveIdeal sage: [ beta for beta in r.positive_roots() ] [alpha[2], alpha[2] + alpha[3], alpha[1], alpha[3], alpha[1] + alpha[2], alpha[1] + alpha[2] + alpha[3], alpha[2] + alpha[3] + alpha[4], alpha[4], alpha[3] + alpha[4], alpha[1] + alpha[2] + alpha[3] + alpha[4]] # it would be great if we were able to get the same order as obtained from chevie, as this gives directly the permutation representation of the corresponding Coxeter group (acting on positions of roots). finally, the non-crystallographic types are missing. using the universal cyclotomic field we should also be able to get these root systems into sage. I would be happy to work on (parts of) the things above, but first wanted to hear what might be good to get into 6588, and your opinion on others. Best, Christian -- 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.
Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
Hi Christian, as you are currently discussing root systems (including 6588, thanks a lot for working on that!): here are some issues that made it very hard for me to work with root systems for finite reflection groups: # the first and the second seem to behave very differently: sage: x = CartanType([['A',4]]) sage: type(x) class 'sage.combinat.root_system.type_reducible.CartanType_with_superclass' sage: x.is_irreducible() False sage: x = CartanType(['A',4]) sage: type(x) class 'sage.combinat.root_system.type_A.CartanType' sage: x.is_irreducible() True This is definitely strange. # there is a typo here (a double ll in the middle): sage: x.is_crystalographic() True Please fix this! # the standard index set is not python/sage convention, is that on purpose? sage: x.index_set() [1, 2, 3, 4] I think this is intentional. The nodes in the Dynkin diagram are labeled 1,2,...,rank of g. # the convention for the exceptional node in types B/C is the other choice that in chevie (compare http://www.math.jussieu.fr/~jmichel/gap3/htm/chap071.htm): sage: x = CartanType(['B',4]) sage: x.dynkin_diagram() O---O---O==O 1 2 3 4 B4 There are many different conventions. I think in sage the default is the one used in Kac. There is also a relabeling option if you want to use a different convention. # the roots are accessible only in the root space, my impression is that a root system has roots, why not having a method there calling them? I am confused. This also exists for other spaces: sage: R = RootSystem(['A',4]) sage: R.weight_lattice().roots() [-Lambda[2] + 2*Lambda[3] - Lambda[4], -Lambda[1] + Lambda[2] + Lambda[3] - Lambda[4], 2*Lambda[1] - Lambda[2], -Lambda[1] + 2*Lambda[2] - Lambda[3], Lambda[1] + Lambda[2] - Lambda[3], -Lambda[1] + Lambda[2] + Lambda[4], Lambda[1] + Lambda[3] - Lambda[4], -Lambda[2] + Lambda[3] + Lambda[4], -Lambda[3] + 2*Lambda[4], Lambda[1] + Lambda[4], Lambda[2] - 2*Lambda[3] + Lambda[4], Lambda[1] - Lambda[2] - Lambda[3] + Lambda[4], -2*Lambda[1] + Lambda[2], Lambda[1] - 2*Lambda[2] + Lambda[3], -Lambda[1] - Lambda[2] + Lambda[3], Lambda[1] - Lambda[2] - Lambda[4], -Lambda[1] - Lambda[3] + Lambda[4], Lambda[2] - Lambda[3] - Lambda[4], Lambda[3] - 2*Lambda[4], -Lambda[1] - Lambda[4]] sage: R.root_lattice().roots() [alpha[2], alpha[2] + alpha[3], alpha[1], alpha[3], alpha[1] + alpha[2], alpha[1] + alpha[2] + alpha[3], alpha[2] + alpha[3] + alpha[4], alpha[4], alpha[3] + alpha[4], alpha[1] + alpha[2] + alpha[3] + alpha[4], -alpha[2], -alpha[2] - alpha[3], -alpha[1], -alpha[3], -alpha[1] - alpha[2], -alpha[1] - alpha[2] - alpha[3], -alpha[2] - alpha[3] - alpha[4], -alpha[4], -alpha[3] - alpha[4], -alpha[1] - alpha[2] - alpha[3] - alpha[4]] I would be happy to work on (parts of) the things above, but first wanted to hear what might be good to get into 6588, and your opinion on others. As far as I understand Nicolas would like to finish this patch soon. If there are some things that can be implemented quickly, why don't you write a quick patch on top of Nicolas? Otherwise it might be better to open a new ticket. Best, Anne -- 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.
Re: [sage-combinat-devel] Re: the unfortunate case of affine type A twisted
Hi Nicolas,
Impressive patch! Thanks for working on this.
Here are some first comments:
- In /sage/categories/affine_weyl_groups.py there is a new import
from sage.categories.infinite_enumerated_sets import InfiniteEnumeratedSets
which is not used. Please either remove this line or add InfiniteEnumeratedSets
in the class (which is probably preferable).
- In /sage/categories/affine_weyl_groups.py please add a `TestSuite(s).run()`
doctest.
- I am not sure this is related to the patch, but there are some
strange methods in /sage/categories/coxeter_groups.py without doctests:
@abstract_method(optional = True)
def has_right_descent(self, i):
Returns whether i is a right descent of self.
#EXAMPLES::
#
#sage:
def has_left_descent(self, i):
Returns whether `i` is a left descent of self.
This default implementation uses that a left descent of
`w` is a right descent of `w^{-1}`.
return (~self).has_right_descent(i)
Should has_left_descent also be an abstract_method? Or is that implicit through
has_right_descent?
- Why is the cateogry RootLatticeRealization in
/sage/combinat/root_system/root_lattice_realization.py
here and not in categories (if it is a category as specified in the docstring)?
The same question holds for WeightLatticeRealizations(Category_over_base_ring)
in /sage/combinat/root_system/weight_lattice_realization.py.
- When using the extended weight lattice, the list of fundamental weights
does not include `\delta`. On the other hand it is possible to input
`\delta` into the method fundamental_weight. This seems a little inconsistent.
{{{
sage: Q = RootSystem(['A', 3, 1]).weight_lattice(extended = True); Q
Extended weight lattice of the Root system of type ['A', 3, 1]
sage: Q.fundamental_weights()
Finite family {0: Lambda[0], 1: Lambda[1], 2: Lambda[2], 3: Lambda[3]}
sage: Q.fundamental_weight('delta')
delta
}}}
Also, I posted a first reviewer's patch on sage-combinat with mostly just
trivial changes and some extra doc tests. Please fold it if you are satisfied.
Thanks!
Anne
On 3/9/12 1:18 AM, Nicolas M. Thiery wrote:
Hi Mark,
On Thu, Mar 08, 2012 at 11:01:59PM -0500, msh...@math.vt.edu wrote:
Unfortunately, in type A_{2n}^{(2)}, the implementation of the
extended weight lattice is (slightly) incorrect.
The usual definition of delta in general is the linear
combination of simple roots whose coefficients are given by the
unique relatively prime tuple of positive integers
which give a linear dependence on the columns of the Cartan matrix
(where the i,j-th entry is the pairing of alpha_i^\vee with alpha_j).
In type A_4^{(2)} we have
delta = 2 alpha_0 + 2 alpha_1 + alpha_2.
Therefore
alpha_0 = delta/2 - alpha_1 - 1/2 alpha_2
= delta/2 - 2 Lambda_0 - Lambda_1.
Note that the 1/2 alpha_2 is ok: other than delta/2
you get no denominator.
In other words, in this unfortunate root system,
the Z-basis of the extended weight lattice
consists of the fundamental weights and delta/2.
In every other affine root system the extra generator is delta,
that is, the coefficient of alpha_0 in delta is 1.
Awkward to fix (making delta/2 the
basis element) but it is the standard notation.
The implementation is in fact correct (computationally speaking):
sage: L=RootSystem([A,4,2]).weight_lattice(extended=True)
sage: L.null_root()
2*delta
Granted, the output is suboptimal: naming delta the basis element
used to perturbate the simple root for the special node is a slight
abuse since, as you point out, in the literature, delta is instead
the null root. A trivial workaround would be to tweak _repr_monomial
and _latex_monomial to *output* that basis element as delta/2 for
A_2n^(2). A better fix would be to choose a type free name for this
basis element, to be used for:
- output
- indexing the basis element (as in the current L.basis()[delta])
A further guide for choosing that name is that we want it to admit
natural generalizations for Kac-Moody where we will need more basis
elements to perturbate more simple roots (something like delta_0,
delta_1, ...).
I do claim that their is strong value in keeping the code as type-free
as possible (it currently is completely type free up to a single
thing: the choice of the special node which is hard coded in the
predefined affine Cartan Type). By the way, as a personal opinion, the
literature would be far more accessible to newcomers if it was written
in a more type free way, without all those nitty-gritty type specific
details that are impossible to all keep in mind at once. But that's a
different discussion.
Now for the practical aspect: I have added the following warning to
the documentation:
.. warning::
By a slight notational abuse, the extra basis element used to
