#10527: Implementation of quiver mutation type
-----------------------------------------------+----------------------------
Reporter: stumpc5 | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: combinatorics | Resolution:
Keywords: quiver mutation type days38 | Work issues:
Report Upstream: N/A | Reviewers: Hugh Thomas
Authors: Christian Stump | Merged in:
Dependencies: #10349 | Stopgaps:
-----------------------------------------------+----------------------------
Comment (by gmoose05):
Replying to [comment:25 hthomas]:
>
> Okay, I agree, BB,1,1 should be undefined.
Agreed.
> ----
> I'm confused about the notation you're using for some of the exceptional
finite mutation type classes. The non-simply-laced finite mutation type
mutation classes are classified in Felikson-Shapiro-Tumarkin,
arXiv:1006.4276. They __are__ elliptic root systems (F-S-T say this),
contrary to what's in the package now, and as a result I would rather get
them using Saito notation. But I don't see how the data for them match up
with the data in F-S-T.
> ----
> Here's another question: for the most part, the third parameter is
redundant. I think the third parameter should only be used for the Kac
convention (in affine root systems) and the Saito convention (in elliptic
root systems).
>
> The only other information you're using it for is when you want to
indicate the check in the other convention for affine roots. But
"check=true" would be easier to remember.
We were trying to have some notation that would be compact yet flexible.
Part of the issue, that there will be users from the Kac convention, but
then users from other conventions. Also, since cluster algebra mutation
types can be finer than Dynkin types (e.g. in the affine A case, when the
number of oriented arrows in a given direction matters) it wasn't a
perfect fit either to use the standard Kac conventions.
One ambiguity might be that we wrote that code just after Felikson-
Shapiro-Tumarkin's second paper hit the arxiv. They were using different
notation for their exceptional examples in 2010 (see version 1-3) than
they are in 2011. I am happy for the sage convention to be updated to the
2011 (FST arxiv version 4) notation.
>
> I also think it might be helpful to indicate references for the
different conventions.
>
> http://en.wikipedia.org/wiki/Dynkin_diagram#Affine_Dynkin_diagrams
>
> seems to be a pretty good reference for the affine diagrams using the
Kac convention. And the convention Macdonald uses is recorded online at
>
>
http://assets.cambridge.org/97805218/24729/excerpt/9780521824729_excerpt.pdf
>
> Then there is possibly a more canonical reference for Saito than F-S-T.
> ----
> It seems potentially confusing that "rank" is an argument for creating
the object and also an attribute of the resulting object, but they aren't
equal. I guess all I'm really asking for is that the parameter for
creating the object should have a different name.
> ----
> I haven't heard of types AE, BE, CE, DE before. BE, CE, and DE seem to
be constructed on the same logic as BC, BD, etc, so it's pretty clear what
they're doing, but I'm not sure that they're needed. AE seems to be
constructed on a rather different logic; logically (to me) AE should just
refer to the E-series. So in addition to wondering if it's needed, I'm
not very happy with the name.
I also would vote for keeping BE, CE, DE, but am fine with jettisoning AE.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10527#comment:31>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
