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 >> structure"? > > 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
Why? And what is "path" here? If path is an instance of a class that is derived from sage.structure.element.Element, with parent a "quiver as an algebraic structure", then asking "path in quiver" is totally natural. > whereas this is natural: > > sage: path in quiver.paths() Why is this natural? Note that we already have DiGraph. From my perspective, it in fact would be more natural to consider the quiver as the set of paths with concatenation, and as the same time as a DiGraph, so that you can do sage: path = quiver([list,of,some,arrows]) sage: path in quiver True sage: quiver.edges() # method inherited from DiGraph ... 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? >> Florent suggested to call it "monoidoid". Because of multiple idempotents, >> I could imagine "multimonoid". But of course, we could just describe it >> as an associative magma. > > From "http://en.wikipedia.org/wiki/Groupoid"; this would be a > semicategory :-) Do you want to create the category of semicategories?? >> Third question: Do you think we should create categories of "associative >> magmas" and of "associative additive magmas", fitting them between >> (additive) magmas and (additive) monoids? > > Yes. Actually my functorial construction patch creates those two > categories. Great! > Finishing this patch is on the top of my list starting from next week > when the semester here will be over. But it's pretty large and has a > some dependencies, so I can't make any timeline promise. The one good > thing is that most dependencies are on patches that we are already > working on together anyway :-) Is your functorial construction patch on trac? > Question: can you afford this dependency, or alternatively cheat > temporarily and use the semigroup/monoid category for now? I couldn't use the category of monoids for obvious reasons. So, I would use the category of magmas---no problem for now. >> - Do you agree that an improvement of efficiency should be addressed >> after establishing the quiver as algebraic structure (after all, >> premature optimization is the root of all evil)? Or should one try to >> implement "paths with concatenation" in Cython right away (the current >> code at #12630 is python)? > > Incremental is good. I think the task at hand is pretty large, so if > there is a natural way to split it into smaller tickets, go ahead. Since I am still not convinced that there should be a separate class for quiver-the-digraph, I suggest the following plan: On #12630: - Let Quiver_generic inherit from both DiGraph and Parent, and initialise it in the category of magmas. Keep using a UniqueFactory. - Do not use UniqueRepresentation on QuiverPath. Instead, derive it from Element (or some algebraic sub-class) and establish it as element class of Quiver_generic. - Do *not* require acyclicity when creating a quiver. Only test for acyclicity where this is really needed (e.g., for Quiver representations). I think these changes on #12630 would be relatively mild---after all, what the ticket is really about is "representation of quivers and quiver algebras", which wouldn't change much by what I suggest. Functorial constructions: - Let Quiver_generic use the category of associative magmas (or something better) as soon as your functorial construction patch is in Sage. Performance post-#12630 - Use Cython for QuiverPath. - Use some more efficient memory representation than "list of arrows". I have experimental code (that rotted for some months, though) where paths are determined by a bitpacked sequence of numbers, where the numbers correspond to a local numbering of outgoing arrows on a vertex. - Take care of a monomial ordering of paths. Eventually, I need to be able to use a negative length ordering, but it would be great to have freedom of choice. On top of the previous: - Finite dimensional quotients of quiver algebras (multiplication perhaps being implemented by matrix multiplication) - ... using as basis the paths that do not occur as leading monomials of the quotient relations - modules over finite dimensional quotients of quiver algebras - F5 algorithm for these modules. 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.
