Are these bugs?

Hi all, I'm trying to verify that I'm looking at bugs in graph_tool, and
not my own user error.

A little background:

I'm using graph_tool to search over graphs that have been generated by
graph_tool.generation.geometric_graph(). The graph represents an occupancy
grid that some simulated robots are traversing. The robots do not know
apriori which vertices are occupied, so they have to update their own
internal maps of the world as they try to move. They do this by updating
an internal edge filter (one for each robot) which filters out
untraversable edges. In this way, I have one graph, and multiple edge
filters, which works fairly well when I'm trying to use either
graph_tool.search.dijkstra_search() or graph_tool.search.astar_search()
functions to decide where to go next (I swap filters more or less non-stop).

To test out how well this works, I'm randomly generating graphs and
occupied vertices, and then running my code on those randomly generated
graphs. Sometimes I'll end up with 50-60 tests successfully completed, and
sometimes it'll die on the first test. I have no idea when or how it will
die, and when I've set up code to draw the graph immediately prior to
calling either dijkstra or astar, the graphs don't look particularly
strange, nor do they have anything in common with one another. It just
dies with a "RuntimeError: maximum recursion depth exceeded" exception as
shown below.

I'm also getting the divide by zero errors that cairo is complaining about,
but I'm less worried about those as they are just part of my debugging
display code. In the worst case, I can find a way of displaying everything
using some other method.

Build info:

uname -a

Linux forge 3.2.0-40-generic #64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

python

Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

numpy.__version__

'1.6.1'

graph_tool.__version__

'2.2.23 (commit 66e8c6a6, Wed Mar 20 14:51:22 2013 +0100)'

Note that I built it with OpenMP enabled. If someone can tell me how to
enable more debugging output, I can do that and send the output somewhere.

Thanks,
Cem Karan

The complete stack trace:

ckaran(a)forge:~/fuerte_workspace/gridWorldSimulator/src$ nosetests
--nocapture --nologcapture -x
Random_walk_robot_test.py:Random_walk_robot_test.test_call
..../usr/lib/python2.7/dist-packages/graph_tool/draw/cairo_draw.py:957:
RuntimeWarning: divide by zero encountered in double_scalars
  zoom_y = (geometry[1] - sum(y_delta)) / (y_range[1] - y_range[0])
......................../usr/lib/python2.7/dist-packages/graph_tool/draw/cairo_draw.py:956:
RuntimeWarning: divide by zero encountered in double_scalars
  zoom_x = (geometry[0] - sum(x_delta)) / (x_range[1] - x_range[0])
.E

attachment.html (5.25 KB)

To test out how well this works, I'm randomly generating graphs and
occupied vertices, and then running my code on those randomly
generated graphs. Sometimes I'll end up with 50-60 tests successfully
completed, and sometimes it'll die on the first test. I have no idea
when or how it will die, and when I've set up code to draw the graph
immediately prior to calling either dijkstra or astar, the graphs
don't look particularly strange, nor do they have anything in common
with one another. It just dies with a "RuntimeError: maximum
recursion depth exceeded" exception as shown below.

Looks very strange. Could you please provide a minimal self-contained
example which triggers the problem?

I'm also getting the divide by zero errors that cairo is complaining
about, but I'm less worried about those as they are just part of my
debugging display code. In the worst case, I can find a way of
displaying everything using some other method.

See if the vertex positions values are strange. Again, a minimal example
would allow me to understand the source of the problem.

Cheers,
Tiago

I'll pull together the code from the tests I'm doing, but it will take me a couple of days to get the appropriate releases through work. What would be the best way for me to get it to you? Just email you a tarball of it all?

Thanks,
Cem Karan

Would it not be possible to isolate one single graph and the operation
on it which triggers the problem in a single small script?

Cheers,
Tiago

I haven't tried that, but if my latest tests fail, then I'll try to isolate it as you suggest. If I can't find a particular graph that fails (or a set of them), I'll send you the code instead.

The issue may resolve itself though; I'm in the process of installing the latest version of boost to see if that'll solve the problem. I'll know more by Sunday.

Thanks,
Cem Karan