#20402: Make subword complexes compatible with  real reflection groups
-------------------------------------+-------------------------------------
       Reporter:  stumpc5            |        Owner:
           Type:  enhancement        |       Status:  needs_work
       Priority:  major              |    Milestone:  sage-7.2
      Component:  combinatorics      |   Resolution:
       Keywords:  reflection group,  |    Merged in:
  coxeter group, subword complex,    |    Reviewers:
  days80                             |  Work issues:
        Authors:  Christian Stump    |       Commit:
Report Upstream:  N/A                |  295d784db0ae24bed97ed7b4d3777df9dbd652c2
         Branch:  u/stumpc5/20402    |     Stopgaps:
   Dependencies:  #11187             |
-------------------------------------+-------------------------------------

Comment (by tscrim):

 Replying to [comment:44 stumpc5]:
 > > Sage's vectors exists expressed in some canonical basis, and by doing
 matrix multiplication, there is an implicit assumption that these bases
 are the same.
 >
 > I'd say that multiplying a matrix {{{M}}} with a vector {{{v}}} (as a
 tuple in distinction to vector space elements) is well-defined and
 completely independent on bases. So that's totally fine to do as
 {{{M*v}}}.

 No, that is not true except in the most abstract sense of a linear
 morphism and an element of a vector space. A matrix comes with an implicit
 choice of a basis, and when we write vectors as tuples, there is an
 implicit choice of a basis as well. For example, if `M` is a
 diagonalizable matrix acting on a vector space `V`, we can find some basis
 such that `M` can be expressed as acting on scalars on that basis. While
 the diagonal matrix and `M` are different matrices, they define the
 ''same'' linear automorphism on `V`, and hence, have the same action on a
 vector. Yet, to do the computation, we need to express the vector in terms
 of our basis.

 > Only if the matrix is representing a linear map and the tuple represents
 a vector space element there is an assumption on both being represented in
 the same basis. When you now represent a Coxeter group element as a matrix
 you make a choice of basis (which might be the root basis, its dual, some
 linearly independent vectors of an "ambient space", or any other) This is
 now what you stick this matrix to, but when you do {{{w*v}}}, one does not
 specify the matrix that represents {{{w}}} in some basis, so this
 operation is ambiguous, as it didn't specify on which space {{{w}}} acts
 here (i.e., it is not clear in which basis you represent {{{w}}} as a
 matrix for that action.

 That is not how a `CoxeterMatrixGroup` or a `WeylGroup` is defined. It is
 given precisely by that choice of representation/matrix, so in a way, it
 is a Coxeter system along with a specified representation.

 Also, any `v` (implicitly) carries with it a vector space (not up to
 isomorphism), and we are checking to see if the Coxeter group has a
 defined action on that vector space. An alternative viewpoint is if `v` is
 a Sage vector, in a way, we are only considering that element up to
 isomorphism, so we have lost some information (but again, that is if we
 don't fix a representation which makes a canonical choice of basis for the
 vector space). In contrast, for `v` being an element of the
 root/weight/ambient space, we have an explicit basis and we have defined
 where the roots are in these, so the action is well-defined and explicit.

 > For {{{ReflectionGroup}}} I just thought that the best is to have the
 method {{{.action}}} to take two parameters {{{side}}} being {{{"left"}}}
 or {{{"right"}}} and {{{on_space}}} being {{{"primal"}}} or {{{"dual"}}}.
 >
 > Beside that, I am okay with providing the coercion to act on the primal,
 but am also okay with removing it again (I am slightly in favour of
 keeping it though).

 In case there is any ambiguity, I'm also only really advocating for using
 `*` in the real reflection group setting. Moreover, I think we should
 avoid using Sage vectors for the roots (at least in the generic parents)
 because there is some ambiguity about their basis.

--
Ticket URL: <http://trac.sagemath.org/ticket/20402#comment:45>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to