There's a monthly math puzzle at http://researchweb.watson.ibm.com/ponder/ Many of them are quite good. But I found this month's puzzle rather lame. I treated it as a speed programming challenge. It took me 17 minutes to solve it and email them the solution. One can replace the letters in the expression I/M = B/A+C/K with different digits from 1 to 6 to form a valid equation. For example: 5/6 = 2/4+1/3. Substituting back letters to digits, using the same solution ACK.IBM is 413.526. The problem: Replace the letters with different digits such that D/O+N/T = P/E+R/I+S/H and send us PONDER.THIS translated back to a number. This is unsatisfying for three reasons. For one thing, there are multiple valid solutions. Hundreds of them. For another, each letter only occurs once. They might as well have just had ten blanks and said to use each digit once and only once. Finally, rearranging the digits at the end, and sticking a decimal point in, is gratuitous. (I'm also annoyed that they put it online several days early, so I wasn't the first to solve it. They list solvers in order of when they submitted their solutions.) A decent cryptarithm or alphametic has a unique solution and duplicate digits. A classic is SEND + MORE = MONEY. That one dates to before the computer age; you're supposed to use cleverness instead of raw CPU power. (The first step is to realize that when a sum of two numbers is longer than either summand, the leftmost digit must be 1. Hence so is the other M, which then constrains the S, etc.) I decided to come up with a problem along the same lines as theirs, but more elegant, to submit to them for use during a future month. I'd start with PONDER=THIS, and find operations I can stick in such that it will have a unique solution. One example I quickly found was P*ON*DER=T*HIS. Or, if you prefer (as I do), _*__*___=_*___. Then I figured, anything they can do, I can do meta. So I decided to submit, not that problem, but the problem of finding such a problem. Unfortunately, that suffers from the same flaw. With multiplication as the sole operation, there are 12 solutions, of which the above is just one. They all use the same 5 numbers (two single-digit, one two-digit, and two three-digit) in different arrangements. This happens because multiplication is commutative. Actually, that's two operations, since concatenation (gluing two or more digits together to create a multi-digit number) counts. I'm currently looping over all combinations of addition, subtraction multiplication, division, concatenation, and decimal point. An example of this is _*___*_+_=_/_._-_ which unfortunately has multiple solutions. 0*367*8+4=9/1.5-2 is one of the solutions. The precedence is concatenation (including the decimal point) first, then multiplication and division together left to right, then addition and subtraction together left to right. So 3-2+1 means 2, not 0, and 8/4/2 means 1, not 4. I believe this is standard. Looping through operations is more challenging than looping through numbers. I had to write my own parser. To keep it fast and simple, I always alternate between digit and operations. No parentheses, no prefix plus or minus, and I use a character for concatenation rather than just having the digits next to each other. (The comma is suppressed during printing, of course.) The parser rejects invalid arrangements such as division by zero, a multi-digit number with a leading zero not followed by a decimal point, and a number with more than one decimal point. Amusingly, the ASCII characters * + , - . / are consecutive. So if I use the comma for concatenation, I can just loop over the numeric values of those ASCII characters, 42 through 47. I'm not using floating point. I keep track of numerators and denominators. And when determining whether the resulting two fractions are equal, I don't bother with common denominators, I simply multiply the first one's numerator by the second one's denominator and compare that with the product of the second one's numerator and the first one's denominator. If those products are equal, the fractions are equal. Neither do I ever reduce fractions (so 1.2*3.4*5/6 is stored as 2040/600, not 17/5). Why waste the CPU time? The numbers never get big enough to get an overflow error on a 32-bit machine. That's an interesting problem itself: What's the largest numbers I can get in my fractions? Or when cross-multiplying the final two fractions to see if they're equal? What if my equal sign was elsewhere in the equation, e.g. __=________? (Actually, even if I got an overflow error in the final step, does it really hurt anything if it's the *same* overflow error for both cross-multiplies? No, I don't plan to program that riskily, but it's a thought.) I'm not doing exponentiation, and not because the usual exponential symbol, ^, is elsewhere in the ASCII code. Trying to figure out how to represent the value of something like 4^5^6^7^8^9 gives me a (metaphorical) headache. Especially since with exponentiation, precedence is right to left, so that would be a rather large number. Also, if I put in exponentiation, then by symmetry I ought to also put in its opposite. But unlike addition and multiplication it has two opposites, roots and logs. And both of them would require me to deal with irrational numbers. My hope is that I'll find some set of operations that has a single solution. Something like, "Arrange ten blank spaces, an equal sign, three multiplication signs, two decimal points, a plus sign, and a minus sign such that there's only one way to fill in the blanks with unique digits to make the equation correct." The downside is that this will take about a month to run. And that's just for the six-four (______=____) arrangement. If the equal sign can go anywhere (except on the ends, of course), it's more like half a year. Has this already been done? In conclusion, their problem wasn't so lame after all, since it inspired the above. (Unless you consider the above to be lame.)