#12630: Add representations of quivers and quiver algebras to sage
-------------------------------------------------+-------------------------
Reporter: JStarx | Owner:
Type: enhancement | AlexGhitza
Priority: major | Status:
Component: algebra | needs_work
Keywords: algebra, quiver, module, | Milestone: sage-5.12
days49 | Resolution:
Authors: Jim Stark, Simon King, | Merged in:
Mathieu Guay-Paquet, Aladin Virmaux | Reviewers: Simon
Report Upstream: N/A | King
Branch: | Work issues:
Dependencies: #12412, #12413, #14806 | Commit:
| Stopgaps:
-------------------------------------------------+-------------------------
Comment (by SimonKing):
Replying to [comment:129 ncohen]:
> Well... You can get the edge label from a pair of vertices u,v (and that
label could be a list),
Yeaaah, but then you aren't using methods "officially" supported by the
graph. If you like, you can even mutate an integer: I recall a worksheet
in which William demonstrated mutating an Integer.
> Ahem. Well, for a start, the static backend only support multiple edge,
loops and labels because you need them.
Did you just say that you made the static backend support multiple edges
just for me? (blush) Thank you!
> And most of this patch headaches, as usual, come from multiple edges,
loops and labels. I personally hate them with all my heart `:-P`
OK, but they naturally occur in algebra. Algebra causes headaches, too ;-)
For example, if you have a finite group whose order is a power of a prime
p, then the group algebra over GF(p) can be described as a quotient of a
quiver algebra ''with a single vertex''. So, all edges are loops.
> Then, as the graph is static these things have no reason to be
> mutable. Though the backend only stores the labels as "python objects",
and
> Python objects can be anything. A "clean" implementation would be to
refuse
> to convert to an immutable graph any graph which has non-immutable edge
> labels, but I think that's going too far.
I totally agree.
> Good question. I hope not. I don't have Sage right now (it's compiling),
but if
> g = graphs.PetersenGraph(); g == Graph(g.edges())
> says True, then we are sage and these are not taken into account.
Good news for me:
{{{
sage: g = graphs.PetersenGraph(); g == Graph(g.edges())
True
}}}
> Though it would make sense to prevent anybody from changing the
> embedding/layout in an immutable graph anyway. Let's pretend, at the
very
> least `:-P`
That's other people's problem for me ...
> Though of course, if two graphs with the same edges have different
labels
> they will be different.
That's what I want. Namely, the generator names of the quiver algebra are
obtained from the edge and vertex labels. And if they change, then the
algebra
should change as well. Hence, the labels ''should'' be checked in "==".
> And you can (currently) modify an edge label if the edge label object is
> mutable, using only non-underscore methods.
That's not what I meant. You can of course obtain the edge label by
non-underscore methods, but in order to ''mutate'' the returned label, you
need to do more.
> Well, if you want immutable graphs you will probably have to use these
decorators ! I think that
> two graphs cannot be equal if one allows multiple edge while the other
one does not. Perhaps it
> is a mistake, though `:-P`
Hmmmm. I'd think one shouldn't say that an immutable graph "allows"
loops/multiple edges. Either it ''has'' loops or it has not---if it has
not,
it will certainly not allow to create a loop, since it is immutable.
> > AFAIK, there is no mathematical difference between a quiver and a
digraph.
>
> Then why would you call them quivers ? `:-P`
Then why would you call them digraphs? `:-P`
Seriously, I guess there are just two mathematical communities. Graph
theorists would call them digraph, I guess, but algebraist would call them
quivers.
> Hmmm... Well, a `.quiver_algebra()` method would make sense indeed
> then. Would you have many to add ?
I'd need to look at the code. At least there would be
- `.free_small_category()`: This is the set of directed paths with
multiplication by concatenation. I was told on sage-combinat-devel that
I
shouldn't call it "path magma" but "free small category".
- `.quiver_algebra(R)` (or just `.algebra(R)`?): Return the monomial
algebra
over R whose monomials are given by the free small category
- `.quiver_representation(...)`: Create a module over the quiver algebra.
- Currently there are some short-cuts for creating a quiver
representation. For example, the vertices of the quiver/digraph are in
one-to-one correspondence to the simple modules of the quiver algebra.
And
the projective covers of the simple modules are important as well.
If I recall correctly, we have 3 shortcuts, so, this would result in 6
additional methods.
Disadvantage of moving stuff to Digraph: It would again give rise to
refactoring the code. I guess this is not other people's problem ... `:-/`
> > Hence, from the implementation point of view, "quiver algebra" and
friends
> > will only make sense for all ''immutable'' digraphs.
>
> Why so ? I chatted a bit with Florent about this, and it seems that you
do
> need some specific data structure to store all these paths, and
> concatenate them easily and quickly and everything. I thought that
calling
> a `.quiver_algebra()` in a (possibly mutable) graph would somehow give
you
> a new object containing that data structure, and that this would
probably
> encode the graph in a better way too ?... By the way, this static data
> structure is now ... extremely cheap, compared to the current
> graphs. Really, really cheap. And copying it is really just a `memcpy`
of
> size `g.size()`.
Right, you could always say that you have a class `FreeSmallCategory`
inheriting from `UniqueRepresentation`, and then `G.free_small_category()`
should return `FreeSmallCategory(G)` if G is immutable,
but `FreeSmallCategory(immutable_copy(G))` otherwise.
> > Well, a quiver ''is'' the same as a digraph. So, I believe it totally
makes
> > sense to have 10000 unrelated methods.
>
> Really, why don't you call them digraphs then ? `O_o`
Because currently I am algebraist. I used to be a low-dimensional
topologist,
and I think these guys did not come to a conclusion whether it is digraph
or
quiver (I heard naming them both ways when I was young).
> Hmmm... And what about having a `quiver_albegra()` method that returns
this
> quiver algebra, and having those method for representations be methods
of
> this quiver algebra object ?
Makes sense. I would agree that having a method on the quiver/digraph is
actually a short-cut.
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:130>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
