Here are a couple similar graphs that go fine:
G = {0: {1: None, 6: None, 7: None, 10: None, 11: None, 12: None, 13:
None}, 1: {0: None, 6: None, 7: None, 10: None, 11: None, 12: None,
13: None, 18: None}, 2: {3: None, 4: None, 5: None, 8: None, 9: None,
14: None, 15: None, 20: None}, 3: {2:
Okay, I guess the profiler is only profiling Python calls, so it's not
so good to figure out what's going on. There are some linux tools that
may help with this. I will look into this and post back in a while
(maybe 1 week) when I have something.
Thank you for reporting this important example.
We didn't really have any expectations about the size of these
automorphism groups (this isn't the central part of the project), so
I'm not sure if this output is reasonable for the given graph. But
here's what search_tree gives:
([[0, 6, 2, 3, 4, 5, 1, 7, 8, 14, 10, 11, 12, 13, 9, 15, 16, 17,
On Nov 23, 4:05 am, Dustin Pluta [EMAIL PROTECTED] wrote:
Hi,
Hello Dustin,
I ran across a graph and partition for which it takes the search_tree
function 6 hours on my machine to complete, and I was wondering if
this is something to be expected, or a possible bug. I've been
working
The complexity predicting the running time of this algorithm is
difficult to analyze, and depends very deeply on the structure of the
graph itself. With G and Pi as you have them, I'm looking at
sage: g = Graph(G)
sage: g.show(partition=Pi)
and it seems to be moderately symmetric. Usually when
PS - A mugshot of the culprit:
http://www.rlmiller.org/bug.jpg
On Nov 23, 10:16 am, Robert Miller [EMAIL PROTECTED] wrote:
The complexity predicting the running time of this algorithm is
difficult to analyze, and depends very deeply on the structure of the
graph itself. With G and Pi as you
