There were four problems this time, with less variation in difficulty than usual. I solved the first problem, Airport Walkways, completely and got partial credit for my correct-but-inefficient solutions to two other problems. Of course, I figured out how to make my solutions efficient shortly after the contest ended. I didn’t get to the fourth problem, A. I. War, but it looks more straightforward than I expected from a title alluding to artificial intelligence. Maybe I could have solved that one completely instead of one of the partial solutions.

The third problem, Expensive Dinner, involved finding the difference between the best and worst case for a particular problem involving least common multiples. I set about computing both cases separately and taking the difference. I thought I was doing well to reduce the naive O(n²) solution to O(n), but when n is 10¹², that’s not good enough (for full credit). I reduced the best case to be the number of primes less than or equal to n, aka π(n), and the worst case to be the number of primes powers less than n. That seemed like a dead-end, though, since it’s not so easy to calculate π(10¹²). What I didn’t see in time is that since I was going to be taking the difference of the two and they both included π(n), I didn’t have to compute that part at all. And counting the higher prime powers is much easier, and that’s all I really needed to do. Oh well.

The second problem, Spinning Blade, didn’t involve any fancy math, but required a clever data structure to reduce it from O(n⁴) to O(n²) or so. (n was limited to 500, so O(n²) is fine.) I didn’t find it in time, though, and went with my brute force solution for the partial credit.

There were three problems, each with a small and large challenge test cases. The first problem was relatively easy, and basically boiled down to computing greatest common denominators to reduce fractions. I used a fraction class I had from Project Euler work, which made things even simpler. That got me 20 points in under 20 minutes, which turns out was already good enough to place around #640 in the final scores. Time is used for tie-breaking, and there were about 1500 partipants with 20 points.

The second problem was worth 30 points but had a very long description, so I skipped it. It looked interesting reading it later, but I wasn’t confident about boiling down all that prose correctly under time pressure. The problem was basically to find the hardest word(s) for someone to guess in hangman, given the guesser’s letter-picking order.

The third problem was the hardest and worth 50 points. You had to basically find the maximum score for a solitaire card game, given the order of cards in the deck. I thought it would be a simple dynamic programming solution, but the parameterization I chose was obviously not optimal. I included the current cards in the hand as part of the state, but with up to 80 cards in play, there could be a disastrous 2⁸⁰ possible states. After several tries, I was able to add enough tree-pruning to my code to solve the small test cases and get 15 points, but I never solved the large test case which included more pathological card sequences, defeating my pruning logic.

As a consolation prize, my code did trigger an internal JVM error at one point:

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create name string at ../../../src/share/instrument/JPLISAgent.c line: 769

Update: Turns out my parameterization was OK, but I had bugs in the pruning logic.

The first two problems were easy — basically just seeing if you could carefully convert the prose instructions into code. The third problem required a little bit of math insight to reduce the simplistic O(2ⁿ) solution to O(n). I got those three done, but it still took a few hours, which would not be good enough for future rounds where time is more constrained.

The fourth problem, GoroSort, was pretty fun but required a little more thinking than I could put together. Basically, the problem is to sort a list of the first n integers by randomly permuting a subset of your choice. Because of the randomness, the answer is the expected number of permute operations to six decimal places. Fortunately, the problem statement included an example that suggested cycles should be sorted separately. I worked on a recursive solution to iterate through the possible cycle combinations (equivalent to integer partitions) resulting from a random permutation while weighting each one by its probability, but I didn’t get a successful submission.

Turns out my logic was good, but my probability formula was bad (which I should have realized since the total for all partitions was greater than 1). The next day I posed the question to the Mathematics StackExchange site and got a quick answer, which at least let me verify my logic (and learn more about combinatorial counting).

To find out, I ran some tests on some variations on three basic, low-overhead methods: Trial Division, Fermat’s method, and Pollard’s Rho method. All of these take a long time if the number being factored is actually prime, so it’s worthwhile to add in a fourth component which is a Miller-Rabin primality check. Here are my timing results for 400,000 random 64-bit integers. Actually, only the first test uses 400,000 numbers since I limited each test to 1 hour and extrapolated beyond that.

I was really surprised at how well the Rho method worked in practice. It’s a probabilistic method that’s basically like trial division except it chooses numbers at random instead of sequentially. However, the “random” generator uses a polynomial such that lots of the values can be tested at once using some fancy number theory.

Fermat’s Method works best when there are two divisors near √n, which apparently doesn’t happen very often. Here is my Rho code, which is adapted from some pseudocode in a gamedev forum thread.

[sourcecode language='java'] long rhoFactor(long n, int c, int max) {
int check = 10;
long x1 = 2;
long x2 = 4 + c;
long range = 1;
long product = 1;
int terms = 0;

for (int i = 0; i < max; i++) {
for (int j = 0; j < range; j++) {
x2 = (squareMod(x2, n) + c) % n;
long next = multiplyMod(product, Math.abs(x1 - x2), n);
if (next == 0) {
return Math.max(gcd(product, n), gcd(Math.abs(x1 - x2), n));
}
else if (++terms == check || j == range - 1) {
long g = gcd(next, n);
if (g > 1)
return g;
product = 1;
terms = 0;
}
else
product = next;
}

x1 = x2;
range *= 2;
for (int j = 0; j < range; j++) {
x2 = (squareMod(x2, n) + c) % n;
}
}
return 1;
}
[/sourcecode]

For the parameters, I used small odd numbers for c, the polynomial constant term, and 16 – 20 for max which limits the generated values at around 2^max. If the factorization fails, I increase c by 2 and try again. For max = 16, it failed to find a factor about once for every 10,000 numbers and never failed twice in my tests. And those numbers had already had any small factors (less than about 50,000) removed with trial division.

The only app I use that’s really built for that kind of thing is Xcode, which will spawn off separate compiler threads in parallel. However, I wasn’t seeing more the two cores busy when compiling a large project, though Xcode claimed to be working on 8 files at a time. I was thinking that disk or memory constraints were the problem, but it turned out to be a configuration issue.

At some point in the past, I had innocently turned on the Distributed Builds option, which is meant for distributing tasks to other machines on a local network. However, a side effect is that the compiling is throttled, presumably with thread priorities, so the build is more of a background activity. Turning off Distributed Builds gets all 8 local cores working in parallel.

Now I just need to get my own programs to use those cores…

Many of my comments have been resolved recently in a relative flurry of activity. (The comment archive shows more activity last month than any previous three month period.) When a comment is resolved, the original poster can (silently) accept the resolution or appeal to the W3C director. I disagreed with the resolution of my comment on type tables and substitution groups, but just registered my dissent and closed it anyway rather than appeal — I trust the working group’s expertise over my casual interest.

Substitution groups have always been questionable in my mind. I’d prefer typed wildcards or, at least, an opt-in mechanism rather than opt-out for substitution groups to limit their unintended use.

Type tables is a big feature added late in the game and doesn’t seem to interact well with substitution groups. Type tables allow alternative types to apply to an element based on its context, such as an attribute value. I thought such context-based constraints should be in a separate layer, as is done with Schematron, but it seems like half the schema-dev questions are about how to impose such constraints within XML Schema, so I can understand why the Working Group would want to add it.

The problem, as I see it, is that type alternatives live as element declaration properties rather than within the type hierarchy. Substitution group members must have types in proper derivation relationships, but that only applies to the declared types, not the alternatives types. So combining type tables with substitution groups can break the spirit of the derivation hierarchy, if not the letter of it.

(Though not a big table, I’m using it to test out support for HTML 4 (ca. 1999) table elements like THEAD.)