#10527: Implementation of quiver mutation type
-----------------------------------------------+----------------------------
Reporter: stumpc5 | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.3
Component: combinatorics | Resolution:
Keywords: quiver mutation type days38 | Work issues:
Report Upstream: N/A | Reviewers: Hugh Thomas
Authors: Christian Stump | Merged in:
Dependencies: | Stopgaps:
-----------------------------------------------+----------------------------
Changes (by gmoose05):
* cc: robertwb (added)
Comment:
I just uploaded a new patch which takes care of the issues that Hugh
raised. Thanks for that. I also made one or two other changes that will
be useful for patches 10538 going forward. Please see my comments below.
Replying to [comment:113 hthomas]:
> Yay! So far as I can tell, the only complaint the patchbot is making is
that we're adding new modules, but since we're importing them lazily, it's
not really a problem.
Yay! Hopefully the patchbot will again be happy after it processes the
new patch. Yes, this seems related to
https://groups.google.com/forum/?fromgroups=#!searchin/sage-
devel/patchbot$20plugin$20start-up$20modules/sage-
devel/6LByB07Ks9c/gU1TCecUwwoJ
and yes, it is true that we import (although lazily) modules. So I agree
that this plug-in is not an issue. To double-check, I just CC'ed Robert
Bradshaw (who had also mentioned the lazy_import to us for #10538).
>
> I had never reviewed Gregg's final patch. I've now looked at it and I'm
afraid I have some minor issues with it. (And testing it has led to
detecting some other non-optimal behaviour.)
>
> Gregg, you said you wanted to fix !QuiverMutationType('C',1,1) giving a
cryptic message, but in fact it still does (it still says "'CC',1,1" is
not valid).
>
Yes, this is fixed now. Thanks for catching that.
> I see you changed the error message to reflect the fact that in elliptic
types, twists can have 2's in them, which is better than what was there
before. But they can also have 3's in them (elliptic G's).
>
> In fact, I suggest removing the last four lines of the error message,
including the elliptics, and replacing them by "For correct syntax in
other types, please consult the documentation." As it stands, it looks
like it's purporting to be some kind of complete list, but in fact not
every type is well-described (e.g., GR, which takes a single additional
parameter which is a tuple/list blah, blah). In general, I don't think
the goal of an error message should be to replace the documentation.
Yes, you are correct I slightly changed the phrasing for Elliptic, and
then followed your advice for the last three lines. Let me know if this
looks okay.
>
> I still think it's pointless to include AE. If you want it, it
definitely shouldn't have a twist of 3. And I think the documentation
should explain the input format.
I ensured that AE doesn't take a twist argument, updated the example, and
added a comment to the documentation about the input format. I still vote
to keep it, but don't feel too strongly if you and Christian want to get
rid of it.
>
> I'm not sure why we're allowing !QuiverMutationType('GR',(n,k)) as well
as (k,n). The Grassmannian of 3-planes in 2-space is just meaningless,
and (in my view) it should return an error. I could be argued out of
this.
I forget now why we allowed switching the order of k and n. Christian, do
you remember? Anyway, Hugh I agree with you, and made the change.
!QuiverMutationType('GR',(5,2)) for instance now gives an error. But we
still have !QuiverMutationType('GR',(3,5)) =
!QuiverMutationType('GR',(2,5)).
>
> !QuiverMutationType('D',3,2) works, but !QuiverMutationType('A',3,2)
doesn't. But A_3 and D_3 are the same. I think both should yield what
D,3,2 does now (namely, C,2,-1). There has to be some notation for it,
and it's pretty peculiar to require people to think of the root system as
derived from D,3 rather than A,3. (The reason this makes some sense is
that it fits the pattern of D,n,2, not the pattern of A,2n+1,2, but I
think that's okay.)
This was from following Kac's affine notation, which didn't allow A_3^(2).
However, coercing to ('D',3,2) might be a better choice than an error
message here. Unfortunately, ('A',3,2) doesn't resemble ('A',2k+1,2) in
this case, but perhaps this is okay. Christian, feel free to let us know
if you have a different preference. By the way, I just ran
{{{
sage: CartanType(['A',3,2])
['B', 2, 1]^*
sage: CartanType(['D',3,2])
['C', 2, 1]^*
sage: CartanType(['A',4,2])
['BC', 2, 2]
sage: CartanType(['A',5,2])
['B', 3, 1]^*
sage: CartanType(['A',7,2])
['B', 4, 1]^*
sage: CartanType(['D',4,2])
['C', 3, 1]^*
sage: CartanType(['D',5,2])
['C', 4, 1]^*
}}}
as a sanity check, and it actually *does differ* from this choice. Should
we make
{{{
sage: QuiverMutationType(['D',3,2])
['BB',2,1]
sage: QuiverMutationType(['A',3,2])
['CD',2,1]
}}}
instead?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10527#comment:114>
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.
