Comments on: Integral Calculus in Haskell

By: solrize

solrize — Fri, 10 Apr 2009 06:28:13 +0000

You might like John Hughes’ famous article “Why Functional Programming Matters”, which goes over a few examples like this. It was written in the 1980’s and uses Miranda, an older language that Haskell is descended from, that should be easy to understand. You should be able to find it online easily.

By: Leon Smith

Leon Smith — Fri, 10 Apr 2009 04:04:41 +0000

@Joe Fredette: nothing symbolic here: it’s a purely numerical technique. It could be improved a bit by using the trapezoidal or Simpson’s Rule. I second the AD suggestion, obviously.

@Jake McArthur and jberryman: very erudite comments. One big thing about learning Haskell well is learning when there will be thunks versus when concrete values will be produced.

Basically, common situations where evaluation will be forced, avoiding the creation of thunks, is on conditional branches, pattern matching, and uses of “seq” and friends.

By: Leon Smith

Leon Smith — Fri, 10 Apr 2009 03:51:15 +0000

Nicely done. Part of me was hoping for something a little bit more: you should take the time and effort to learn about Automatic Differentiation.

You are spot-on when you say that it’s important to understand how your compiler works. I must admit, Haskell is a challenging one in this regard, but I have a reasonably good understanding at this point, although my understanding of GHC pales in comparison to certain other compilers for other languages. Keep at it!

By: Jake McArthur

Jake McArthur — Fri, 10 Apr 2009 03:32:28 +0000

Your sum parameter accumulates thunks because you don’t need it until the end. That is, for each recursive call, it might grow something like this:

0
0+(f 0)*0.0001
0+(f 0)*0.0001+(f 0.0001)*0.0001
0+(f 0)*0.0001+(f 0.0001)*0.0001+(f 0.0002)*0.0001
0+(f 0)*0.0001+(f 0.0001)*0.0001+(f 0.0002)*0.0001+(f 0.0003)*0.0001
0+(f 0)*0.0001+(f 0.0001)*0.0001+(f 0.0002)*0.0001+(f 0.0003)*0.0001+(f 0.0004)*0.0001

and so on. This is what overflows your stack. (Notice the similarities to a function that is not tail recursive!)

There are ways to avoid this problem, but since GHC’s strictness analyzer can tell what’s going on anyway it’s easiest to just use optimizations.

By: jberryman

jberryman — Fri, 10 Apr 2009 00:46:40 +0000

@Elben Shira: what Jake M means is that the compiler only evaluates the ‘x’ and ‘b’ parameters with each iteration because it has to in order to perform the comparison and continue the computation. The other parameters aren’t evaluated at all until the very end because you haven’t needed to evaluate them! So they exist as ‘thunks’ (a computation that has yet to be evaluated). Look at seq to add strictness.

By: Elben Shira

Elben Shira — Fri, 10 Apr 2009 00:08:42 +0000

@Jake McArthur: you are right, my ignorance is the problem, not GHC, but I’m not sure what you mean by “the other parameters are not forced until the end.” Can you provide an example?

By: Justin Grant

Justin Grant — Thu, 09 Apr 2009 23:22:48 +0000

Your stack overflows are probably due to the code exceeding the limits in the Double type.

You may want to look at this in Lisp too. Here’s the equivalent code in Lisp –> http://jng.imagine27.com/articles/2009-04-09-161839_integral%20calculus_in_lisp.html

Lisp itself is really just a calculus too(lambda calculus) implemented as a programming language that has the same syntax. This lends well to many types of math coding. There is little to translate.

By: Jake McArthur

Jake McArthur — Thu, 09 Apr 2009 22:14:55 +0000

“Thinking about and writing programs recursively may be more elegant and easier to understand, but then we are putting our trust on the compiler for optimizations, which is scary if we don’t understand how the compiler works.”

This is a common misconception for newbies to the language. In reality, we aren’t really putting any trust in the compiler to perform certain optimizations. It’s just a matter of understanding Haskell’s evaluation model.

In this case, you believed that making a function tail recursive should prevent stack overflows, but you didn’t realize that laziness can play a factor here. The guards in your integrateGen function only force two parameters to evaluate. The other parameters are not forced until the very end. Without realizing, you have defeated the purpose of tail recursion by creating a long chain of unevaluated thunks instead of accumulating a result as you go, a stack overflow.

The reason that optimizations fixed this is because GHC’s strictness analyzer figured out that the result will always be evaluted at the end anyway, so it causes the binary to go ahead and evaluate it earlier.

By: Joe Fredette (jfredett)

Joe Fredette (jfredett) — Thu, 09 Apr 2009 21:57:17 +0000

Nifty, you might try using Haskell’s Algebraic datatypes to do some kind of symbolic integration, since if you could lift basic math operations into some kind of datatype, then integration symbolically ought to become a series of pattern matches which break down an equation and apply basic rules.

You might also be interested in Conal Elliot’s Automatic Differentiation stuff, it’s on his blog, some others have done Computer-Algebra type stuff.

Very neat!