#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:28 hthomas]:
> Replying to [comment:27 hthomas]:
> > Replying to [comment:26 stumpc5]:
> > > > 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.
>
> Chris Berg agreed with me when I talked to him just now, and Nicolas
also agreed with me last night (though I guess I didn't put the question
quite as precisely to Nicolas).
>
> Also, Nicolas suggested that the names of the types be more obvious.
It's a matter of style, I guess, whether you prefer R2 or Rank2, TR or
Triangle, GR or Grassmannian. I think the latter is more inviting to
someone who is unfamiliar with the code. But I don't really have a strong
feeling about this. (Nicolas's suggestion was based on a quick
description of the situation from me, so it could be that he would have a
different opinion if he looked into it himself.)
I am fine with using Rank2, Triangle, Grassmannian for the type names if
it is more instructive to a user, but if it seems reasonable, would also
keep the shorter 'R2', 'TR', and 'GR' as shorter inputs that then coerce
to the longer names.
Regarding the issue of the "twist" parameter which is either 'None' for
finite, '1' for affine, '2' for mutation-finite, or '3' for other, I am
open to suggestion.
We definitely want to distinguish Cartan finite from Cartan affine, or the
elliptic types, and wanted some other useful sequences.
In future implementations, we foresaw including other quiver sequences
such as the Generalized Glick quivers, Somos 4 and 5 quivers (or other
Gale-Robinson sequence quivers) or those coming from a Q-system, and
quivers from other surfaces, so we would want an infrastructure that
easily allows a user to encode quiver types from certain families. This
was part of the mutation for including a twist parameter but maybe its
extraneous.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10527#comment:32>
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.
