Hi all,
I hope I summarise the discussion correctly:
- There is no mathematical difference between a quiver and a digraph.
Hence, there will be no separate sub-class Quiver of DiGraph.
- How shall we call the algebraic structure formed by the paths in a
quiver? PathMonoid? PathMagma?
Hi Simon,
On Mon, Apr 29, 2013 at 03:18:59PM +, Simon King wrote:
Let me try to rephrase the question: Since we already have DiGraph, why should
we have *two* separate classes, namely for quiver-the-digraph and for
quiver-the-associative-magma? Why not just use DiGraph for
Hi Nicolas,
On 2013-05-01, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
I definitely see your point about not multiplying the number of
classes for no reason. The executive summary of the rant below is: I
am very happy with your proposal; just don't call the parent of the
paths Quiver
Hi Simon,
On Wed, May 01, 2013 at 03:44:06PM +, Simon King wrote:
and don't have PathMonoid inherit from DiGraph.
Why? If it does, then a PathMonoid can immediately tell you its
vertices, connectedness, it can show itself, etc.
Yup. But then you have an object that bears
On 2013-04-29, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
I would tend to keep them separate; a quiver and its sets of paths are
different mathematical objects. It would be weird to ask for:
sage: path in quiver
whereas this is natural:
sage: path in quiver.paths()
By
Hi Nicolas,
On 2013-04-29, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
First question: Would you agree that a quiver should be identified with
the algebraic structure formed by paths with concatenation? Or should
quiver as a digraph be kept separate from quiver as an algebraic
