#12630: Add representations of quivers and quiver algebras to sage
-------------------------------------+-------------------------------------
Reporter: JStarx | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: algebra | Resolution:
Keywords: algebra, quiver, | Merged in:
module, days49 | Reviewers: Simon King
Authors: Jim Stark, Simon | Work issues:
King, Mathieu Guay-Paquet, Aladin | Commit:
Virmaux | 48a8fed2d0503ea4bf4312c9a942c1fd024b0917
Report Upstream: N/A | Stopgaps:
Branch: |
public/combinat/quivers |
Dependencies: #12412, #12413, |
#14806, #15491, #15623, #15810 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:245 SimonKing]:
> Replying to [comment:244 nthiery]:
> > - Maybe {{{QuiverRepElement}}} could inherit from
{{{ElementWrapper}}}? That would give it e.g. the hash for free.
>
> No idea about this. I don't know how it works.
It's really just a simple base class that handle the trivial stuff
when one wants to implement an element whose data structure consists
of a single object (e.g. a tuple). See ElementWrapper?
> We are talking about `QuiverRepElement`, right? Well, eventually this
should become faster, too (but first, I'll focus on paths). After all, I
plan to implement an F5 algorithm for modules over path algebras, and
speed will be absolutely critical. But this could actually require more
trickery (even free-lists, to save the time that is vasted for creating
and deleting elements)---so much that it could be that internally I will
use classes that will not be exposed to the user. So, perhaps internally I
will use a class (certainly Cython cdef class) that has almost nothing to
do with the current implementation.
Oh I see; I mistakenly thought it was modeling an element representing
a quiver representation. Not an element thereof. Now I see the
potential need for speed.
> > - is there a reason to use {{{UniqueFactory}}} rather than
{{{UniqueRepresentation}}}?
>
> We have long code to create a cache key, and we have long code to create
an object from a given key (which involves choosing among different
implementations). I think `UniqueFactory` is a better tool, since (in
contrast to `UniqueRepresentation`) it allows for a clean separation
between the two requirements "create key" and "create object".
Ok. At some point we should think about whether we could make a better
distinction in UniqueRepresentation. But that's of course for later.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:249>
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/groups/opt_out.
