#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 hthomas):
Replying to [comment:26 stumpc5]:
> Replying to [comment:25 hthomas]:
> >
> > Okay, I agree, BB,1,1 should be undefined.
>
> okay -- are you going to edit this patch, or (even better) add a review
patch right after?
>
Yes, I am workiing on a review patch. I can do this there.
----
>
> > 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.
>
> I think you know more about that than I do: are you saying that types
V,W,X,Y,Z are elliptic?
>
X_6 and X_7 (The Derksen-Owen quivers, which are skew-symmetric) are not
elliptic. But the sporadic non-skew-symmetric mutation-finite valued
quivers are elliptic. This means they have elliptic-sounding names (eg
G^(1,3)^). However, the elliptic-looking quivers are different from the
ones which you've provided. Do you want to use the quivers you provided,
or the elliptic-looking ones in (for example) FST? Also, do you have a
reference for the quivers you provided?
----
>
> > 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).
>
> Yes, that's right. The reason we still use it is in order to make it a
priori clear for the user what kind of type he/she is using: None for
finite 1 for affine, 2 for mutation finite, and 3 for mutation infinite.
But if you think that's too much, or not needed, we can as well delete it.
You can maybe ask for another opinion on that at the sage days.
Okay, I'll get a second opinion. But note that the system you are using
is actually less straightforward than that, since if, for example, you
invoke a finite mutation type via a family like T, you have to enter a 3
anyhow.
> ----
>
> > 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.
>
> agreed with all these.
>
Great. If people are using Macdonald notation, how do you feel about
making them say "affine=true" for affines (if we now reserve "twist" for
Kac and Saito notations)?
----
>
> > 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.
>
> can you think of a good name? choose whatever you find appropriate.
Maybe "numerical_data"?
> ----
>
> > 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.
>
> me neither, but I discussed that with Gregg, and we thought that we just
include them. If you really think no one will ever try to use them, then
we can as well delete them.
>
> > 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 think of AE as an affine type A plus an extra edge, so the logic is
still the same (though the only point where it is visible that we have
affine type A is that we use (a,b) as a second parameter in order to say
how many edges are oriented in which direction.
I guess it does no harm to include BE, CE, DE. The reason AE's notation
seems different to me is that BE, CE, DE have "B on one end, E on the
other", while this is not really true for AE (the A is really affine A,
not finite A, and there isn't anything very E-like about adding an edge at
an arbitrary point). I'm inclined to remove it.
----
>
> I added Gregg as cc, so he can also give his opinion...
Hi Gregg! Please do feel free to weigh in.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10527#comment:27>
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.
