#16453: Cythonize quiver paths
-------------------------------------+-------------------------------------
Reporter: SimonKing | Owner:
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.4
Component: algebra | Resolution:
Keywords: | Merged in:
Authors: Simon King | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
public/ticket/16453 | 9d56888d08c500f692116354e5ba0f498a84c6d0
Dependencies: #15820 #17564 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Hi again,
Replying to [comment:94 SimonKing]:
> Replying to [comment:93 vdelecroix]:
> > These paths have more applications than quivers (e.g.
[https://github.com/coulbois/sage-train-track train-tracks for free group
automorphisms]). Could you move it from `src.sage.quivers` to
`sage.graphs`?
>
> `sage.graphs` is quite large already, that's why I created the new
module `sage.quivers`, for everything that implements representation
theoretic aspects of directed multigraphs.
>
> I could imagine to use cythonized path algebra elements (see #17435) to
provide a better implementation of free associative algebras, but a
potential application is no reason to move the code, IMHO.
>
> Do you really need oriented paths for train tracks? Or do you rather
need sequences of integers to implement train tracks? If the integers are
subject to a global bound, then see
`sage.data_structures.bounded_integer_sequences`.
Yes, I really mean oriented paths. And also (di)graph maps, that is
function that maps edges to paths. These are not at all quiver morphisms
as they are defined in wikipedia.
> > And also remove the name 'quivers' from there.. why not `GraphPaths`?
>
> Most people understand "graph" as a non-directed graph. But we are
talking here about objects for which orientation is absolutely essential.
The original Python code for quivers and their representation had to make
a difference between two different notions of paths in a graph, one being
a sequence of vertices, the other being a sequence of edges. `QuiverPaths`
is about paths as sequences of ''directed'' edges.
Then `DiGraphPaths`? If you say `Quiver` in a talk on Geometric Group
Theory to talk about train-track, I bet that the public would be quite
surprised.
> When developing the current Python code for quiver representations,
there was some discussion about terminology. "Quiver" is a well-
established mathematical notion, so, good to use. It is the same as multi-
digraph, but is a shorter word. It seems that the decision was to use
"`DiGraph`" in Sage to denote the mere directed graph, whereas one uses
"`Quiver`" when one considers the directed graph as an algebraic object.
I see. But Quiver for me already denotes representation theory (you should
agree with me since you said "`sage.quiver` for everything that implements
representation theoretic aspects of directed multigraphs" and Wikipedia as
well).
> While it may be acceptable to replace the word "Quiver" by "`DiGraph`",
it can certainly not be replaced by the word "Graph". Hence, changing
`QuiverPath` into `GraphPath` would be misleading. I am against that
change.
All right, I understand. But `DiGraphPath`? My concern is that if Thierry
did not mentioned to me your previous ticket about sequences of bounded
integers I would never have found it.
> > Actually, for train track automorphisms one needs the groupoid of
paths (that is authorize to take edges in reversed direction). As far as I
understand, it is different from yours. Do you have an idea for a
compatible terminology?
>
> Well, the current terminology for the algebraic object formed by the
oriented paths in a multi-digraph subject to concatenation is "path
semigroup", and thus the terminology for your groupoid of invertible paths
would naturally be "path groupoid", isn't it?
It is. But I do not want to have it in `src.sage.quivers` and it would be
logical to have it close to implementation of the path semigroup (and they
will surely share some of their features).
I would be happy to finish the review of this ticket, but I want it to be
a starting point for the path groupoid as well.
Vincent
--
Ticket URL: <http://trac.sagemath.org/ticket/16453#comment:95>
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/d/optout.
