It's reasonably common to have a database containing a few thousand or million points in some high-dimensional space. If you have some "query point" in that space you might like to know whether there is a match in your database.

If you're looking for an exact match then the problem is pretty easy -- you just come up with a suitable hash algorithm that hashes points in your space and build a big old hash table. That's extremely fast lookup. But what if you're not looking for an exact match, you're looking for a close match? Perhaps there is some error, either in the measurements that went into the database or the measurement of the query point, that needs to be accounted for.

Now the problem is "for a given query point, what is the closest point in the database to it?" That's not a problem that's amenable to hashing. (Well, you could use a Locality Sensitive Hash algorithm, but we'll rule that out later.)

What if the closest point to the query point is so far away from the query point that it's more likely that the query point simply has no match at all in the database? In that case we don't really want the closest point, because that's not really relevant.

Essentially you can think of every point in the database as being surrounded by a "probability sphere". As you move farther away from a given point in the database, the probability that you have a match to that point gets smaller and smaller. Eventually its small enough that the probability that the query point is "junk" -- not a match to any point in the database at all -- gets larger than the probability that the closest point is a match.

To sum up the story so far: we've got a query point, which may or may not correspond to a point in our database of points. We need a way to say "is this point junk? If not, what are some reasonably close points in the database that might be matches?"

Here's an idea for an algorithm: compute the distance between the query point and every point in the database. Discard all points where the distance is outside of a certain tolerance. Geometrically, we're **constructing a sphere of a certain radius around each point in the database**. We check to see whether the query point is inside each sphere.

We know that the volume of an n-sphere is tiny. That's good. If we do get a match then we know that the match is probably in a very small volume and therefore likely to be correct. However, we also know that such a system is not tolerant of small errors in many dimensions -- because distances grow so fast, a small deviation in many dimensions leads to a big distance. That means that we probably will have to construct a sphere with a **fairly large radius** in order to allow for measurement error in many dimensions.

But that's not really so bad. What's bad about this scheme is that if there are a million points in the database then we have to calculate one **million Cartesian distances for every query**. In a 100-dimensional space that means computing 100 differences, 100 multiplications, 100 additions and one comparison a million times just to do one query.

We could build some optimizations in -- we could check at each addition whether the total radius computed so far exceeds the tolerance and automatically discard the point. Maybe we could cut it down to on average 50 differences, multiplications and additions per point -- but then we've just added in 50 comparison operations. ** No matter how you slice it, we're doing a lot of math**.

A hash table works by automatically discarding all but a tiny number of points, so that you just have to check a small number rather than the whole database. A Locality Sensitive Hash algorithm (which I might write about in another series) would work well here except that LSH algorithms have lousy performance if a large percentage of the queries are junk. Let's assume that there are going to be a lot of junk queries. Is there some way that we can more rapidly find valid points?

We learned earlier that 99.9% of the volume of an n-sphere is contained by an n-cube with the same center as the sphere and an edge length fairly close to that of the radius.

Hmm.

Determining if a point is inside a cube is a lot less math than determining if a point is inside a sphere. With a cube you don't need to compute any distance. You just compare the upper and lower boundaries of each dimension to the position of the point in that dimension and see if they overlap. For a 100-dimensional space, that's 100 to 200 comparisons per point, and as soon as even one of the dimensions is bad, you can skip this cube and move on.

Maybe we can get it down to around a few dozen comparisons per point for a straightforward linear search. That's pretty good compared to the distance metric.

We know that a cube of a given side is much, much more voluminous than a sphere of similar radius. We don't really care about the 0.1% false negative rate caused by clipping off the bits of the sphere that are close to the axes. But what about the false positive rate of the huge volume of points that are inside the cube but not inside the sphere? These are easily dealt with: once we have winnowed the likely matches down to a small subset through the cheap cube method, we can do our more expensive spherical check on the small number of remaining candidates to eliminate false positives.

By this point your bogosity sense should be tingling.

**This armchair performance analysis is completely bogus**. Yes, ~70 comparisons is cheaper than ~100 subtractions, multiplications and additions. Who cares? **That's not the most expensive thing**. Performance analysis always has to be about what the most expensive thing is.

Think about this database for a moment -- a million records, each record is a 100-dimensional point in some space. Let's suppose for the sake of argument that it's a space of 8-byte double-precision floats. That's 800 megabytes of memory. Now, there are certainly database servers out there that can keep an 800 meg file in physical memory, but we're clearly pushing an envelope here. What if the database is large enough that there isn't enough physical memory to keep the whole thing in all at once? At that point, the cost of iterating over all one million records becomes the cost of swapping big chunks of the database to disk and back.

Now consider what happens if there are multiple threads doing searches at the same time. Unless you can synchronize them somehow so that they all use the same bits of the database at the same time, you're just going to exacerbate the swapping problem as different threads access different parts of the record set. (And if you can synchronize them like that, why even have multiple threads in the first place?)

The fundamental problem with both the sphere and the cube methods isn't that the math per record is expensive, it's that they must consider every record in the database every time you do a query. Getting those records into memory is the expensive part, not the math.

What we really need is some **index** that is small enough to be kept in memory that quickly eliminates lots of the records from consideration in the first place. Once we're down to just a few candidates, they can be pulled into main memory and checked using as computationally-intensive algorithm as we like.

There's no obvious way to build an index of hyperspheres, but there might be things we can do with hypercubes. Stay tuned.