Hi Simon,
On Mon, Apr 29, 2013 at 03:18:59PM +0000, 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 quiver-the-digraph?
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) and don't
inherit from DiGraph.
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.
(3) on the other hand should definitely be a separate class: the
"monoid of paths in a quiver" is not a quiver and reciprocally.
(4) idem
Now the question is what should be the main entry point for users.
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".
So the options are:
- Implement the class Quiver, and use it as main entry point:
sage: Quiver(...).projective_modules()
- Use something like QuiverPathMonoid as main entry point
sage: QuiverPathMonoid(...).projective_modules()
- Use something like QuiverPathAlgebra as main entry point
sage: QuiverPathAlgebra(...).projective_modules()
I guess I'd lean for the latter, but without strong preference.
> Is your functorial construction patch on trac?
No. It's in the Sage-Combinat queue. I won't waste time uploading it
on trac until it's in a reasonably final. Or more likely, I'll do the
final development using the new workflow and GIT.
> I couldn't use the category of monoids for obvious reasons. So, I
> would use the category of magmas---no problem for now.
Cool!
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
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.
