August 17th, 2006

  • evan

differentiation of compiled functions

Typeful symbolic differentiation of compiled functions:
In this message, we develop the `symbolic' differentiator for a subset of Haskell functions (which covers arithmetics and a bit of trigonometry). We can write

test1f x = x * x + fromInteger 1
test1 = test1f (2.0::Float)
test2f = diff_fn test1f
test2 = test2f (3.0::Float)

We can evaluate our functions _numerically_ -- and differentiate them _symbolically_.


We must point out that we specifically do _not_ represent our terms as algebraic datatypes. Our terms are regular Haskell terms, and can be compiled!
The key here (as in most creative Haskell hacks) is the clever use of type classes, which may be the subject of my next post.

(The mail is from Oleg, who is the Haskell community's equivalent of _why: every few weeks or so he comes out with an absurd hack. The hackers mirrors the languages, as well: as _why's hacks are fast-and-loose and impenetrably obfuscated, Oleg's are often theory-heavy and impenetrably complicated.)
  • evan

data types are not objects

One question I can remember students asking, when faced with ML, is something like: "If the language doesn't have objects, how do you provide something like a reusable binary tree?" Without objects, that is, how do you package things into meaningful components? This is a good example of how knowing only one way of looking at the world frames your perception of it, and I like to think that it's one of the reasons forcing college kids through a programming languages course is worthwhile.*

Talking about what is and isn't OOP is too slippery to be able to say much that's meaningful, but hopefully this one lesson is worth keeping in mind: abstract data types do not require objects.

Collapse )