Sequential A*

Everyone knows and loves the A* search. If you're familiar with it and want to jump ahead to parallelizing it, please feel free.

For those who aren't familiar with A* and don't want to read the complete treatment above, A* is a type of best-first search. It uses a heuristic function to estimate the distance between any node under consideration and the goal. Essentially, A* uses extra information about the problem domain to make informed choices when it considers where to go next.

Take for example the problem of a programmer who lives in San Francisco who has accepted a job in Boston. She's packed all her stuff in a moving van which gets terrible gas mileage, so she's taken out the highway map to find the shortest route between the cities.

Since she's a programmer, her map shows an abstract version of (a country remarkably similar to) the United States: only cities and highways are portrayed, in the form of vertices and edges of a weighted graph.

She sees that, starting in San Francisco, she has four choices for the first leg of her trip: she can drive to Portland, Reno, Las Vegas, or Los Angeles. From Portland, she can continue to Reno (backtracking to SF being forbidden); from Reno, she can go to Portland, Denver or Las Vegas; from Las Vegas, to Reno, Denver, Phoenix or Los Angeles; and from Los Angeles to Las Vegas or Phoenix. This is starting to get complicated, so she draws a tree to help her evaluate her options:

Looking at this, she and we can see that going from San Francisco to Reno to Las Vegas would be a trip of 670 miles. She could keep systematically enumerating the possible next moves from each city in a breadth first search, and it certainly will find a route to Boston, but it's not guaranteed to be the best possible route, and it may take quite a while to find any kind of solution.

Then inspiration strikes. She takes out a ruler and measures the straight-line distance from each city to Boston, never mind if there's actually a direct road or not. The first few make the map look like:

Now she knows as above that a trip from San Francisco to Reno to Las Vegas will be 670 miles. But now she can also estimate that the balance of the trip, from Las Vegas to Boston by some route, will be another 2370 miles. Adding those together gives her an estimate of 3040 miles for the length of the shortest trip that starts by going from San Francisco to Reno to Las Vegas and ends up in Boston.

At every step in the A* search, she picks the next city with the smallest total estimate route length. So at the beginning her search tree is as simple as can be:

The only state she knows of is when she is in San Francisco. She has traveled 0 miles to get there and has an estimated 2700 miles left to Boston. Adding these together gives her a total estimated trip length from here of 2700 miles.

In A*, you always expand the unexpanded state with the lowest total estimate. Since there's only one possible state, it'll have to do for a start. Our heroine looks at the possibilities from this state and comes up with:

Looking at the unexpanded states, she notes that the route beginning by driving from San Francisco to Reno has the lowest estimated total cost. Being a methodical type, she asks herself "Is Reno Boston?" If you happen to have visited both cities, you already know the answer to this. So she repeats the process again, considering where she could go from Reno:

At this point she has six possible routes to consider, and she sees that the route from San Francisco to Reno to Denver has the lowest estimated total cost. Denver is not Boston either, so she repeats the process again, and again, until a route to Boston emerges.

Note that, while we're imagining examining the tree directly for our next move, in practice you use a priority queue instead. A priority queue is just a list of items, each of which has a numerical value called a "priority" associated with it. When you add new items to the list, instead of just sticking them on the end, you put each in the list so that the list stays in ascending order of priority. In A*, the priority value we use is the estimated total distance.

So at the start we'd have a priority queue with just one item in it:

Node	Estimated Total Distance
San Francisco	2700

San Francisco is at the head of the queue, so we take that off, expand it, and add the results back into the queue:

Node	Estimated Total Distance
San Francisco to Reno	2740
San Francisco to Las Vegas	2930
San Francisco to Los Angeles	2980
San Francisco to Portland	3170

Now Reno is at the head, so we take that off, expand it, and add the results back in:

Node	Estimated Total Distance
San Francisco to Las Vegas	2930
San Francisco to Los Angeles	2980
San Francisco to Reno to Denver	3020
San Francisco to Reno to Las Vegas	3040
San Francisco to Portland	3170
San Francisco to Reno to Portland	3280

In the next iteration, we'd expand routes that start by going from San Francisco to Las Vegas, and so on until we find our way to Boston.

A proof is beyond the scope of this article, but as long as the estimating function is "optimistic" (to use the formal term, admissible), that route is guaranteed to be the best possible one. An optimistic estimating function can underestimate the remaining cost of a route, or get it exactly correct, but isn't allowed to ever overestimate that cost. The straight-line estimation we're using here is certainly optimistic: no matter what route you take from Point A to Point B, you're never going to beat the straight-line distance between them.

To recap, her strategy for picking the best route by A* is:

1. Take the state at the head of the priority queue off of it. It's guaranteed, of all the states we know, to have the smallest estimated total distance.
2. If that state corresponds to being in Boston, we've found our route and can stop.
3. Otherwise, look at the map and find which cities we can go to without doubling back on our route. Calculate their estimated total distances by adding the known distance it takes to get there to the estimated remaining distance to Boston. Based on those estimated total distances, add them to the appropriate place in the priority queue.
4. Go back to the top and repeat until we've gotten to Boston.

A lot of the work of A* can profitably be done in parallel if we have multiple CPUs to work with. Suppose that we have three CPUs available: instead of picking the lowest estimated total cost node and expanding just that, we pick the three lowest estimated total cost nodes and assign each to a CPU.

To return to the example above, the first step (expanding the "San Francisco" state) would still work the same, since there's only one node to look at. But on the second iteration, we can expand three nodes at once, going from:

to:

This lends itself to a manager/worker architecture. The manager keeps the priority queue of states and assigns work to the workers. The workers expand the states and pass results back to the manager. A diagram of messages passing between processes in our example might look like:

Notice that we're not assuming any relationship between the order in which we assign work to workers and the order in which they actually finish. We just pass out work in an arbitrary order and add results to the queue whenever they come in.

There's a trap here. Since you don't know the order that results will come back to the manager, it's theoretically possible for it to find a solution that's not the best possible solution. In fact, if you're really unlucky, it may find the worst possible solution.

We need to do a little more work to ensure that we get the best solution. Rather than stopping when we find a solution, we take the cost of that solution, and consider it as an upper bound on the cost of the best possible solution. This means we can throw out any unexpanded node with an estimated total cost greater than that bound. Recall that our estimation function is allowed to underestimate the cost of a path, but never to overestimate it. Hence if the estimate is greater than this upper bound, the actual cost is guaranteed to also be greater.

When we ask a worker to expand a node, we can also pass it this upper bound. The worker then expands the node as normal, but filters out any results with estimated total cost greater than the upper bound. The manager never sees these, and never adds them to the queue in the first place.

With these rules in place, we know we're done when the queue is empty and all workers are idle (and thus we're not expecting any new results). At this point, the best solution we know of is the best one there is.

To recap the parallelized algorithm:

1. Assign nodes off the top of the queue to workers until all workers are busy or the queue is empty (assuming none of your starting nodes are solutions).
2. When a worker responds, add its results to the queue in the proper order, removing any with an estimated cost greater than the upper bound on cost (originally infinity).
3. Take the node off the top of the queue. If it's a solution, remember its cost as the upper bound on cost. If not, give it to the newly-freed worker to expand.
4. Repeat until all workers are idle and the queue is empty. The best solution the manager knows of is now the best solution there is.

For those interested in playing with code to illustrate this algorithm, I've uploaded an example implementation in Erlang to Github, under an MIT license. It's very pre-alpha, just meant for a proof of concept. If I think of a practical use for it, I'll be cleaning it up. Of course, if you beat me to it, you're welcome to do the same, especially as the chances of me actually making a production-quality library out of this are slim.

This is also the first library that I have written using EUnit, a testing framework for Erlang. My first cut at this library was plagued by odd and obscure bugs, so I threw it out and rewrote it from scratch using EUnit for TDD, which it turned out to be well suited for.

The library is available here on GitHub. Since it's my understanding that Erlangers (Erlangists? Erlangueons?) prefer to use Mercurial, I'll also make a Mercurial repo available later this week, once I've had time to learn how to use it it's also available via Mercurial on bitbucket.org.

Advice (especially about how to better use EUnit), criticism, and offers of excellent things are as welcome as always.

Thus, over the course of a few weeks, I put on my JavaScript hat whenever I had a free hour, and whipped up what I couldn't resist calling the Dopp-down menu. It's essentially a small (218 LOC), simple, but flexible autocomplete widget, built on top of jQuery. In the simplest case, if you follow the conventions it's expecting, you just need to give it:

• a selector to a text field to watch and complete;
• a selector to an element to populate with suggestions;
• and a URL that can return search results.

With just a few more options, you can also have an element that gets filled in with the most popular choices, to get the user started.

Here's an example of how you call it, deliberately written to show off a number of options, taken from the demo application:

It's true that jQuery UI has its own perfectly good autocomplete widget. But here's one thing to consider: the unminified version of dopp_down_menu.js is 10K, just over half the size of the minified version of jQuery UI's autocomplete widget. Minified, dopp_down_menu.js squishes down to a svelte 6K. Also, as far as I know, jQuery UI autocomplete doesn't support the "popular choices" functionality that the Dopp-down menu does.

So please give it a try! I will add some documentation soon (promise) have now documented the API, and as always, feedback and pull requests are most welcome.

You might write part of the logic for RBAC like this:

But what's wrong with doing it this way?

• You end up repeating Role.find_by_name(...) a million times. Of course, in practice, you'd write methods with names like is_admin?, is_moderator?, is_regular_user?. But these all have the same structure and vary only in what role they're concerned with, indicating that we have a chance to DRY things up.
• You're hardcoding strings. One of the first things I learned in programming, and quite likely one of the first things you learned, is that this always leads to trouble eventually. A role's name will change, or you'll type "administrator" where you meant "admin", or any of innumerable variations.
• You'll often want to refer to values bootstrapped in this way all together, perhaps in a <select> or a listing on an index page. Of course you can always find(:all) and grab every instance of that model, but I find that you often want to treat the bootstrapped values differently from other instances that might get created.

Dan Chak, in his book Enterprise Rails, suggests that you create a constant to refer to this kind of data. I don't agree with everything in this book, but I do believe that this particular advice is on the money. So our example from above might turn into:

This could still be DRYer, but it's definitely a step in the right direction.

Having defined a few gazillion of these constants in some of my code, I wrote and recently open-sourced a gem called has_named_bootstraps (with source on GitHub) that automates defining these constants. There are plenty of options to play with, but the most basic case just looks like:

The constants R_AND_D, MARKETING, and HANDSOME_DEVILS are now all defined on Department.

Feedback, bug reports and pull requests are all most welcome. I'm eager to hear what you think.

When include NiftyCapabilities is evaluated in Monkey, the hook NiftyCapabilities.included is called with Monkey passed as a parameter. NiftyCapabilities.included then calls Monkey.extend(ClassMethods), which adds the instance methods of NiftyCapabilities::ClassMethods to the class Monkey. Since a class method in Ruby is just an instance method of a Class object, the instance methods in NiftyCapabilities::ClassMethods are now class methods on Monkey. Hooray for first class classes.

This standard idiom is great as far as it goes, but for this library I have one additional goal: to be as unobtrusive as possible. I'm concerned that if I add a Monkey.grab_banana method via this idiom I'll overwrite an pre-existing grab_banana method with unfortunate results.

The solution here is to borrow a principle from unobtrusive Javascript: you should add no more than one symbol to the global namespace. In this context, for "global namespace" read "class namespace." The natural way to do this is to add an inner module to Monkey and define these new methods in that inner module. Here's how:

Now when NiftyCapabilities.included(Monkey) is called, that here doc is evaluated in the context of the class Monkey. The result is as if we had written:

Let's flesh out our banana-grabbing capabilities to absolutely satisfy ourselves that the modules created are perfectly cromulent inner modules of our classes:

Which we can try out like so: