## A plausible-sounding data structure that probably doesn’t exist

Here is a description of an abstract data type: a confluently persistent set data type containing a subset of the integers in a range $$[1..n]$$ and supporting $$O(\log(n)^c)$$ time creation, $$O(\log(n)^c)$$ time size query, $$O(n \log(n)^c)$$ time conversion to a duplicate-free list, and $$O(\log(n)^c)$$ time merging, for some constant $$c$$. Here, “creation” takes as arguments the range of the element domain $$[1..n]$$ and an optional single element in this range, and “merging” takes two sets with the same domain and returns a new set representing the union of the two input sets. In Haskell, the type signatures for these operations might look like this:

Seems fairly reasonable, right? I’m going to show that it is likely that no such data structure exists.

## rulesgen: A SCIgen-inspired program for generating random text matching a grammar

rulesgen is a simple Haskell program I wrote that allows you to generate randomized text, similar to SCIgen. You can do all sorts of entertainingly nasty things with it…

Source code and documentation for rulesgen are available on GitHub.

## Making ByteString and Text instances of Foldable… almost

I just noticed you can do this:

And then use it like this:

Notice that those are the polymorphic Foldable functions maximum and mapM_, not Text-specific functions. I don’t know if this has any real-world applications, but it’s kind of neat…

Update: As pointed out by lfairy on Reddit, the FMList type works kind of like this.

## Exact (integer arithmetic only) capsule intersection test

The capsule (also called a “pill”) is one of a few common types of shape used for collision detection in games and other applications. A 3-D capsule is a cylinder capped by hemispheres. The 2-D equivalent, a rectangle capped by semicircles, is technically called a stadium, but they are commonly just called capsules as well.

Capsules are nice because they can form both spherical and elongated shapes in any direction. The animation above shows how Super Smash Bros. Melee uses spherical hitboxes that are “stretched” across frames into capsules to prevent fast-moving attacks from going through opponents without hitting them. (Marvel vs. Capcom 3 uses the same trick.) What really makes capsules useful is that they have a very simple mathematical description: a capsule is the set of all points less than a certain radius from a line segment. This means you can check whether two capsules intersect each other by just finding the shortest distance between the two line segments and checking whether it is less than the sum of the radii.

Calculating the distance between two line segments is a well-known problem. This StackOverflow answer gives the code to do that with floating-point arithmetic. Sometimes, though, approximating the correct answer with floating-point isn’t good enough. What if we want an exact intersection test for capsules using only integer arithmetic?
Continue reading Exact (integer arithmetic only) capsule intersection test

## The shortest proof for every theorem

Suppose we want to show that there is a number $$n$$ such that no upper bound on the busy beaver number $$\Sigma(n)$$ is provable from, say, the axioms of ZFC. One possible proof is as follows: Assume that no such $$n$$ exists. That is, assume that for every $$n$$, there is a proof in first-order logic that uses only the axioms of ZFC and derives a sentence $$\Sigma(n) \leq m$$ for some $$m$$. Then we could compute an upper bound for $$\Sigma(n)$$ by exhaustively searching all of the possible valid ZFC proofs until we found one that deduced a theorem of the form $$\Sigma(n) \leq m$$; by assumption, we must eventually find such a proof. But we know that we cannot compute an upper bound on $$\Sigma(n)$$ for arbitrary $$n$$; thus, we have derived a contradiction, and the original assumption must be false.

Enumerating proofs until you find one with the desired properties is one of those grand CS traditions that, like calling an $$O(n^{12})$$ algorithm “efficient” while dismissing an $$O(1.001^n)$$ algorithm as “intractable”, is handy for theoretical purposes but has essentially no bearing on the real world whatsoever. After all, no one would really write a program that loops through all possible proofs and tests each one.