#17798: Create a class for Coxeter matrices and types
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.10
Component: group theory | Resolution:
Keywords: Coxeter groups, | Merged in:
matrices, types, days64 | Reviewers: Jean-Philippe Labbé,
Authors: Travis Scrimshaw, | Travis Scrimshaw
Jean-Philippe Labbé | Work issues:
Report Upstream: N/A | Commit:
Branch: | e659186e20bbb4b4a942008dff32901659e42503
public/combinat/coxeter_matrices-17798| Stopgaps:
Dependencies: #17990, #18152, |
#18743 |
-------------------------------------+-------------------------------------
Changes (by tscrim):
* milestone: sage-6.9 => sage-6.10
Comment:
Replying to [comment:77 jipilab]:
> Replying to [comment:74 tscrim]:
> > The fix was that the cluster seed code was assuming the indexing set
of a Cartan matrix constructed from a matrix that was of finite type had
the standard finite type indexing set of `[1, 2, ..., n]`. I fixed this by
explicitly specifying this to be the index set of the Cartan matrix.
>
> Is my last edition to make test pass consistent with this change?
One of the trivial doctest failures because of `subtype` actually was the
one indicating the problem, but that was because I wasn't passing the
indexing set as I should have been. We should check for `CoxeterMatrix`
and `CoxeterType` that labelings work as they should.
> > This brings up a point that might need a discussion: Should the index
set of a matrix representing a finite type Cartan matrix be by default
1-based or 0-based? The argument for being 1-based is above, a natural
assumption on index sets of finite type. Why we should have 0-based is
consistency with the rest for default labellings and it agrees with the
indexing set of the given matrix (and everything in python is 0-based).
Thoughts?
>
> I would say 1-based for finite type since they probably have a labeling
hardcoded when dealing with them through Cartan matrices and Coxeter
Types.
>
> I would say 0-based whenever there is no labels specified and it comes
through a CoxeterMatrix type, eventhough the type is finite.
>
> But this probably causes trouble?
I was talking about when no labels are given, and it sounds like we are in
agreement. However there is some code that doesn't use the indexing set,
but instead a range under the assumption that the indexing set is `(1, 2,
..., n)`. I'm still partially debating whether or not to change the
cluster seed code as well to help make it robust (although it is somewhat
moot because we now specify the indexing set).
In short, it causes trouble for people's code that had made an assumption
about the indexing set before.
> In a sense, having a "relabel" method somehow means that we have a
canonical way of doing and then whenever it is not that one, it means that
it was relabeled.
>
> Does that make sense?
Yes it makes sense. In a way, I agree with you. However, we must define a
canonical way of labeling in order to implement the database of Cartan
types. Also we can relabel relabeled types.
--
Ticket URL: <http://trac.sagemath.org/ticket/17798#comment:78>
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.
