#15375: Extended Affine Weyl Groups SD40
-------------------------------------+-------------------------------------
       Reporter:  bump               |        Owner:  bump
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.8
      Component:  combinatorics      |   Resolution:
       Keywords:  days54, coxeter,   |    Merged in:
  days64, days65                     |    Reviewers:  Dan Bump, Anne
        Authors:  Daniel Bump, Dan   |  Schilling
  Orr, Anne Schilling, Mark          |  Work issues:
  Shimozono, Nicolas Thiery.         |       Commit:
Report Upstream:  N/A                |  2b78b7bdc2db6835dadfad978e5f6992f0546649
         Branch:                     |     Stopgaps:
  public/combinat/extended_affine_weyl_groups-15375|
   Dependencies:  #10963, #14102     |
-------------------------------------+-------------------------------------

Comment (by nthiery):

 Hi Mark!

 I have glanced half way through the patch. It's a lot of hard work you
 did; thanks! I'll try to go through the over half soon, but won't have
 the time for a systematic review, so please someone!

 Here are some thoughts that popped up; take them as they just are:
 random food for thoughts. If something does not sound applicable, just
 ignore it.

 - `weyl_groups.py` line 420,453: any reason to remove the test for
 s2s1s2s1?
 - `RootSystem(XXX.cartan_type())` -> `XXX.cartan_type().root_system()`

 - `def to_ambient_space_morphism`: you can use
   `sage.misc.c3_controlled.identity`. Yeah, there is no reason why the
   identity function is defined in this module; but at least if we all
   use the same identity function it will be easier to refactor later
   on.

   Variants, if you want a morphism: `End(self).identity()` or `sage:
   self.coerce_map_from(self)`,

 - `..warning` -> `.. WARNING`

 - In `to_weight_space`: instead of going through a vector, one can use
   `.sum_of_terms([i,self.scalar(alpha[i])] for ...`

   This method is generic and would better be in `WeightSpaceRealizations`.

 - `to_ambient`

 - `special_nodes`: any reason not to use `return
 autos.orbit(self.special_node())` ?

 - `Nicolas Thiery` -> `Nicolas M. Thiery` for consistency

 - Doc of `ExtendedAffineWeylGroup`: use `.. MATH` for the math
   formulas on their own line.

 - `... the following lattices:`; idem for `E` below.

 - When natural, put the `::` at the end of the sentence.

 - Line folding could be more consistent

 - There are still quite a few of `ifs` depending on
   twisted/untwisted/GL; any chance to make this more generic?

   For example, to define the special translation covector can't we
   generically use something like `c[special_node] *
   _special_root.associated_coroot()`? I never remember from the top of
   my head whether it's `c` or one of its friends that should be used
   here, but we did things like this in the MacDo code.

   Note that at this point the initialization of
   `ExtendedAffineWeylGroup_class` will probably break on a relabelled
   type BC.

 - Do we need the `special_nodes` method on the group and the
   fundamental group? Or could just have it on the cartan type?

 - Strip new lines just before and just after the end of the
   documentation string.

 - `classical_weyl` -> `classical`? or `classical_weyl_group`?
   I don't remember what we did in similar situations for crystals
   and the like, but please check for consistency.

 - `classical_weyl_to_affine_morphism`: the name is misleading since
   the result is not a morphism. Could we have a name like
   `from_classical` or make this an element method `to_affine`?
   Same for the related methods.

 - `cardinality` is already provided by `Sets().Infinite()`

 - `group_generators` this could in principle go in
   `Groups().WithRealizations()`. If creating the latter just for this
   seems like overkill, you can just add a comment about this.

 - `...Realizations.ParentMethods.one`: replacing `PW0` by
   `a_realization` the code would be generic and could go in
 `Magmas.Unital.Realizations`.

 - `Returns` -> `Return`

 - `coset_representative, is_grassmanian, ...`: this is the same logic
   as for a usual coxeter group, right? Could we avoid the duplication
   by having a common super category?

 - `get_the_index` -> `leading_support`?

 - `FundamentalGroup...one`: `0` -> `special_node`

 - `an_element`: you can probably use `.last()` (haven't tested)

   - `action`: maybe `representation`? Elsewhere in Sage, `action` is
     usually a method that implements the action itself.

 - `root_lattice_realizations`: `Algebras` is now imported twice.


 Cheers,
                             Nicolas

--
Ticket URL: <http://trac.sagemath.org/ticket/15375#comment:94>
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.

Reply via email to