#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 SimonKing):
Hi Vincent,
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 cythoned 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`.
> 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.
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.
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.
> 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?
--
Ticket URL: <http://trac.sagemath.org/ticket/16453#comment:94>
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.
