#7651: c_graph backends should include a "reversed" copy for digraphs in the
sparse case
----------------------------+-----------------------------------------------
Reporter: rlm | Owner: rlm
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.3.1
Component: graph theory | Keywords:
Work_issues: | Author:
Upstream: N/A | Reviewer:
Merged: |
----------------------------+-----------------------------------------------
Changes (by rlm):
* status: needs_info => needs_review
Comment:
Replying to [comment:7 ncohen]:
> I saw you replaced
> ...
> with
> ...
> I understand what you mean, but wouldn't it easier for developpers to
define a function "in_neighbors" or "out_neighbors" doing this stuff to
avoid dealing with the implementation of graphs when in the c_graph.pyx
file ( where the algorithm are more graph-theoretic and a bit further from
the implementation ) ?
On the level of c_graphs, there is no way to avoid the implementation of
graphs. You're using ints as vertices which may not line up with the
actual labels, and since you're calling methods of self._cg, there's no
way around it. If you want to write on a more friendly level, you need to
sacrifice some speed, since on the level of (mostly Python) backends, the
vertex labels are honest, and 'in_neighbors' is the appropriate function
there.
> This kind of thing is bound to reappear very often as we write
algorithms in Cython... :-)
This is only relevant to very low-level functions. In which case you *are*
implementing graphs :)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7651#comment:9>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
