Responding to a comment from trac:
One problem IMHO with `c_graph` is that as is (correct me if I'm wrong)
we won't be able to have a fast `in_neighbors`.
This is certainly true, if you're using a SparseGraph to represent a
DiGraph. In this case, I think there should actually be two
Well, in my use of directed graphs I can swear I need to talk about
out-neighbors at least as often as I need to talk about out-
neighbors Storing them two time would not be a waste in opinion,
and anyway we can not afford to have only the out-neighbors
available... I have not read the
Just a random thought : wouldn't it be way more efficient to write the
definitions of a Graph ( and perhaps the basic functions too )
directly in C, then to wrap them through Cython ?
Nathann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group,
OK, these are both tickets now:
http://trac.sagemath.org/sage_trac/ticket/7640
http://trac.sagemath.org/sage_trac/ticket/7651
These will need to be dealt with before we can switch. I'm optimistic,
given that this is still a pretty short list. I hope everyone reading
this will try out the patch
On Wed, Dec 9, 2009 at 10:23 PM, Nathann Cohen nathann.co...@gmail.com wrote:
Just a random thought : wouldn't it be way more efficient to write the
definitions of a Graph ( and perhaps the basic functions too )
directly in C, then to wrap them through Cython ?
Nathann
Re: Cython vs C, there
On Tue, Dec 1, 2009 at 8:56 AM, Nathann Cohen nathann.co...@gmail.com wrote:
Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I
assure you it will be very hard for them to compete with LP on our
side and so many features around in Sage... As most of NetworkX's
functions are not
I have a patch making sage work with Netwotkx 1.0rc1 based on sage
4.3.alpha0, but it will probably conflict with many other graph
related patches...
If anyone wants to improve it, please do!
It's ticket #7608 now.
On Dec 1, 1:48 pm, William Stein wst...@gmail.com wrote:
The biggest problem we
Just to be clear, my patch is based on 4.3alpha0 and won't apply
cleanly to 4.3alpha1, that's why it's still marked as needs work.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For
patch updated. It should apply fine to sage 4.3alpha1 now.
Yann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at
Your patch exposes the function maximum_weight matching from
NertworkX !!!
There is a high chance that I may have written the patch for matching
using LP for naught, but an even higher chance that NetworkX's
function could be even more efficient (at least for small cases) !!!
Thank you very much
Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I
assure you it will be very hard for them to compete with LP on our
side and so many features around in Sage... As most of NetworkX's
functions are not very hard to rewrite once the basis is set ( graph
structure, neighbors, etc ) I
On Tue, Dec 1, 2009 at 8:56 AM, Nathann Cohen nathann.co...@gmail.com wrote:
Hmmm... If we can make Sage's C graphs as fast as NetworkX's , I
assure you it will be very hard for them to compete with LP on our
side and so many features around in Sage... As most of NetworkX's
functions are not
sage: sorted(g.degree(), reverse=True)
[4, 4, 3, 3, 2, 2, 2]
This is probably what I was thinking of; I didn't see sample code.
Probably in the situations I used, I just used g.degree() all by its
lonesome self, unsorted, because the cases I needed could be done by
hand.
- kcrisman
--
To
Hi kcrisman,
On Mon, Nov 30, 2009 at 10:42 AM, kcrisman kcris...@gmail.com wrote:
SNIP
That is odd; I am pretty sure there used to be such a method, maybe
two years ago?
Ticket #7564 [1] improves the documentation of the method
GenericGraph.degree() by adding two examples showing how one
On Nov 29, 2009, at 8:27 AM, Nathann Cohen wrote:
HMmmm...
I started creating new modules, and I wanted to split it piece by
piece, with time. Ticket #7365 creates a module named
graph_decomposition which I intend to fill ( but I will begin to write
these functions when this patch will be
HMmmm...
I started creating new modules, and I wanted to split it piece by
piece, with time. Ticket #7365 creates a module named
graph_decomposition which I intend to fill ( but I will begin to write
these functions when this patch will be merged and the file
created ).
Is it possible in Python
For example, I have been unable to find a
function/method to compute the degree sequence of a graph.
That is odd; I am pretty sure there used to be such a method, maybe
two years ago?
- kcrisman
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this
Hi kcrisman,
On Mon, Nov 30, 2009 at 10:42 AM, kcrisman kcris...@gmail.com wrote:
SNIP
That is odd; I am pretty sure there used to be such a method, maybe
two years ago?
It turns out there is such a function. One could use
Graph.degree_iterator() as suggested by mhansen, or Graph.degree() as
No answer to the main question, but just completing the timings:
sage: G=graphs.RandomGNP(300,.1)
sage: time d=[G.distance(i,j) for (i,j) in Subsets(G.vertices(),2)]
CPU times: user 3.67 s, sys: 0.00 s, total: 3.67 s
Wall time: 3.72 s
sage: time d=networkx.all_pairs_shortest_path(G)
CPU times:
You can obtain some c_grah in Sage with
cG = G.copy(implementation=c_graph)
I don't know how far the development is though.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more
20 matches
Mail list logo
