Solving the harder problem.

I've not been writing much for the Internet recently. One of the things I've been doing instead is trying to improve my rather meager programming abilities. Since I have a giant Java reference book in my possession and all the necessary stuff already on my computer, Java has so far been my language of choice. If anyone has any suggestions on what might be a better language to learn, I'm open to them.

I've been using Project Euler as practice. Project Euler is a list of math/programming problems. Most of them would be either extremely difficult or exceedingly time-consuming to solve by hand, whereas an efficient algorithm can solve each problem rather quickly. At least for the early problems, the good solutions take less than a second to finish.

When you solve a problem, the website gives you access to a forum where you can see how other people solved problems. Some of the top solvers use a language called J which looks really, really cryptic, even for simple operations. For example: “c=:%:@:(+/)@:*:” creates a formula for the Pythagorean Theorem. Many of the statements just look like someone going to town on the top row of the keyboard. But it's a really powerful little language, and I've been trying to get the hang of it for the past three or four days.

Well, Project Euler's Problem 29 gave me some trouble because I misread it. The question is “How many distinct terms are in the sequence generated by a^b for 2 a 100 and 2 b 100?” See where it bounds a and b at 100? Well, I accidentally did the problem for 2 ≤ a , b ≤ 1000. Doing the problem for 1000 created a whole bunch of rounding errors, because, say 999^1000 is a pretty gigantic number. So I got around this by taking logarithms on one axis, which at the time seemed like a mildly creative way of getting around the problem, though in hindsight it’s the obvious thing to do. I found a second way of checking the answer which also worked nicely. And then I return to the webpage to enter the solution, and find that my bounds were way too high. The real problem was smaller, and when I ran my first line of J code it turns out that I didn't hit any rounding errors after all.

Oh well. The nice thing about math is that when you solve the harder problem, you usually learn enough that it doesn't even feel like a waste of time.