Thanks to corroboration from Jud McCranie, Klaus Brockhaus, and my own new code, and partial corroboration from Edwin Clark, I'm satisfied I had the right answers (though occasionally the wrong question, due to confusion between f(n) mod 21.6 and f(n)/21.6 mod 1 . Oh, and occasionally dividing 21.6 by 2 and getting 10.3 instead of 10.8, in case you were wondering. It's amazing any of my code works the way I'm dropping bits. I'm still working on the faster version of the code. The idea is to code the "lookahead numbers" from u(n)+1 to 2u(n) in order as k when k is not representable as u(i)+u(j) and [m,n] when all numbers m <= k <= n are representable as u(i)+u(j) in just one way. The numbers representable in two or more ways are not mentioned. This is based on the observation that about 1/3 of the lookahead numbers are in the first case, and 2/3 in the third case. Almost all of the first case are singletons, while the run length in the second case averages about 2. The second case accounts for a vanishing fraction of the numbers, but they appear in larger and larger runs. For instance, at u(53584)=724384, the 724384 lookahead numbers are representable in 0 ways, 1 way, more than 1 way 246539 4059 473786 times, in 245835 266 249533 runs. Dan