So far, I’ve solved problems 1-10, 14, 47, and 243. Problem 9 doesn’t really count as I basically borrowed the code verbatim from another site, and problem 5 almost doesn’t as I solved it with pencil and paper.

I may cover a few of the others later, but for now I’ll focus on 14.

Problem 14 was a bit trickier than it looked. I knew from the start that I’d have to resort to some sort of memoization to get runtime down to a reasonable level. As noted on the Project Euler site:

Each problem has been designed according to a “one-minute rule”, which means that although it may take several hours to design a successful algorithm with more difficult problems, an efficient implementation will allow a solution to be obtained on a modestly powered computer in less than one minute.

A brute-force solution without memoization took way too long on the virtual machine I use to run Visual Studio 2010. (I don’t know how long, because I killed it after about ten minutes.) So, I borrowed some code from Programming F# (page 199):

open System.Collections.Generic

let memoize (f : 'a -> 'b) =
    let dict = new Dictionary<'a, 'b>()

    let memoizedFunc (input : 'a) =
        match dict.TryGetValue(input) with
        | true, x -> x
        | false, _ ->
            let answer = f input
            dict.Add(input, answer)
            answer

    memoizedFunc

The project statement uses a starting point of 13, and gives a sequence length of 10; I realized that if the sequence ever reached 13, for instance, it would always be at 1 ten iterations later. My first attempt at a solution copied around the actual sequence of numbers for each starting point. Ideally, if I always tacked the new number on as the head, the tail would eventually be a list that had already been generated, and wouldn’t need to be recreated or even copied, as the new list could just point to the old one.

While this wasn’t a horrible idea, it seemed a lot slower than I’d like. So, I switched to a simple tally of sequence length. Still slow.

After I let the program run all the way through, I realized my problem: the debugging output. What started as a ten-minute process shortened itself to about ten seconds when I removed the printfn from the inner function. I probably could have kept the sequence after all.

let rec collatz =
    // The only reason to create an inner function here
    // is to memoize it. You have to call the outer
    // function recursively or the memoize function
    // won't catch it.
    let collatz_ (x : int64) =
        if x = 1L then 0
        elif x % 2L = 0L then
            1 + collatz (x / 2L)
        else
            1 + collatz (3L * x + 1L)

    memoize collatz_

// Candidates
[ 1L..999999L ]
    // Calculate path length for each, decorate
    |> List.map (fun x -> (collatz x, x))
    // Sort by path length...
    |> List.sortBy fst
    // ... long paths first
    |> List.rev
    // Give me just the longest path
    |> List.head
    // Give me just the starting point
    |> snd;;

PS: if you’re asking why it’s called “collatz”?

So, what did I learn?

I learned that console output is slow. I also learned that decorating an input list with tuples (a la the “Schwartzian Transform”) is a useful technique in F#. Function pipelining is incredibly handy. And I’m addicted to Project Euler.

I thought, “Even as a beginner, I can do better than that.” Here’s my first attempt:

let rec primes_match n =
    match n with
        | nn when nn <= 1 -> []
        | nn when nn > 1 ->
            let so_far = primes_match (n - 1)
            if (so_far |> List.filter (fun d -> nn % d = 0) |> List.isEmpty)
            then nn :: so_far
            else so_far

let primes n = n |> primes_match |> List.rev

Then I realized ‘match’ was a bit heavy for what I’m doing, and shifted to if/then/else:

let rec primes_match n =
    if n <= 1 then []
    else
        let so_far = primes_match (n - 1)
        if (so_far |> List.filter (fun d -> n % d = 0) |> List.isEmpty)
        then n :: so_far
        else so_far

let primes n = n |> primes_match |> List.rev

And finally, I learned about List.exists.

let rec primes_match n =
    if n <= 1 then []
    else
        let so_far = primes_match (n - 1)
        if (so_far |> List.exists (fun d -> n % d = 0))
        then n :: so_far
        else so_far

let primes n = n |> primes_match |> List.rev

I was proud, but not satisfied. There are still two major problems with this code. First, it’s still not the sieve of Eratosthenes. It’s just a more-time-efficient version (I think, maybe) of the original algorithm. Second, it’s not tail-recursive, and stack depth grows with the input parameter, so it can only generate primes up to 32,750 or so.

So, I started from scratch. I managed to create a new sieve function that is, in fact, the sieve of Eratosthenes, and tail-recursive. As it turns out, Chris Smith has a sieve implementation as well, but I didn’t look at it before writing my own. Mine came out shorter, but probably less efficient.

let rec sieve_drain (sifted : int list) (unsifted : int list) =
    if List.isEmpty unsifted then sifted
    elif (sifted |> List.exists (fun d -> (List.head unsifted) % d = 0))
    then sieve_drain sifted (List.tail unsifted)
    else sieve_drain ((List.head unsifted) :: sifted) (List.tail unsifted)

let sieve n =
    sieve_drain [] (2::[3..2..n]) |> List.rev

Any suggestions? Am I being too strict when it comes to functional style? Is there any way I can polish this?

Update:

I managed to find a cleaner way to do this:

let rec sieve_drain (sifted : int list) (unsifted : int list) =
    match unsifted with
    | [] -> sifted
    | x :: xs ->
        if not (sifted |> List.exists (fun d -> x % d = 0))
        then sieve_drain (x::sifted) xs
        else sieve_drain sifted xs

let sieve n =
    if n < 2 then [] else sieve_drain [] (2::[3..2..n]) |> List.rev

But it’s not very efficient. Chris Smith’s implementation (due to the use of shared state) takes about 2.5 seconds to run from 1 to 500,000. Mine takes about 55.

Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot. [Eric S. Raymond]

I, for one, know that I’m only partially enlightened.

When I was taking “Programming Languages” (COP 4020), one of the languages covered, intended to represent the entirety of functional programming, was Common Lisp. We studied it for about two weeks. On the exam, a 5-point question asked us to write a function to determine whether a list was palindromic. I set off writing tons of code (on paper, even), checking for the equality of the first and last elements, then stripping them off and recursing on the rest.

As I handed in my exam, I commented on the difficulty of that question compared to the low point value. The professor looked at my test, then at me, and then she wrote on a scrap of paper so that the other students couldn’t see (yet):

(defun is-a-palindrome (lst) (equal lst (reverse lst)))

That’s thinking functionally. I could hammer out the code, but I was writing C with a bunch of parentheses. I wasn’t really writing in Lisp.

When I started working here, I was writing a lot of Python. Python isn’t generally considered a functional language, but it has enough of the features (first class functions, lists, map/filter/reduce, etc) to give me a taste of power. Then I was forced into using VB.NET 2005, which felt like stepping back in time a decade. It had none of the Pythony goodness I was used to: no list comprehensions, no map/filter/reduce (with clunky forms added in VB 2008), and no lambda statements (halfassedly added in 2008 and properly added, supposedly, in 2010).

What skill I picked up from Python quickly began to fade.

My outlook was bleak, as well. I thought the .NET platform was headed for the same old languages and the same old paradigms, for the same old Blub coders. I was afraid that I’d end up a Blub coder… or worse, that I already was one.

Then I saw some of the nice features of C# in .NET 3.5 (and immediately started griping that VB didn’t have them), and what’s more, I found F#.

Let me say this up front: I like Lisp. Most of it makes very little sense to me, but I can feel the power behind it. Though I’ve wanted to learn a functional language for a while now, I know that my chances of ever getting a job writing it are slim, so I’ve focused on the standard OO and procedural languages. F# has the advantage of being backed by Microsoft; Visual Studio 2010 will have F# out of the box, and it’ll be right there on the desks of almost every .NET programmer, overcoming much of the inertia that leads people to use languages like VB.

So that’s why I’ve decided to throw myself into F#; it’s a paradigm I want to embrace, and a language that I may actually get paid to use someday. That’s worth reshaping my mind for.

And at the very least, I’ll end up writing better code in other languages.