Today I’ve invented DRC Theorem™.

1. Dog
2. Rain (and therefore mud, at least in Lubbock)
3. Clean Carpet

Pick two. You can’t have all three at the same time.

— Using Prototype Property in JavaScript

As an example of over-engineering, imagine a civil engineer, who needing to build a bridge, builds a bridge-building machine, and then being unsatisfied that the bridge-building machine can only build one type of bridge, then sets out to build a bridge-building machine generator (i.e. a machine that produces bridge-building machines).

I did that recently; not the bridge builder, but the software equivalent.

I’ve been working on a user interface prototype for my stock screening application. Since it’s a web-app, the UI (i.e. user interface) code is all in JavaScript. JavaScript doesn’t have a traditional class system like other object-oriented languages, so I set out to build one.

I built one that was built upon another JavaScript library called ExtJS. The system worked, but I wasn’t satisfied because my class system wasn’t as simple to use as the class system that John Resig recently released. So, I’ve been thinking and experimenting with different ways of building class systems, because I don’t want just any old class system, I want the easiest, fastest, smallest, best JavaScript class system.

What I came up with is hideously complex and it took me hours to code and debug.

Fast-forward to yesterday. Google released a javascript library that looks very nice, is simple to use, is very well documented, and is proven (on properties such as gmail.com, Google Calendar, and other google apps). So I  think I’m going to scrap the complex class system and instead go back to something more JavaScript-esque, and simple to use, and use it along with Google’s javascript library.

Hopefully I can keep from over-engineering this thing again. I’m going for simplicity and minimalism this time.

It turns out that my master’s thesis is going to be a comparison of stock trading strategy simulator implementations—one written in C++, and one written in SequenceL.

(defn gcd [a b]
  (if (= b 0)
    a
    (recur b (rem a b))))

(defn totient [n]
  (if (<= n 1)
    1
    (loop [i (- n 1) a 0]
      (if (> i 0)
        (recur (- i 1) (+ a (if (= (gcd n i) 1) 1 0)))
        a))))

Jeremy is right! High-fructose corn syrup really is causing political unrest in America, world instability, the global financial crisis, turmoil in the middle east, conflict among Jupiter’s moons, and near-certain destruction of earth (and Jupiter).

… Sorry, I got a bit carried away.

That washintonpost.com article is a republication of this article at healthday.com.

The article cites this study:
Mercury from chlor-alkali plants: measured concentrations in food product sugar

I didn’t know what a Lychrel number was until I read the explanation. Here it is:

If we take 47, reverse and add, 47 + 74 = 121, which is palindromic.

Not all numbers produce palindromes so quickly. For example,

349 + 943 = 1292,
1292 + 2921 = 4213
4213 + 3124 = 7337

That is, 349 took three iterations to arrive at a palindrome.

Although no one has proved it yet, it is thought that some numbers, like 196, never produce a palindrome. A number that never forms a palindrome through the reverse and add process is called a Lychrel number. Due to the theoretical nature of these numbers, and for the purpose of this problem, we shall assume that a number is Lychrel until proven otherwise. In addition you are given that for every number below ten-thousand, it will either (i) become a palindrome in less than fifty iterations, or, (ii) no one, with all the computing power that exists, has managed so far to map it to a palindrome. In fact, 10677 is the first number to be shown to require over fifty iterations before producing a palindrome: 4668731596684224866951378664 (53 iterations, 28-digits).

Surprisingly, there are palindromic numbers that are themselves Lychrel numbers; the first example is 4994.

How many Lychrel numbers are there below ten-thousand?

At first I made the mistake of thinking that a number was Lychrel if it does produce a palindromic number within 50 iterations. Then I realized my mistake: a number is Lychrel if it doesn’t produce a palindromic number within 50 iterations.

Here is what I came up with in Clojure to determine the number of Lychrel numbers less than 10,000:

(import '(java.math BigInteger))

(defn reverse-str [s]
  (apply str (reverse s)))

(defn reverse-int [n]
  (BigInteger. (reverse-str (str n))))

(defn add-reverse [n]
  (+ n (reverse-int n)))

(defn lychrel? [n iterations]
  (if (< iterations 1)
    true
    (let [i (add-reverse n)
          s (str i)]
      (if (= (reverse-str s) s)
        false
        (recur i (- iterations 1))))))

(println (count (filter #(lychrel? % 49) (range 10000))))

Problem 97 is to “Find the last ten digits of the non-Mersenne prime:
28433 × 2^7830457 + 1.”

My solution in clojure ran in 82165.759 milliseconds, which Google says is 1.36 minutes.

Here’s my implementation:

(require ‘math)
(time (rem (+ (* 28433 (expt 2 7830457)) 1) 10000000000))

My solution uses an external clojure library that implements the function expt (i.e. exponentiation). That library is posted for download here.

(defn list-primes
  ([n] (list-primes n [2] 3))
  ([n primes i]
    (if (>= (count primes) n)
      primes
      (if (not-any? #(= (rem i %) 0) primes)
        (recur n (conj primes i) (+ i 2))
        (recur n primes (+ i 2))))))
(println (nth (list-primes 10001) 10000))