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" but "QuiverPathMonoid" (or something similar)
OK
> and don't
> inherit from DiGraph.
Why? If it does, then a PathMonoid can immediately tell you its
vertices, connectedness, it can show itself, etc.
"M.vertices()" is a lot more convenient than
"M.underlying_digraph().vertices()".
> Long version: we have four kinds of objects:
>
> (1) Digraphs
> (2) Quivers
> (3) monoids of paths in a quiver (a better name is to be found since it's
> not exactly a monoid, but that's orthogonal to the discussion).
> (4) path algebras of quivers
>
> (1) and (2) are related by a isa relation: "a quiver is a digraph". So
> we could use the same class to model both quivers and digraphs. Or
> have a class Quiver that inherit from DiGraph.
Quiver is just another word for digraph (but mainly used by representation
theorists). Hence, I see no mathematical reason to have a new class for
quiver-the-digraph, and (1) is identical with (2)---we have three kinds of
objects.
If I look at Jim's code, then a Quiver differs from a digraph as
follows (and it *does* inherit from DiGraph):
a. It is supposed to be acyclic (and without loops)
b. It uses a UniqueFactory
c. It is immutable
d. It has a couple of methods that return representations, the path
algebra and such stuff
e. The notion of paths is different.
f. paths are *contained* in a quiver ("path in quiver"), but quivers
are no parent structures.
a. is not needed in much of the code. b. and c. are implementation details.
Actually I suggest to use UniqueRepresentation with an appropriate
__clascall__ instead.
d.-f. clearly shows that quivers in Jim's code are considered as algebraic
object, even though they are not implemented as such.
I think that my suggestion boils down to: "Be more consequent!"
I.e., do not implement quivers just with algebraic applications in mind, but
implement them *as* algebraic structures---and of course still inheriting
from DiGraph.
> (3) on the other hand should definitely be a separate class: the
> "monoid of paths in a quiver" is not a quiver and reciprocally.
Sure. (1) and (2) is DiGraph, and (3) is a new class. My working title for
this new class has been "Quiver", but it would be no problem to change it to
"PathMonoid".
> If I recall correctly, at Sage Days 40 it was though better to not use
> DiGraph as main entry point, because this would mean polluting the
> namespace of DiGraph with many representation theoretical methods like
> "projective modules".
OK.
> So the options are:
>
> - Implement the class Quiver, and use it as main entry point:
>
> sage: Quiver(...).projective_modules()
... which seems odd, since quiver *is* digraph.
> - Use something like QuiverPathMonoid as main entry point
>
> sage: QuiverPathMonoid(...).projective_modules()
... which is what I suggest,
> - Use something like QuiverPathAlgebra as main entry point
>
> sage: QuiverPathAlgebra(...).projective_modules()
... which would be fine, too. I wouldn't mind to have both ways.
And of course, we would like to have the following: If data are the
arguments used for creating a DiGraph, then we should have
sage: PathMonoid(data) is PathMonoid(DiGraph(data))
True
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
