#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 stumpc5):
Replying to [comment:45 tscrim]:
> 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.
The point I wanted to make is that given a field k, you can define an nxn
matrix M over k as a table of entries in k and you can define an n-tuple
to be an n-tuple x of entries in k, and you can multiply them Mx by some
explicit row-column definition. At this point, there is no basis involved.
One can even enrich the set k^n with a vector space structure and then see
the multiplication by M at a linear map without ever talking about bases.
And this multiplication is defined in Sage, even if k is not a field so
there is no as simple concept of bases.
Only if one wants to consider a k-linear map phi : V -> V on a vector
space V over k as a matrix, then the basis comes into play.
Of course one could say that k^n has an implicit basis in which the above
matrix represents a linear map, but that is not quite adequate since k^n
comes with a canonical standard basis, so there is no choice of an
implicit basis.
> For example, if `M` is a diagonalizable matrix acting on a vector space
`V`,
in your argument, you always assume a general vector space V, there I
agree that you play with explicit or implicit bases.
> 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.
That's right, and I am fine with arguing that this action of the group
should be used when doing {{{w*v}}}. But there are still other spaces
involved on which the group also acts, so if you do not specify which
space {{{v}}} lives in one has to **implicitly** assume it to be this
representation.
> In case there is any ambiguity, I'm also only really advocating for
using `*` in the real reflection group setting.
My proposition for reflection groups at the moment is
* have a method {{{.action(vec, side="left", on_space="primal")}}} that
does the appropriate action, and
* have {{{._act_on_(vec, self_on_left)}}} defined as {{{.action(vec,
side=side, on_space="primal")}}} where the side is set depending on
self_on_left being {{{True}}} or {{{False}}}.
> 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.
I agree, but I have not yet implemented root spaces and coroot spaces for
crg's. So I don't have anything better to provide for now than vectors.
But that's on the todo list...
--
Ticket URL: <http://trac.sagemath.org/ticket/20402#comment:46>
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.
