#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 ncohen):
Hellooooooooo !!
> I recall a worksheet in which William demonstrated mutating an Integer.
That's forbidden magic.
> OK, but they naturally occur in algebra. Algebra causes headaches, too
;-)
I admit that.
> 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.
Multiple labelled loops on a vertices. Ahahah. I owe other headaches to
that while coding #14953 `:-P`
> Good news for me:
> {{{
> sage: g = graphs.PetersenGraph(); g == Graph(g.edges())
> True
> }}}
Wuuuhuuu !!
> > 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 ...
HMmmmmm.. Well, if you want some Graph objects to be officially immutable,
it has to make sense with what the objects already store...
> 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 "==".
This equality test can also be implemented at backend-level. Which would
be MUCH faster `:-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.
I agree with you. However, the current implementation checks that these
flags are equal in `__eq__`. So you will probably have to modify it a bit
in case the graphs are static.
Dans it would produce weird things like :
sage: g == h
False
sage: Graph(g,immutable=True) == Graph(g,immutable=True)
True
Or perhaps we should just give up saying that two graphs are different
just because of these flags... Would probably make more sense, actually.
> Then why would you call them digraphs? `:-P`
http://en.wikipedia.org/wiki/Quiver_(mathematics)
http://en.wikipedia.org/wiki/Directed_graph
HMmmm... Looks like they insist on having multiple edges and loops, which
is not forbidden by digraphs. Well `:-P`
> Seriously, I guess there are just two mathematical communities. Graph
> theorists would call them digraph, I guess, but algebraist would call
them quivers.
I'll go talk to them one by one and convince them that what they do is
wrong `O_O`
> 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".
`O_o`
Well. As a DiGraph user I would personally prefer "path magma", because
even if I have no idea what a path magma is there is "path" in there at
least. "free small category" really rings no bell at all.
But well.. It's not mine to decide `^^;`
What about `path_monoid` (if it is a monoid) ? `:-P`
> - `.quiver_algebra(R)` (or just `.algebra(R)`?): Return the monomial
algebra
> over R whose monomials are given by the free small category
What about `path_alebra` ?
http://en.wikipedia.org/wiki/Quiver_(mathematics)#Path_algebra
> - `.quiver_representation(...)`: Create a module over the quiver
algebra.
To me this should be `.quiver_algebra().representation()`.
> - 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.
HMmmmmm `O_O;;;`
> 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.
Yep ! And I swear, it's cheap. And much more efficient than current
graphs.
See youuuuuuuuuuu !
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:131>
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.
