#12630: Add representations of quivers and quiver algebras to sage
-------------------------------------+-------------------------------------
       Reporter:  JStarx             |        Owner:  AlexGhitza
           Type:  enhancement        |       Status:  needs_work
       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                            |  72fb2eb71459f4ac76b0d922a7ad788c660a8017
Report Upstream:  N/A                |     Stopgaps:
         Branch:                     |
  u/SimonKing/ticket/12630           |
   Dependencies:  #12412, #12413,    |
  #14806, #15491, #15623             |
-------------------------------------+-------------------------------------

Comment (by ncohen):

 Hello !

 > Nathann, I have some questions concerning `all_paths`.

 Oh ?

 > I just notice: There is the method `all_paths_iterator`, and I expected
 it to be used in a generic implementation of `all_paths`. But in fact, the
 generic `all_paths` relies on `neighbor_out_iterator` (for digraphs, at
 least). Why is that?

 Answer #1: All I know about this code is that I do not like it. Nobody
 should enumerate paths in Python.

 Answer #2: Let me read that code...

 Well, I have NO idea why this thing is implemented twice. One function
 should be more than enough, and I do not yet why we have both a list
 version and an iterator version. The iterator version should be
 sufficient, we can wrap the call with `list` if needed, so well... `O_o`

 Those things should probably be merged. I don't like to see heaps involved
 in the code of `all_paths_iterator` though (which is only implemented for
 digraphs, for some reason). Plus I have absolutely NO idea why heaps are
 involved there. A list should be sufficient `O_o`

 > And in particular: Would `neighbor_out_iterator` be the correct place to
 change the behaviour of the `all_paths` method (depending on an optional
 argument, of course)?

 Hmmmmm... What would you want to change in `neighbor_out_iterator` ? My
 secret hope is that whatever you want `neighbor_out_iterator` to give you
 there is already another way to obtain it, for I don't really want to add
 anything smart in this function which we already try to make FAST. Tell
 me, and we'll find a way.

 Nathann

--
Ticket URL: <http://trac.sagemath.org/ticket/12630#comment:172>
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.

Reply via email to