#15703: Refactor Coxeter groups as matrix groups and non crystallographic root
systems
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.2
Component: combinatorics | Resolution:
Keywords: coxeter groups, | Merged in:
days57 | Reviewers: Nicolas M. Thiéry
Authors: Jean-Philippe | Work issues:
Labbé, Vivien Ripoll | Commit:
Report Upstream: N/A | 2846f67039fe6baf568fe3ffebdb675fba9ba091
Branch: | Stopgaps:
u/vripoll/refactor_coxeter_groups_as_matrix_groups_and_non_crystallographic_root_systems|
Dependencies: #16120, #16126, |
#16130 |
-------------------------------------+-------------------------------------
Description changed by jipilab:
Old description:
> This is a follow up to #9290.
>
> * Experiment with the infrastructure scales and benchmark
>
> Here is a goal picture (benchmark.png) given by the Coxeter matrix
> [[1,oo,2,5],[oo,1,6,2],[2,6,1,-1.1],[5,2,-1.1,1]]. It represents the
> limit roots of the elements of infinite order of length 3 and 4, and
> their orbits under the actions of elements of length smaller or equal to
> 5. There are 12212 drawn limits. (Not showing 66 limit roots that created
> approximation errors coming from a "to be looked at" usage of solve in my
> code). With a homemade implementation, it took 42 seconds to do the
> computations of everything from scratch and also the computation of the
> tetrahedron and the light cone.
>
> The picture named benchmark2.png shows an image produced with sage
> with hacks and tweaks. It took around 10 minutes to compute. There are
> 2347 roots shown. (There was a problem in the production of the roots
> located at (0,0,0)) These roots is formed as the union of the inversion
> sets of the elements of length at most 8 obtained via the weak order
> poset.
>
> * CoxegerGraph, see #16126
> - Create a class similar to DynkinDiagram
> Starter: an edge-labeled graph.
> - Edge labels: m_{i,j}, possibly with number <-1 for oo
> - method dynkin_diagram() which builds the cartan matrix for the
> geometric representation
> Starter: just make this a function
>
> * Update DynkinDiagram to support non crystallographic case:
> - Add an argument base_ring to the constructor
> - Add a method base_ring
> - Make add_edge honor this method when automatically adding edges
> - Update cartan_matrix() to use the base_ring
> - Add a method _test_base_ring that checks that all edge labels are
> indeed in this base ring
> - Implement is_crystallographic testing if the base ring is ZZ
> - Add an argument symmetric=False to the constructor, and make
> add_edge and symmetrizer use it.
> - Add a method _test_dynkin_diagram that tests that the Dynkin
> diagram indeed defines a proper root system. See in particular
> cartan_matrix.is_generalized_cartan_matrix.
>
> * Update CartanMatrix
> - Add a base ring argument to the constructor
> - Update is_crystallographic
> - Update is_affine
> - Update is_finite
> - Update is_generalized_cartan_matrix
>
> * CartanType
> - Possibly update to accept appropriate data to build a CoxeterDiagram
> (e.g. a matrix)
> - Add a base_ring method?
> - Decide on the semantic of is_crystallographic (symmetrizable or
> not?), and if possibly add an is_... method to decide whether the
> entries are integral or not.
> - Provide a dynkin_diagram method that builds the Dynkin diagram
> from the Coxeter diagram when available
> - Test: H_3 and friends should have a working dynkin_diagram method
>
> * RootSystem
> - Decide on the meaning of root_lattice: either disable it in the
> non integral case, or have it be the span of the roots over the
> smallest available ring.
>
> * RootLatticeRealizations:
> - Feed this to RootSystem, and check that the root space and weight
> space are built properly.
> - Rename the weyl_group method to reflection_group, with an alias
> from weyl_group; update the setting of the category.
> - Long run: stuff specific to the crystallographic case, starting
> with this weyl_group method, should go in
> RootLatticeRealizations.Crystallographic. That's for a follow up
> ticket on using axioms for root systems; but let's not depend on
> #10963 right now.
>
> * RootSpace (for this ticket or some follow up):
> - Define the inner product
> - Signature of the bilinear form
>
> * CoxeterMatrixGroup and WeylGroup:
> - Refactor WeylGroup to make it a subclass of CoxeterMatrixGroup,
> and lift as many features as possible from WeylGroup to
> CoxeterMatrixGroup.
> - Check that, with a proper Dynkin diagram, the conversion to GAP
> issue does not appear
> - Now or later: we probably want the Weyl group elements to be
> represented by Sage matrices, but keep a handle to the
> corresponding Gap group. Currently one has to make a choice
> between MatrixGroup_generic and MatrixGroup_gap.
>
> * Update WeylGroups:
> - inversions: use the "root_lattice" by default?
>
> * Prerequisites:
> - Add a __float__ method to UCF, see #16120
>
> Tests:
>
> {{{
> sage: C = CoxeterDiagram(...) # good name? or
> CartanDatum(coxeter_matrix=...) [1] ? or?
> sage: L = RootSystem(C).root_space()
> sage: W = L.reflection_group()
> sage: W = CoxeterGroup(['H',3])
> sage: W.domain()
> }}}
> Sage Days 57 in Cernay will be a good occasion to work on this.
>
> Follow ups: #16087
>
> [1]: Generally speaking, it's planned to rename CartanType to
> CartanDatum.
New description:
This is a follow up to #9290.
* Experiment with the infrastructure scales and benchmark
Here is a goal picture (benchmark.png) given by the Coxeter matrix
[[1,oo,2,5],[oo,1,6,2],[2,6,1,-1.1],[5,2,-1.1,1]]. It represents the limit
roots of the elements of infinite order of length 3 and 4, and their
orbits under the actions of elements of length smaller or equal to 5.
There are 12212 drawn limits. (Not showing 66 limit roots that created
approximation errors coming from a "to be looked at" usage of solve in my
code). With a homemade implementation, it took 42 seconds to do the
computations of everything from scratch and also the computation of the
tetrahedron and the light cone.
The picture named benchmark2.png shows an image produced with sage with
hacks and tweaks. It took around 10 minutes to compute. There are 2347
roots shown. (There was a problem in the production of the roots located
at (0,0,0)) These roots is formed as the union of the inversion sets of
the elements of length at most 8 obtained via the weak order poset.
* CoxegerGraph, see #16126
- Create a class similar to DynkinDiagram
Starter: an edge-labeled graph.
- Edge labels: m_{i,j}, possibly with number <-1 for oo
- method dynkin_diagram() which builds the cartan matrix for the
geometric representation
Starter: just make this a function
* Update DynkinDiagram to support non crystallographic case:
- Add an argument base_ring to the constructor
- Add a method base_ring
- Make add_edge honor this method when automatically adding edges
- Update cartan_matrix() to use the base_ring
- Add a method _test_base_ring that checks that all edge labels are
indeed in this base ring
- Implement is_crystallographic testing if the base ring is ZZ
- Add an argument symmetric=False to the constructor, and make
add_edge and symmetrizer use it.
- Add a method _test_dynkin_diagram that tests that the Dynkin
diagram indeed defines a proper root system. See in particular
cartan_matrix.is_generalized_cartan_matrix.
- adapt column() and row() method to give the labels in the base ring
* Update CartanMatrix
- Add a base ring argument to the constructor
- Update is_crystallographic
- Update is_affine
- Update is_finite
- Update is_generalized_cartan_matrix
* CartanType
- Possibly update to accept appropriate data to build a CoxeterDiagram
(e.g. a matrix)
- Add a base_ring method?
- Decide on the semantic of is_crystallographic (symmetrizable or
not?), and if possibly add an is_... method to decide whether the
entries are integral or not.
- Provide a dynkin_diagram method that builds the Dynkin diagram
from the Coxeter diagram when available
- Test: H_3 and friends should have a working dynkin_diagram method
* RootSystem
- Decide on the meaning of root_lattice: either disable it in the
non integral case, or have it be the span of the roots over the
smallest available ring.
* RootLatticeRealizations:
- Feed this to RootSystem, and check that the root space and weight
space are built properly.
- Rename the weyl_group method to reflection_group, with an alias
from weyl_group; update the setting of the category.
- Define a new projection "transversal" to visualise root systems (and
find a right name for it)
- Long run: stuff specific to the crystallographic case, starting
with this weyl_group method, should go in
RootLatticeRealizations.Crystallographic. That's for a follow up
ticket on using axioms for root systems; but let's not depend on
#10963 right now.
* RootSpace (for this ticket or some follow up):
- Define the inner product
- adapt the is_positive_root to make it work for any base ring
- Signature of the bilinear form
* CoxeterMatrixGroup and WeylGroup:
- Refactor WeylGroup to make it a subclass of CoxeterMatrixGroup,
and lift as many features as possible from WeylGroup to
CoxeterMatrixGroup.
- Check that, with a proper Dynkin diagram, the conversion to GAP
issue does not appear
- Now or later: we probably want the Weyl group elements to be
represented by Sage matrices, but keep a handle to the
corresponding Gap group. Currently one has to make a choice
between MatrixGroup_generic and MatrixGroup_gap.
* Plotting:
- add a family_of_points method in the projections to be used by the
"transversal projection"
* Update WeylGroups:
- inversions: use the "root_lattice" by default?
* Prerequisites:
- Add a __float__ method to UCF, see #16120
Tests:
{{{
sage: C = CoxeterDiagram(...) # good name? or
CartanDatum(coxeter_matrix=...) [1] ? or?
sage: L = RootSystem(C).root_space()
sage: W = L.reflection_group()
sage: W = CoxeterGroup(['H',3])
sage: W.domain()
}}}
Sage Days 57 in Cernay will be a good occasion to work on this.
Follow ups: #16087
[1]: Generally speaking, it's planned to rename CartanType to CartanDatum.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/15703#comment:19>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
