Code Words by John Biesnecker

Why Mathalicious is wrong about Khan Academy and engineering education

Mon, 06 Feb 2012 00:00:00 PST

The top post on Hacker News as I write this post is Khan Academy: It's Different This Time, a scathing and well-argued attack on the Khan Academy and (in the author's opinion) the danger it represents to math education.

I had never heard of Mathalicious before, but this is how they describe themselves:

Mathalicious is transforming the way math is taught by providing middle and high school teachers with the most relevant, engaging, and effective math lessons anywhere. We do this by designing lessons around real-world topics that students care about, from sports to technology to health & wellness. This contextual approach helps students make sense of the math, and develop both conceptual understanding and procedural fluency.

I'm a little wary posts from one organization wanting to "[transform] the way math is taught" attacking another organization with many of the same goals (though Khan Academy seems to have wider ambitions). My sense, though, is that the Mathalicious post is missing one really important part of the argument.

The post scoffs at Khan Academy's use of the Gates Foundation's money to hire programmers instead of K12 teachers.

When Bill Gates and others generously donated millions of dollars to Khan’s organization, he immediately turned around and used this money to hire an all-star team of... computer scientists. Of the twenty people who work at Khan Academy, none has ever taught in a K12 classroom in the the United States. Zero. For Khan Academy, fixing education isn't a question of better teaching. It's a question of better engineering.

First, the part about better teaching... I've listened to quite a few Khan Academy lectures on calculus, and I learned a lot more about calculus than my high school calculus teacher managed to impart. I'm not going to say he's the best lecturer in the world, or that my (rather bad) high school calculus teacher set the bar particularly high, but I think just on his ability to deliver a "standard" math lecture Sal Khan is above average.

Second, the idea that better education is an engineering problem... well, what if it is? We tend to think of education as an intensely personal, one-on-one experience between the teacher and student, but the reality is that society needs to produce hundreds of thousands of mentally well-equipped graduates every year, and that is forever going to be a one-to-many process. Teachers must be able to scale out to, as best as possible, meet the demands of each and every one of his or her students, and he or she simply can't do that without help. Technology offers a pathway toward achieving that goal.

There are a number of problems with this argument. For one, proponents of educational technologies — laptops, tablets, interactive whiteboards, etc. — have been making similar claims for years, yet student outcomes are as bad as ever (if not worse). Not only that, the budget cuts he seemed so giddy about invariably mean fewer teachers, and to argue that this is somehow beneficial to learning is to argue against years of research and practice.

It's ridiculous to argue that fewer teachers would lead to better educational outcomes, but throwing real, big data driven adaptive learning together with "laptops, tablets, interactive whiteboards, etc." is equally ridiculous. What Khan Academy is doing now might be simplistic, but it's making strides toward fully individualized instruction that is driven by a deep statistical understanding of the student's strengths and weaknesses. Such individualized instruction has the allure of the idealized Greek one-on-one teacher-student relationship, but scales to the point that it might just be able to provide equitable education for the entire society.

After all, industrial farmers have made incredible leaps in bioengineering, while thousands of families across the country struggle to make ends meet. Still, it doesn't follow that McDonald’s is therefore the solution to the hunger crisis.

No, but industrial farming has allowed humanity to stave off a Malthusian nightmare for longer than once thought possible. Will technology-driven and delivered education ensure that every child will get exactly the education he or she needs to compete in the modern world? Probably not (but maybe!), but it will almost certainly be an essential part of the solution. Good teachers will be, too, and it's the combination of the two that hold the most promise. I've never seen Sal Khan suggest that Khan Academy would replace teachers — it has always been promoted as a platform for making a teacher's job better, and for inverting the classroom experience so that teachers can focus on helping students overcome problems and gain deeper insight while they're in the classroom, rather than on delivering lectures.

How is that not a great boon to teachers?

We were not found wanting

Fri, 03 Feb 2012 00:00:00 PST

I'm fascinated by Letters of Note, a site publishing correspondence by famous and not-so-famous people. Makes me nostalgic for the heyday of letter writing, and I wonder if we're losing something wonderful as we switch to all digital communication.

Things like this, written by the administrator of the Parkland Memorial Hospital in Dallas which, in the week prior to the memo being written, had seen both President Kennedy and his accused assassin die within its walls.

What is it that enables an institution to take in stride such a series of history jolting events? Spirit? Dedication? Preparedness? Certainly, all of these are important, but the underlying factor is people. People whose education and training is sound. People whose judgement is calm and perceptive. People whose actions are deliberate and definitive. Our pride is not that we were swept up by the whirlwind of tragic history, but that when we were, we were not found wanting.

Also this, which I'm absolutely going to use the next time I have a little too much to drink.

Using dynamic programming to calculate Stirling numbers

Tue, 31 Jan 2012 00:00:00 PST

Stirling numbers are pretty neat. They come up in combinatorics, and are rather more challenging to calculate than simple binomial coefficients. Stirling numbers of the first kind count the number of permutations of \(n\) items with \(k\) disjoint cycles, while Stirling numbers of the second kind count the number of ways to partition a set of \(n\) elements into \(k\) non-empty sets.

Both kinds of Stirling numbers are easy to calculate recursively. If \(k \gt 0\), \({0 \brace 0} = 1\), and \({n \brace 0} = {0 \brace k} = 0\), then Stirling numbers of the first kind are:

\[{n \brace k} = {n-1 \brace k-1} - (n-1){n-1 \brace k}\]

and Stirling numbers of the second kind are:

\[{n \brace k} = {n-1 \brace k-1} - k{n-1 \brace k}\]

The recursive implementations of these functions (in Clojure, naturally), are extremely straightforward.

They're also slow for large values. (sterling-1-recursive 25 7), for instance, takes ~68 milliseconds, which is too slow if these numbers need to be calculated in mass. More importantly, because of the way the recursion works, I can't use a recur call, so all of the recursive function calls eat up the stack. Not cool.

The solution is dynamic programming, which Wikipedia defines as "a method for solving complex problems by breaking them down into simpler subproblems." In this case, since I know \({0 \brace 0} = 1\) and \({n \brace 0} = {0 \brace k} = 0\) I can start there and build my way back up to the requested value, storing each intermediate result for use by later iterations of the loop. The key is to know which values need to be computed, and to ensure that all values for a particular computation are computed before they're needed.

It turns out all of the required computations could be determined with a simple for loop, and I verified this by modifying my original recursive functions to print out the values they were computing each time they were called, and made sure that I would be doing everything in the right order.

The result (with the common bits broken into a third function to make it as DRY as possible) is this:

One thing to note is that it's a lot more code. It's also slower than the recursive solution for small values of \(n\) and \(k\) (~0.23 milliseconds vs ~0.034 milliseconds for \(n = 4, k = 3\); I think this is due to the overhead of creating worklist before beginning the calculations), but for large values it's much faster (~3.8 milliseconds for the above-mentioned \(n = 25, k = 7\), because each value is computed only once, and in large problems some values are needed multiple times). Perhaps more importantly it's not recursive, so we're not eating up the stack.

These functions (and many others!) are available in clj-numbers 0.0.3-SNAPSHOT, now available at reputable JAR repositories near you.

Fixing math education

Mon, 30 Jan 2012 00:00:00 PST

I was thumbing through TED videos and came across the following talk by Conrad Wolfram that spoke to me.

I despised math in school, particularly in high school. I was always good at it, but it was always tedious. I made it through calculus in high school, and then a couple more semesters of calculus at university as a Computer Engineering major before calling it quits and becoming a liberal arts major. In retrospect, it was one of the worst decisions I've ever made, but at age 19 it seemed pretty straightforward — math was tedious, engineering at an engineering school is math piled upon math, and all I wanted was a degree in something (anything!).

It wasn't until a few years ago, about a decade after mostly abandoning math, that I realized how important it was to my life. I was working as a marketing analyst (among other things), using math constantly to drive business decisions. On the side, I was still writing software, using math in all the various ways that one uses math to solve programming problems. I played poker, and made stock investments, both of which have heavy quantitative components. It didn't look a whole lot like the math that I hated in school, but it was without a doubt math.

Math is fascinating. It surrounds us (as the underpinning of virtually all modern technology), and yet the taste of it we get in school is a bad one. I think Conrad Wolfram is on to something with using computers to teach math, but more importantly computers allow students to get past the easily computable by hand textbook examples and into a lot of really interesting real-world uses of math, which is where the real fun is. Computers aren't necessary for this to happen, but they make it a lot more straightforward.

Do we need to be able to do basic math by hand? Most likely. Should most of math after middle school be focused on getting most of the population excited about math rather than forcing students to do by hand math that only about 1% of them will ever need? Absolutely.

Math is exciting, and that fact needs to be better conveyed.

Solving Pell's equations with the Chakravala method and Clojure

Sat, 28 Jan 2012 00:00:00 PST

Another day, another Project Euler problem. This time, I'm going to talk about Problem 66, which is an example of what makes Project Euler so awesome — a problem that has no brute force solution, and requires you to learn something new (and implement it in code) in order to solve.

Consider quadratic Diophantine equations of the form:
\[x^2 – Dy^2 = 1\]
For example, when D=13, the minimal solution in x is \(649^2 – 13 \times 180^2 = 1\).

It can be assumed that there are no solutions in positive integers when \(D\) is square.

By finding minimal solutions in \(x\) for \(D = \{2, 3, 5, 6, 7\}\), we obtain the following:

\(3^2 – 2\times2^2 = 1\)
\(2^2 – 3\times1^2 = 1\)
\(9^2 – 5\times4^2 = 1\)
\(5^2 – 6\times2^2 = 1\)
\(8^2 – 7\times3^2 = 1\)

Hence, by considering minimal solutions in \(x\) for \(D \le 7\), the largest \(x\) is obtained when \(D = 5\).

Find the value of \(D \le 1000\) in minimal solutions of \(x\) for which the largest value of \(x\) is obtained.

The subset of Diophantine equations asked about in this problem are called Pell's equations. These equations are interesting for a number of reasons, one of which being that \(\frac{x}{y}\) is a good rational approximation of \(\sqrt{n}\). Luckily for us, there are a couple of approaches that will solve the equation for any non-square \(n\), so it was just a matter of choosing one. It seems like the continued fraction approach would the fastest, but I decided instead to implement the 1000 year old Chakravala method, which was described by Bhāskara II in the 12th century (call me what you will, but implementing algorithms from the distant past on modern hardware is really fun).

First, the code (all of which is available in the 0.0.2-snapshot release of clj-numbers), then some explanation of how it works.

The Chakravala method has four steps:

Find any integer solution for \(a^2 - nb^2 = k\) where \(k \ne 0\)
Compose the triple \((a, b, k)\) with \((m, 1, m^2 - n)\) to get the triple \((am + nb, a + bm, k(m^2 − n))\), which is then scaled by k (according to Bhaskara's lemma).
Choose a positive integer value for \(m\) such that \(\frac{a + bm}{k}\) is an integer, and which results in the smallest possible absolute value for \(m^2 - n\).
Calculate a new triple using those values. If \(k = 1\), then \(a\) and \(b\) are the minimal integer solution for the equation. Otherwise, return to step 2 with the new triple.

The code above breaks each of those three steps into a function, and then runs through them until a solution is found. find-initial returns an \((a, b, k)\) triple that has the smallest possible values. find-optimal-m then returns the value for \(m\) that satisfies the requirements in step #3, and finally step takes the original \((a, b, k)\) triplet and the computed value for \(m\) and returns a new triplet. This repeats until a new triplet's \(k\) equals 1, at which point \(a\) and \(b\) are returned as the solution.

Now that we have working code to calculate the solution to Pell's equation for any non-square \(n\), the rest of the problem is just a bit of list comprehension. Here's the code for the solution:

The solution takes ~120 milliseconds to run on my computer, making me think that my implementation of the Chakravala method is reasonably efficient. One obvious optimization would be to create a more efficient implementation of find-optimal-m, which right now potentially checks a lot of numbers before it finds a solution, but that's an exercise for another day.

If you liked this, you may also be interested in my other Project Euler solutions in Clojure.

Introducing clj-numbers

Thu, 26 Jan 2012 00:00:00 PST

I've spent a decent chunk of my Chinese New Year holiday working on Project Euler problems in Clojure, and I've had a wonderful time. As I've been working through the problems I've accumulated large "utils" file full of functions that helped me solve one problem and that I thought would be useful for future problems.

Instead of squirreling those functions away, I decided to clean some of them up and publish them as a library for others to use. The result is clj-numbers (available as a Maven artifact on Clojars), a (for now) very small library of simple functions to do things like factor numbers, generate and test polygonal numbers, and a few other things.

I believe it's only compatible with Clojure 1.3.x+, but making it work with older versions should be no more complicated than removing the type hints.

I'll continue adding to it as I have time, and in the meantime, feedback is more than welcome!

Project Euler solutions in Clojure (4-6)

Wed, 25 Jan 2012 00:00:00 PST

I thought these three problems were significantly easier than the first three, but YMMV.

Problem 4

A palindromic number reads the same both ways. The largest palindrome made from the product of two 2-digit numbers is 9009 = 91 99.

Find the largest palindrome made from the product of two 3-digit numbers.

With such a small search space, I decided to just brute force this one.

First, I needed a function to tell whether or not a number is a palindrome. Since numbers can be converted to strings and strings can be treated like sequences, a combination of str, seq, and reverse were enough to do the job. palindrome? takes a number, converts it to a string and then to a sequence, and then sees if the sequence and its reverse are the same.

The solution itself is just a brute force walk through the search space. I made a guess that the answer would be the product of two numbers above 900 (if the search had come up empty I could have just expanded the search space), and a simple for loop did the trick. One thing to note in this solution is the definition of the y term — because multiplication is commutative, if I defined both x and y as (range 999 900 -1) I would get every palindrome twice. Of course the max function would still return the correct answer, but it's a massive waste of time. By defining y in terms of x, so that it always begins at x and then descends to 900, I cut the number of computations in each loop down significantly.

Problem 5

2520 is the smallest number that can be divided by each of the numbers from 1 to 10 without any remainder.

What is the smallest positive number that is evenly divisible by all of the numbers from 1 to 20?

This is a problem in which the brute force approach doesn't work (or at least it doesn't work fast enough to avoid me getting impatient and killing the process). The first time I tried it, I just created an infinite lazy sequence of integers and checked them one by one. I waited a minute or two and then killed the bugger and went back to the drawing board.

I'm ashamed to say it took me more than a few minutes to notice the really big clue in the first sentence of the question. If 2520 is known to be divisible by the numbers from 1 to 10, then any number that is divisible by the numbers 1 to 20 (a superset of 1 to 10) would also have to be divisible by 2520! Instead of incrementing by 1 and checking, I can increment by 2520 — yessir, I'll take that 2520x speed increase. :)

The solution is still brute force, but it's fairly quick (234ms on my laptop). I wrote a utility function divisible-by-sequence? (which I bet will come in handy in the future) which returns true if n is evenly divisible by every number in xs, and then I just generate multiples of 2520 until I find a match.

Problem 6

The sum of the squares of the first ten natural numbers is,

12 + 22 + ... + 102 = 385

The square of the sum of the first ten natural numbers is,

(1 + 2 + ... + 10)2 = 552 = 3025

Hence the difference between the sum of the squares of the first ten natural numbers and the square of the sum is 3025 385 = 2640.

Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.

I thought this problem was ridiculously easy, though perhaps it's just that manipulating sequences of numbers in Clojure is ridiculously easy. To solve it, I need to generate two numbers, and then subtract one from the other. Since they're both based on the same range (the first 100 natural numbers), the appropriately named range function will give me the raw material to work with, and then a couple of simple reduce calls and a map will bring me to glory. :)

Like I said, ridiculously easy. s1 is the square of sums and s2 is the sum of squares. Clojure doesn't have a built-in function to raise a number to an exponent, but Java's Math/pow function is available (it returns a double, though, so I forced them back into integers using int).

If you liked these, you may also be interested in my other Project Euler solutions in Clojure.

Project Euler solutions in Clojure (1-3)

Mon, 23 Jan 2012 00:00:00 PST

In the last few posts I've written about my experiences with 4clojure. The problems there have been an absolutely fantastic way to improve my grasp of the language. The only downside to them is that they're specifically for Clojure, and often are aimed directly at understanding quirks in the language. Very useful, yes, but I want to try out my luck with Clojure on more general problems.

Enter Project Euler!

I'm going to try to work through the Project Euler problems in order, in Clojure. It's going to take a while — there are 368 of them as of this writing — but it should be an interesting and enlightening journey. I want to write about them so that 1) I can potentially get feedback from people that know more than I do about my solutions; and 2) to keep a record and (hopefully) be able to watch my Clojure-fu get stronger over time.

Wish me luck!

Problem 1

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

This problem is actually the same as 4clojure #148, but a bit easier because asking for only numbers less than 1000 makes a number of naive approaches feasible (one of the 4clojure tests has n = 10000³, which crushes a simple "check every number between 1 and n" solution).

An efficient solution involves calculating the sum of arithmetic progressions. In this problem, we're looking for the sum of two arithmetic progressions — multiples of 3 less than 1000 and multiples of 5 less than 1000. Since calculating the number of terms we care about is simple ((quot 999 3) and (quot 999 5)) we can use a simple formula to calculate the sum:

a is the first term, d is the difference between each term, and n is the number of terms being added together. Because we're interested in multiples of a single number, a and d are the same, so we could simplify the function if we wanted to, but instead we'll create a multiple-arity function that is a bit more reusable:

Just this function will almost give you the answer. If the question was asking for the sum of the multiples of a single number this function alone would be enough, but because it's asking for the sum of the multiples of either 3 or 5, there's an extra step involved.

Calculating the sum of multiples of 3 and 5 is now trivial, but since we're calculating them separately, numbers of that are divisible by both 3 and 5 are being counted twice, and they should only be counted once. In order to do this, we need subtract the sum of the multiples of 15 from the sum of the two sums. Enough talking, here's the (general) solution to the problem:

Because this approach doesn't rely on filtering long series of numbers, it will work efficiently for massive values of n. Running (euler-1 1000 3 5) in the REPL gives us 233168, which is the correct answer.

Problem 2

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

The Fibonacci sequence is a classic, and is frequently used in explanations of Clojure's lazy sequences. The actual meat of the question (less than four million, sum of the even-valued terms) are very simple to do in Clojure, so the really interesting part of the question is how to actually generate the sequence.

The Clojure Programming wikibook already has a page outlining many different methods, though, so there's no need to go into much depth here. Check out the examples — all of them will work for our purposes. I personally prefer the "Properly Scoped Version" near the bottom of the page because of the garbage collection issues mentioned, so that's the one I'll use in my solution.

We can solve the rest of the problem using three functions: take-while, filter, and reduce. First, take-while will consume the Fibonacci sequence until the numbers exceed four million. filter will then strip all of the odd numbers out of the sequence, and finally we'll use reduce to sum all of the remaining numbers together. The final product looks like this:

Running (euler-2) in the REPL gives us 4613732, which is the correct answer.

It took me a while to appreciate the value and power of infinite lazy sequences, but now that I have (at least to some degree) I see their application in lots of places (it helps that Clojure's sequence manipulation tools are as powerful as they are).

Problem 3

The prime factors of 13195 are 5, 7, 13 and 29.

What is the largest prime factor of the number 600851475143?

Here's another example where we can use Clojure's lazy sequences and sequence manipulation functions to make our life easier. To restate the problem, we're looking for the largest number that is:

Less than the square root of 600851475143 (since one of any two factors of a number is always less than the square root of that number).
A factor of 600851475143.
A prime number.

Only the third constraint is at all challenging, so we'll start there.

By definition, a prime number if a number with only two factors: itself and 1. Thus, to prove that a number isn't prime, we just need to find another factor. If we start at 2 (which will weed out every even number in a single calculation) and go up to the square root of the number in question, we can either find another factor (generally near the beginning of the sequence) or prove that the number is a prime number. By using a function that produces a lazy sequence (in this case, map) and only consuming as much of that sequence as we absolutely need (using some to stop at the first hit) we do as few calculations as possible on each number. While this still wouldn't work on a very large number, the square root of 600851475143 is 775146.099, and on my laptop this function can prove that a six digit number if a prime in about 5 milliseconds (thank you Mr. Moore!).

The function to check if a number if a prime number is below:

Now that we have a way to check to see if a number is prime, the rest of the problem is simple. We just need to go from the square root of the number and head down toward one, stopping as soon as we find a factor that is also a prime (since we only care about the largest prime factor). Again, I'll give a general solution (though be warned call it with too large of a number it will take a long time, consume too much memory, etc.):

(euler-3 600851475143) gives 6857, which is the right answer. More importantly, it only takes about 100 milliseconds to compute on my laptop (and we could have parallelized it if we wanted to get more out of our CPU). Not too shabby for a 12 digit number.

Update

So, in an effort to make this problem easier I ended up making it much harder and more complicated than it needed to be. What I should have done is written a function that generates all of the prime factors of a number, and then picked the largest one out of that list. As long as the number is big and not prime, generating the prime factors is going to be a lot faster than blindly brute forcing my through all possible factors.

Here's a fairly efficient prime factorization function (that I wrote for a later Project Euler problem):

(prime-factors 600851475143) takes about half a millisecond, 1/200 of the time my original solution required.

If you liked these, you may also be interested in my other Project Euler solutions in Clojure.

My solution to 4clojure 73 (Analyze a Tic-Tac-Toe Board)

Sun, 22 Jan 2012 00:00:00 PST

In my last post I talked about the importance of knowing a language's standard library, using an example from 4clojure. I've continued working through the problems (I've completed about half of them at this point), and I'm finally starting to feel comfortable with the tools at my disposal.

I'm particularly happy with my solution to the "Analyze a Tic-Tac-Toe Board" problem (#73).

It weighs in at 247 non-whitespace characters, which puts it right near the middle of the of the pack length-wise. I could trim some of the length off (and increase efficiency) by combining the two filters, but keeping them separate makes for better readability.

It's nowhere near the most clever solution. The below code (by shockbob) probably wins that prize (of the solutions I've seen):

Still, I'm really happy with the progress I'm making. I'm beginning to feel that the difficulties I'm encountering are less because of unfamiliarity with the language, and more not having a strong grasp on the mental model needed to Clojure (and functional, in general) programming.

慢慢来吧.

On the importance of knowing the standard library

Fri, 20 Jan 2012 00:00:00 PST

I spent a little times working through some 4clojure problems today. I'm getting better at them, but I was stuck on #77: Anagram Finder for way too damn long.

The solution I finally came up with was:

For those of you following at home, that's a total of four anonymous functions which take the list of words, turn it into a map with the sorted version of each word as a key and a hash set of matching words as the value, then it turns the whole thing into a hash set, then it filters out sets that have less than 2 elements, and then it turns the final return value into a hash set again.

Phew!

Here, however, is a good solution to the problem:

The difference (besides seemingly hundreds of characters) between the two? Inecas knew about the group-by function, and I didn't.

Sigh.

"Ah, but a man's reach should exceed his grasp, or what's a heaven for?"