Some Playing with Derivatives

This is a summary of what I’ve been playing with in case people find it interesting.

In general, there are three ways to find the derivative of a function:

Do the symbolic manipulation of formulae that we all learned in school when we were 16 years old. This assumes that one has the function as an algebraic expression of some kind in terms of known quantities.

Do it numerically, by computing (f(x + h) – f(x)) / h for some small value of h. This suffers from numerical inaccuracies, and will generally cause rises in the blood pressure of numerical analysts.

Calculate the value of the function and its derivative simultaneously at a given point of evaluation.

The last option seems to have a lot of names: automatic differentiation, algorithmic differentiation, and a few more. Just for fun, I wrote an implementation of a very simplified version of it in Haskell.

Essentially, this declares a data type to represent the pair of a number and its first derivative. It then defines how to perform primitive math operations on that data type, for three of Haskell’s numerical type classes. Note that basically the entire implementation consists of talking about how derivatives fare in the face of certain operations. In fact, you may recognize a lot of it from the algebra of differentials in calculus. For example, if z = xy, then dz = x dy + y dx, and so forth. (One quick note, because someone else asked me about this. The exponentiation operator ** is complicated because both the base and the exponent could be non-constant. So it must use both the power rule and the exponentiation rule.)

My Argument With the Type System

The last section is certainly weird. It defines four identical functions, because the type system gets in the way of doing what I really want. What I would like is for the diff function to map functions over the numeric typeclasses to other functions over the same type classes. For example, the derivative of a function with type (Num a => a -> a) will itself have type (Num a => a -> a). The derivative of a function with type (Floating a => a -> a) will itself have type (Floating a => a -> a). But the only way that works is for diff to get a type that depends on AD. That’s confusing, because the type AD is an implementation detail; and I’d rather not even export it. The user of this module won’t think they’ve written a function for the type AD; they’ve just written a function over any type that is an instance of, say, Floating.

To illustrate something closer to what would make me happy, I’ve also given the same function three better types, in diffNum, diffFractional, and diffFloating. These rank 2 types provide the right level of abstraction; but unfortunately, it’s impossible to write only one function that works for all three numeric type classes. Here’s what I’d really like to be able to say:

Here, I’m using :> to mean “is a superclass of”, and A is meant to quantify over type classes. In other words, the type says that given any type class that’s a superclass of Floating, I can pass in a function that’s polymorphic over that type class, and get back its derivative (interpreting its domain and range as being, at the very least, numbers). But that’s not possible, so the functions above all have some of the advantages, and I’ve written all of them.

The “no” part of the answer is because there are a few specific situations in which the code will give the wrong answer. First, the code I’ve written often gives a derivative when the derivative is really undefined. Sometimes this is me being sloppy; for example, the log of -1 is undefined, but this code provides a derivative anyway. I could fix this if I were willing to make my code a little uglier. Second, uses of fromRational and fromInteger must be constants, because the code assumes they are. It was pointed out by Luke Palmer that I can define a function of the correct type (Num a => a -> a) by using the Show superclass to convert a value to a string, then read it as an Integer, do all sorts of things to it, and then convert the result back to the type a by using fromInteger. Doing so will give a derivative of zero, even if your function really has a different derivative.

A more nefarious example is this:

f x = if x == 1 then 1 else x^2

This is the same function as f x = x^2. However, asking for the derivative at x = 1 will return 0, because the function returns the constant 1, whose first derivative is 0. In particular, the technique runs into problems right on the boundaries of intervals where the function is defined piecewise. It doesn’t appear to me that there’s a particularly good way of dealing with this, except to process the source code and modify if statements to refuse to calculate derivatives at those locations. That’s far beyond the scope of a little playing with overloading, so I have no intention of doing it.

Extending to Other Cool Stuff

If we just got functions computing values, this wouldn’t be very visual. In the effort to avoid introducing GUI libraries, I’ll play the old trick of graphing functions sideways in ASCII art. Let’s look at the second function in my example above… the weird one with square roots, exponentials, and inverse hyperbolic sines.

But what if you define f using diff, then apply diff to f?
Turns out you can get the wrong answer, given the way you’ve
written the code. Jeff Siskind and I went nuts on this issue,
concluding that although diff is referentially transparent,
it cannot be implemented in pure Haskell: you need to use
some dirty trick. We exhibit a bunch of such dirty tricks
in Scheme, but can’t do it in Haskell.

One big question is whether some new pure mechanism could
be added that would allow this in Haskell. Existential
types might do the trick, but so far I have not figured out
how…

PPS I am currently putting together the best of the forward-mode AD Haskell I’ve seen to try to make an actual usable version. Of course, this is all basically an exercise before the hard but important part: REVERSE-MODE AD!