Documentation
(http://projects.skewed.de/graph-tool/doc/search_module.html#graph_tool.search.astar_search)
says that both 'zero' and 'infinity' parameters type should be int or float.
To me this is wrong, their type should be the one used to represent costs.
A confirmation of that is that I used to work with 2.2.17 version. While
moving to 2.2.24, I encounter a bug that has been introduced in 2.2.18
version (commit 016d8244a24b3dba812ce2bb305e2e1f09e85154)
In my application, 'cost_map' and 'dist_map' are both created with
graph.new_vertex_property("object")
'zero' and 'infinity' are two specific Cost() instances, which is a type
with a __init__ function that don't take any other argument than the regular
'self' one). The call to astart_search is like this:
gt.astar_search (g=MyGraph, source=MyGraph.vertex(0), weight =
MyGraph.new_edge_property("object"),
visitor=MyVisitor, dist_map =
MyGraph.new_vertex_property("object"),
cost_map = MyGraph.new_vertex_property("object"),
pred_map = MyGraph.new_vertex_property("int"),
zero = CostZero, infinity = CostInfinity, implicit
= true)
While it used to work with 2.2.17, now my application crashes in
search/__init__.py, at the beginning of the astart_function, more precisely
the instruction in the following "try" section:
try:
zero = _python_type(dist_map.value_type())(zero)
except OverflowError:
zero = (weight.a.max() + 1) * g.num_vertices()
zero = _python_type(dist_map.value_type())(zero)
I don't get why we try here to convert 'zero' (and right after this,
'infinity') whereas it already has the correct type. What did I miss?
--
View this message in context:
http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/gt-astar-search-zero-and-infinity-parameter-type-interpretation-is-wrong-tp4025088.html
Sent from the Main discussion list for the graph-tool project mailing list
archive at Nabble.com.
_______________________________________________
graph-tool mailing list
[email protected]
http://lists.skewed.de/mailman/listinfo/graph-tool
