Changes between Version 9 and Version 10 of SageCombinatChevieStatusReport


Ignore:
Timestamp:
08/03/10 18:28:47 (11 years ago)
Author:
nthiery
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SageCombinatChevieStatusReport

    v9 v10  
    1313 * Jean Michel, DR, CNRS, Université Paris 7
    1414 * Viviane Pons, graduate student, LIGM, Université Paris-Est
    15  * Nicolas Thiéry, MdC, Orsay
     15 * Nicolas M. Thiéry, MdC, Orsay
    1616
    1717== Sage introduction ==
     
    2929
    3030== GAP and Sage ==
    31 Many discussions, in particular with Frank Lübeck, went around  the differences in the design and development strategy between GAP and sage. In very very short: Sage goes further in the modeling of mathematics at the potential price of complexity. GAP's development is of cathedral type, with an emphasis on packages, whereas Sage's goes for bazaar and shared ownership of the code. Everybody agrees on the relative merits of both strategies; everybody has his own belief about which one is more likely to succeed in the long run.
     31Many discussions, in particular with Frank Lübeck, went around  the differences in the design and development strategy between GAP and Sage. In very very short: Sage goes further in the modeling of mathematics at the potential price of complexity. GAP's development is of cathedral type, with an emphasis on packages, whereas Sage's goes for bazaar and shared ownership of the code. Everybody agrees on the relative merits of both strategies; everybody has his own belief about which one is more likely to succeed in the long run.
    3232
    3333Also the release strategies are different. New GAP code can sometimes  take  time to become available to the user community, while Sage  has frequent releases containing a lot of very new code.  The Sage approach is good for people who want to use the new code, but it is more likely that code and interfaces will change later.
     
    6262  Altogether, there is no urgency in porting code from Chevie just for the sake of making it run; however the difficulty of e.g. having a 64-bit version of GAP3 means that a port will become necessary some day  (in a few years?); when a complete port exists to another system one can expect the new developments to occur there.
    6363
    64   A remark on the license of GAP 3: the usage conditions of GAP 3 are more restrictive than GPL (see the doc/manual.* in GAP 3), and Frank evaluated that is would be close to impossible to change this. We suggest to make GAP 3 with Chevie an optional Sage spkg.
     64  A remark on the license of GAP 3: the usage conditions of GAP 3 are more restrictive than GPL (see the doc/manual.* in GAP 3), and Frank evaluated that it would be close to impossible to change this. We suggest to make GAP 3 with Chevie an optional Sage spkg.
    6565
    6666 * A variant of the core code for reflection groups and their representations will at some stage also become available in GAP 4 (and much more on representations of algebraic groups and groups of Lie type, ...). Some functionality in this direction is already available in the context of Lie algebras, see, e.g., http://www.gap-system.org/Manuals/doc/htm/ref/CHAP061.htm#SECT007.
     
    9292 * #9288: General (complex) reflection groups: the current implementation of Coxeter groups in Sage is in principle designed to open the door for such generalizations. In fact, even if this is not directly apparent, much of Sage's design was directly inspired from Chevie's. This should be better acknowledged.
    9393
    94   Jean is interested in this feature, and generally speaking about exploring the possibility of porting parts of Chevie to sage and/or of making the design of these features in sage compatible enough with Chevie to allow a port.
     94  Jean is interested in this feature, and generally speaking about exploring the possibility of porting parts of Chevie to Sage and/or of making the design of these features in Sage compatible enough with Chevie to allow a port.
    9595
    9696 * Representation theory of Coxeter/reflection groups: porting Chevie's data collections (and/or smoothly interfacing to them as a temporary measure) would definitely make sense. On the other hand algorithms for representations of general groups really belong to GAP 4. Much needs to be done to better expose such features in Sage, in particular around character tables (see #9293)!
     
    104104   * Potential collaboration with Dehornoy
    105105   * A notion of braid group exists for every finite complex reflection group
    106    * Implementation: Braid group elements have a canonical normal form, which is a concatenation of reduced words for the corresponding Coxeter group (because, they are unique quotients of elements of the braid monoid, and each of them as a unique maximal factor).
     106   * Implementation: Braid group elements have a canonical normal form, which is a concatenation of reduced words for the corresponding Coxeter group (because they are unique quotients of elements of the braid monoid, and each of them as a unique maximal factor).
    107107
    108108 * GarsideWords (generalization of braid monoids)
     
    123123  My main aim to to compute the decomposition matrices of these algebras. This is closely related to computing the (semi/quasi/...) canonical bases  in the combinatorial Fock spaces. I view the (images of the) PIMs, Specht modules, Young modules and simple modules as special cases of the Fock spaces/Grothendieck group and the decomposition matrices give the transition matirces between them. One of the main "achivements" of the Specht package was that it could, within limits, inductively compute the decomposition matrices of the symmetric groups and its Hecke algebras. It  did this by inducing the simple and projective modules in the Fock space and then using a lot of representation theory to decompose these modules. Now that these algebras are known to be Z-graded this adds some extra traction to these computations.
    124124
    125   As I already have a working platform for these calculations in gap, and time is short, my plan is to re-implement this code in sage as I need it. So it might be quite a slow project. Implementing the Fock spaces is very quick. Computing the canonical bases in level 1 is almost trivial, whereas for higher levels this will require more work. The crystal graph machinery I can write very quickly. Implementing decomposition matrices as labelled matrices is again easy, but sage probably provides a better mechanism for displaying them than this.
     125  As I already have a working platform for these calculations in gap, and time is short, my plan is to re-implement this code in Sage as I need it. So it might be quite a slow project. Implementing the Fock spaces is very quick. Computing the canonical bases in level 1 is almost trivial, whereas for higher levels this will require more work. The crystal graph machinery I can write very quickly. Implementing decomposition matrices as labelled matrices is again easy, but Sage probably provides a better mechanism for displaying them than this.
    126126
    127   In addition to working with the Grothendieck groups I would also like to work with the algebras and their modules directly. In gap I have code for doing this both inside chevie and in unpublished code. During the workshop I started writing some new code in sage for computing with  the graded Specht modules. I have an implementation of this inside my working version of specht but it is a little clunky and difficult to  extend from type A to arbitrary level. The version that I have in sage will generalise very easily once I write the necessary code  for multipartitions (PartitionTuples) and tableaux whose shape is a multipartition. The workshop was very helpful in letting me see how sage worked and helping to motivate me to write something. In particular, I finally learnt, with some help from Nicolas and Florent, how to interface with gap3 which is essential for what I am currently doing as I need some specialized combinatorial functions that I  have in gap. At some point I will submit this for review and incorporation into sage...
     127  In addition to working with the Grothendieck groups I would also like to work with the algebras and their modules directly. In gap I have code for doing this both inside chevie and in unpublished code. During the workshop I started writing some new code in Sage for computing with  the graded Specht modules. I have an implementation of this inside my working version of specht but it is a little clunky and difficult to  extend from type A to arbitrary level. The version that I have in Sage will generalise very easily once I write the necessary code  for multipartitions (PartitionTuples) and tableaux whose shape is a multipartition. The workshop was very helpful in letting me see how Sage worked and helping to motivate me to write something. In particular, I finally learnt, with some help from Nicolas and Florent, how to interface with gap3 which is essential for what I am currently doing as I need some specialized combinatorial functions that I  have in gap. At some point I will submit this for review and incorporation into Sage...
    128128
    129   In any case, following the workshop I am quite enthusiastic about sage and I am now close to having some working code which is more succinct than the corresponding code in gap. More importantly this code is very easy to extend. It would be nice is permutations in sage worked better, that   the general framework was more complete and really good if tab stops were two spaces rather than four. Apart from these quibbles sage is rapidly growing on me and I expect to start pushing code to the patch server soon!
     129  In any case, following the workshop I am quite enthusiastic about Sage and I am now close to having some working code which is more succinct than the corresponding code in gap. More importantly this code is very easy to extend. It would be nice is permutations in Sage worked better, that   the general framework was more complete and really good if tab stops were two spaces rather than four. Apart from these quibbles Sage is rapidly growing on me and I expect to start pushing code to the patch server soon!
    130130
    131131 * Frank pointed out several spots where Sage's code is much slower than it should be. For example, listing or iterating through the elements of a Coxeter group is ridiculously slow. The following challenge will be a good measure of Sage's progress in this area: running through all elements of the Coxeter group of type E8 in  less than 3 hours as GAP can do (see #9285).
     
    142142 * #7980: Implement generic support for parents with (multiple) realizations
    143143 * Polishing Jason's tutorial on implementing algebraic structure
    144  * Reorganizing the various demos/tutorial for sage-combinat
     144 * Reorganizing the various demos/tutorial for Sage-Combinat
    145145 * Proof of concept for #9291
    146146