#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 | c5dd56af126669e380f5a9fbb1680447123d22cc
Report Upstream: N/A | Stopgaps:
Branch: |
public/combinat/quivers |
Dependencies: #12412, #12413, |
#14806, #15491, #15623, #15810 |
-------------------------------------+-------------------------------------
Comment (by 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.
> - Is speed critical enough to motivate inheriting from ModuleElement?
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.
> - 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".
However, one should do one thing: Let it inherit from `WithEqualityById`.
> - _iadd_ and _isub_ change the element in place and therefore break
immutability.
Ouch, that's bad.
> Are those methods really necessary?
Well, `_add_` should be enough (then, `a+=b` will assign `a+b` to a new
instance under the old name `a`, but would not change `a` in place).
Having in place addition mutate `a` makes sense in some time-critical
applications, but of course not when it is hashable (in particular when
the hash is cached!).
I'll have a second look at the file, to see if there are more cases of
mutation.
> I am done with my teaching, and will have some time starting from March
1st. If the review is not finished by then, let me know which piece need
review and I'll work on it.
Thank you in advance!
Best regards,
Simon
--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:245>
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.
