#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:127 ncohen]:
> No, they are not [immutable]. Only the backend is immutable, the graph
itself isn't. I mean, you can't add/remove vertices nor edges (you would
get an exception) using the Graph object, but there is a wealth of awful
things that graphs store, and that are still mutable. Like embeddings,
like a LOT of stuff. Can't an edge label be mutable too, btw ?
Let me rephrase my question: Probably, if one really wants to play dirty,
one could change edge labels. But is it possible to change edge labels by
using "official" (non-underscore) methods of the graph? If it is
impossible, then I'd say the graph is immutable.
And concerning edge labels: Yes, I need them for the constructions of
quiver
algebras and so on.
So, if it is possible to change the edge labels of a "static_sparse"
digraph
by using non-underscore method, then I'd say we ''can't'' work with
digraph
(and need a sub-class or something else).
> Embedding, layout, name, allowing or not multiple edges/loops.
This won't matter for me. Actually, if you compare digraphs ("=="), would
the
embedding, layout, name and so on be taken into account?
Let me rephrase my needs: For me, it is important that one can't (by
non-underscore methods) change the ==-equivalence class of the graph. If
this
is the case, then it is immutable.
> My problem with the patch at #14535, is that decorators on methods that
are
> heavily used could impact ALL graphs
The stuff here is not related with #14535 (which is probably just a bad
idea).
> I don't really know what these methods do, to be honest.. Do they apply
to
> all digraphs, for a start ?
AFAIK, there is no mathematical difference between a quiver and a digraph.
And
of course, for any digraph, you can construct the algebra whose monoids
correspond to directed paths, which are multiplied by concatenation
(yielding
zero if the end/startpoints don't match): The quiver algebra.
So, yes, the mathematical notions here make sense for all digraphs.
But, as you know, I like `UniqueRepresentation`. And since the digraph
together with a
base ring is enough to determine the quiver algebra, I would like to use
the
digraph as a cache key.
Hence, from the implementation point of view, "quiver algebra" and friends
will only make sense for all ''immutable'' digraphs.
> And do you think that you would ever want the digraphs you use to have
anything to do with the parent/element stuff and facades ?
No. For me, the digraphs are just labels for some algebra.
Note that with the patches from here, `Quiver` is not a parent. The only
parents occuring here are `FreeSmallCategory`, `QuiverRepresentation` and
`QuiverAlgebra`---none of them are digraphs.
> Most importantly, do you really think that you want to inherit from
DiGraph? You can use the backends without inheriting from DiGraph objects,
and in particular you wouldn't have 10000 unrelated methods in your
objects.
Well, a quiver ''is'' the same as a digraph. So, I believe it totally
makes
sense to have 10000 unrelated methods.
And yes, I also believe that digraph should
have even more methods, namely in addition: A method returning the quiver
algebra
over a given ring and some methods being able to construct representations
of the
quiver.
The only reason for introducing a subclass `Quiver` of `DiGraph` was the
concern about mutability.
> And you could have a method from quivers to graph if you ever want to do
things like computing a hamiltonian circuit in your quivers ? `:-P`
Sure. But there is no mathematical reason to create a new python class for
quivers. The only reason to do so was in the code.
__Conclusive question__
Do we have digraphs with the property that it is impossible to change the
==-equivalence class by using non-underscore methods? If we have, then I'd
suggest to add a few more methods to them. And don't worry, I won't turn
digraphs into parents or facades... :)
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:128>
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.
