In my articles I have to make a tradeoff between making things approachable and including all the little details you might need in a real project. I tend to err on the side of making things approachable, but that means people can get frustrated when trying to translate these topics into real code.
For my A* pages I have a “theory” page that describes the main concepts but doesn't go into detail with code, and then I have a separate “implementation” page that shows more of the code. I included some C++ code that is abstract and reusable, but I've been unhappy with it. I decided to simplify it a little bit:
- I dropped the template parameter for
SimpleGraph
because it's only ever used withchar
. - Even though
Location
is a property of theGraph
, the templated code for this is verbose and distracting so I madeLocation
a separate template parameter. - I switched from
unordered_set
andunordered_map
toset
andmap
; in practice you might prefer a hash table or an array, depending on the location type, but it's hard to pick one of these that's best for all cases. - I dropped some of the reference and const parameters.
- I switched from set.count() to set.find() to test membership.
- I wrote out explicit types instead of using
auto
. - I used
std::xyz
instead ofusing
to omit thestd::
namespace.
I have mixed feelings about most of these, and went back and forth a few times before deciding I'm overthinking it and just going with my gut.
Before:
template<typename Graph> void dijkstra_search (const Graph& graph, typename Graph::Location start, typename Graph::Location goal, unordered_map<typename Graph::Location, typename Graph::Location>& came_from, unordered_map<typename Graph::Location, double>& cost_so_far) { typedef typename Graph::Location Location; PriorityQueue<Location, double> frontier; frontier.put(start, 0); came_from[start] = start; cost_so_far[start] = 0; while (!frontier.empty()) { auto current = frontier.get(); if (current == goal) { break; } for (auto& next : graph.neighbors(current)) { double new_cost = cost_so_far[current] + graph.cost(current, next); if (!cost_so_far.count(next) || new_cost < cost_so_far[next]) { cost_so_far[next] = new_cost; came_from[next] = current; frontier.put(next, new_cost); } } } }
After:
template<typename Location, typename Graph> void dijkstra_search (Graph graph, Location start, Location goal, /* out */ std::map<Location, Location>& came_from, /* out */ std::map<Location, double>& cost_so_far) { PriorityQueue<Location, double> frontier; frontier.put(start, 0); came_from[start] = start; cost_so_far[start] = 0; while (!frontier.empty()) { Location current = frontier.get(); if (current == goal) { break; } for (Location next : graph.neighbors(current)) { double new_cost = cost_so_far[current] + graph.cost(current, next); if (cost_so_far.find(next) == cost_so_far.end() || new_cost < cost_so_far[next]) { cost_so_far[next] = new_cost; came_from[next] = current; frontier.put(next, new_cost); } } } }
The code isn't as fast but I hope it's a little easier to read. I added a section at the end with the faster code.
My goal is to show how the algorithms work, and not to write reusable library code. That's not what I'm good at. Whenever I try to show code, I get into these messes. I hope the code I have is a reasonable starting point for anyone who's writing their own instead of using a library.
This year I'm trying to iterate more and publish things more often. Take a look at the updated A* implementation page and let me know what you think. I'll add suggestions to the Trello page.
Labels: pathfinding
Post a Comment