5

I am running an astar algorithm on a graph that is partially (?) implicit - it is built from a large paging data source, but the graph is persistent. I need to handle paging in new parts of the graph whenever the astar algorithm gets to an area that is not fully paged in - ideally without starting the astar search over entirely.

I have tried a couple solutions but hit some road blocks, and I'm wondering if I'm missing something obvious or just approaching the problem wrong.

I am currently using boost 1.45 but plan to upgrade to 1.51.

First, I tried to modify the astar visitor such that when it determines it needs to page in new data, it calls a function on the graph and loads it in - however, since the graph is const, this is not possible. I have looked around and found this other question boost implicit graph and astar_search_no_init that references a presentation that suggests someone has done the work to make this possible, but it looks like the actual code is not available.

Second, I thought I might be able to exit the algorithm when I get to a place where I need to page in more data, and save the state of the distance_map, predecessor_map, and color_map so that I could use them to "resume" the search using astar_search_no_init. I am not sure whether this would work, because once I switch over to using astar_search_no_init, I see that while the visitor appears to do the work of pathfinding, the predecessor map is empty - since I am using the predecessor for building the path after the visitor is done, I need to know how the visitor is then building a path.

Here is the definition of my graph and how I am calling astar_search, if that helps at all.

typedef adjacency_list<
     vecS,         
     vecS,        
     undirectedS, 
     VertexInfo,        //contains geographic location     
     EdgeInfo,          //contains weight information             
     no_property,     
     setS>            
        BoostGraph;
...
ColorMap cmap = get(vertex_color_t, myGraph);           
astar_search(
     myGraph, 
     source,
     distance_heuristic(myGraph, destination), //geometric distance heuristic
     predecessor_map(&srcPredmap[0]).
     distance_map(&distMap[0]).
     color_map(cmap).
     visitor(astar_goal_visitor<vertex_descriptor>(destination, this)). //throws an exception when it finds the goal
     weight_map(make_function_property_map<edge_descriptor>(  //copied make_function_property_map functionality from boost 1.51 since I can't upgrade just yet
        EdgeWeightAdjuster(&myGraph, weightFactors))));       //modifies edge weights based on weightFactors construct
Community
  • 1
  • 1
user1299170
  • 108
  • 4
  • 1
    The "throws an exception when it finds the goal" idiom feels unfortunate. If success is considered exceptional then that implies that failure is considered natural. – Öö Tiib Sep 24 '12 at 00:28
  • That part was essentially copied from an example, but it seems like a convenient - if not "correct" - way to get the visitor to exit when it has found the vertex I want it to find, instead of traversing the entire tree - which in my case is impossible. Is there a better way to do this? – user1299170 Sep 24 '12 at 04:10
  • I'm not sure why your external data lays and so ... but couldn't you use a memory mapped file for this so that the underlying OS will do the paging when necessary? I've implemented this in GraphHopper (Java). And to make this efficient don't you additionally need to sort the nodes of your implicit graph according to Z-order or similar? Because A* could otherwise reach 'randomly' any page at any time and via sorting you'll reduce the 'randomness'. – Karussell Sep 24 '12 at 07:22
  • If you want to be correct re: const-ness, you can always construct your visitor with a non-const reference to the graph as a member. – Chris Dellin Nov 12 '15 at 01:55

1 Answers1

1

You write: "however, since the graph is const, this is not possible..." And what about a simple CAST (event an old C-cast)? You should give this option at least a try. Modifying the graph may invalidate iterators, etc. This is true. Nevertheless you should still try.

There is a difference between "technical const-ness" and "conceptual const-ness". In your case you will break only the technical, not the conceptual one.

Kirill Kobelev
  • 10,252
  • 6
  • 30
  • 51