#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:
-----------------------------------------------+----------------------------
Changes (by hthomas):
* keywords: quiver mutation type => quiver mutation type days38
* reviewer: => Hugh Thomas
* status: needs_work => needs_review
Old description:
> The patch implements multiple mutation types of quivers. This
> classification contains in particular all finite and affine types of
> generalized Cartan types.
>
> The patch contains multiple examples.
>
> {{{
> sage: mt = QuiverMutationType(['A',3]); mt
> ['A', 3]
> }}}
New description:
The patch implements multiple mutation types of quivers. This
classification contains in particular all finite and affine types of
generalized Cartan types.
The patch contains multiple examples.
{{{
sage: mt = QuiverMutationType(['A',3]); mt
['A', 3]
}}}
The current version of the patch is the one on the combinat server, not
the one posted here.
--
Comment:
Okay, I agree, BB,1,1 should be undefined.
----
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.
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.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10527#comment:25>
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.
