small_dx = 0.0001

-- integrate a function f from a to b
integrate f a b = integrateGen f a b small_dx 0

-- Generalize the integrate function to take
-- advantage of tail recursion.
-- integrate a function f from x to b
integrateGen f x b dx sum
 | x > b = sum
 | otherwise = integrateGen f (x+dx) b dx (sum + (f x) * dx)

f1 x = 1
f2 x = x**2
f3 x = x * exp (x**2)

-- normal distribution
std = 1
mean = 0
normal x =
  (1/(std*sqrt (2*pi)))*exp(-(x-mean)**2 / (2*std**2))

integrate takes in three parameters, f is a function, and a and b are doubles. If you are familiar with Haskell types, here is the type of integrate:

*Main> :t integrate
integrate :: (Double -> Double) -> Double -> Double -> Double

integrate calls a general version of integrate called integrateGen. integrateGen takes advantage of tail recursion, which allows the compiler to internally convert the recursive function (which would take a lot of stack space) to an iterative function. The dx in integrateGen is the usual calculus , and sum holds what we have calculated so far.

The functions we declared are:


where

Now we are ready to test this baby out. Let’s start with an easy one:

*Main> integrate f1 0 5
5.000000000001686

This is pretty close to the actual answer:

Let’s try a more interesting problem:

*Main> integrate f3 0 1
0.8592768342831555

The true answer is:

Next time, we will use this little program to do some useful statistical calculations.

Optimizations

We generalized integrate to take advantage of tail recursion, but for some reason, the GHC interpreter does not figure this out. As a result, we can get stack overflows when we have large limits. So we are forced to compile it with optimizations turned on. First we need to add a main function:

-- replace with whatever you wanted to integrate
main = print (integrate funct2 0 999)

Then we compile it with optimizations turned on:

$ ghc -O --make filename.hs

This is one thing that bugs me about functional programming. 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. But nevertheless, Haskell is a fun and powerful language, and I can’t wait to do some other cool things with it!

// The outputs given is based on my machine; it may
// be different on yours.

#include <iostream>
using namespace std;

int main() {
  int *p = new int(144);
  cout << *p << endl;   // output: 144

  delete p;
  cout << *p << endl;   // output: 144 (weird?)

  char *z = new char('a');
  cout << *p << endl;   // output: 97 (crazy!)
  // note: 97 is the numerical representation of 'a'.

  delete z;
  return 0;
}

This example reveals how a pointer works internally. After line 11, we have no guarantee about what data p points to, so we should not use p ever again. But because we are evil programmers, we output *p on line 12 and line 15 and get unexpected but entertaining results. Why is 144 the output of line 12 even though p was deleted? And what is up with the output of line 15?

The keyword delete takes, as an argument, a pointer. In reality, delete doesn’t actually delete anything. Instead, delete lets the operating system know that the memory blocks (on the heap) the pointer is pointing to are now up for grabs. That is, new data can replace the “deleted” data. But we do not add any new data onto the heap before line 12, so the value 144 is never replaced. This is why line 12 still outputs 144.

Line 14 creates a new character ‘a’ on the heap. We have no control over where ‘a’ is placed in memory. On my machine, however, the operating system decided to put ‘a’ at the exact memory address where 144 used to be. As a result, when we print out *p, we get 97, which is the ASCII numerical representation of ‘a’.

Fun stuff.