RK4 in Scala

August 27, 2009

I’ve been looking at Scala recently and I’m impressed. It’s got a nice mix of imperative and functional styles that means that it can be really useful and easy to code in.

As an example I thought I’d knock up an implementation of RK4 in it.

The work-horse of RK4 is implemented as follows:

def rk4Iter(f: (Double, Double) => Double, 
            t : Double, 
            y : Double, 
            h : Double) = {
  val k1 = f(t, y)
  val k2 = f(t + h / 2, y + h * k1 / 2)
  val k3 = f(t + h / 2, y + h * k2 / 2)
  val k4 = f(t + h, y + h * k3)
  y + h * (k1 + k2 * 2 + k3 * 2 + k4) / 6

One thing I think we can all agree on is that having functions as first-class objects makes this incredibly succinct and easy to follow. I’m just calling the function f a whole bunch of times. Coming from a Java background this is pleasantly less noisy (compare with f.calculate(t, y) etc).

Another subtlety is the lack of specifying a return type. Scala is smart enough to infer the return type 🙂

This method is intended to be called from a loop that performs n steps of size h:

def rk4(f: (Double, Double) => Double, 
            t0 : Double, 
            y0 : Double, 
            n : Int, 
            h : Double) 
    : Double = {
  n match {
    case 0 => y0
    case _ => 
      val y1 = rk4Iter(f, t0, y0, h)
      rk4(f, t0 + h, y1, n - 1, h)

For those coming from a Java background you’ll notice that match looks a lot like switch. You can think of it as switch on steroids (I’ll leave off explaining more as it’s a blog post in its own right!). It is sufficient to say that case _ is similar to default.

In functional programming the preferred way to do things is using recursion rather than iteration (when written properly the compiler can identify tail-recursive functions and make them just as fast as loops). We do this because it makes them easier to mathematically reason about them. Suppose the function works for:

  • the 0th case
  • the nth case if it works for the n -1th case

then the function works for all positive integers.

A recursive style also reduces the scope for off-by-one errors.

And now for an example that ties it together:

  (t, y) => 4 * Math.exp(0.8 * t) - 0.5 * y, 
  0, 2, 10, 0.1)

I think anyone coming from a Java background will agree that passing around functions like this is lovely: goodbye interfaces and lots of curly braces, hello Functional Programming.

Launch of Two New Sites

August 20, 2009

Today I see the launch of two sites of mine that I’ve been working on in my free time over the past month or so. Neither of them are finished and well polished, but, the act of getting them out there will ensure I start taking them more seriously and start getting them used 🙂

So, I am proud to present: No Green Sheep and Self-review.com.

No Green Sheep

The idea behind this site is to promote being more green and friendly to our planet – but by understanding the effects of our actions instead of just doing whatever someone tells us.

The inspiration for this was a friend boiling a kettle on a gas hob and telling me it was more eco-friendly than boiling in an electric kettle. I asked “how?” and they couldn’t explain or give any numbers… unsurprisingly, I haven’t changed my kettle boiling habits. If my friend had known a few more details about this then she might well have had a convert out of me!


When I worked at CHP Consulting I kept a monthly reminder in Outlook telling me to review how I’ve done over the past month. This process of self-reflection allowed me to move forward and improve myself in a positive manner. It also gave me complete ownership of it – it’s far better to set your own goals and achieve them than have someone else do it for you.

After leaving CHP I no longer had Outlook. I also decided I needed something a little more guided – something I could just tick a box to say I’d done what I wanted to do. I also wanted to gain feedback from my friends whenever possible (a self-criticising blog post of mine made me realise I wanted this). So, I made self-review.com. The commenting isn’t yet ready – but I’ll keep you posted!

My first review of myself is available at http://www.self-review.com/reviews/5

Twitter Accounts for Both

If you want to keep up-to-date with both of these projects then they have their own Twitter accounts: selfreview and nogreensheep

Why We Made Our Own Bug Tracker

August 11, 2009

Part of starting the development of Sonnet Models was choosing a bug tracker. Knowing that reinventing the wheel was a bad thing I decided that we should do it anyway.

Why would I do this? Knowing full-well of the existence and having used numerous bug trackers I decided that they all suffered from one common flaw: bloat.

Bloated with Fluff-Fields

If entering a bug requires more than 20 seconds of entering other fluff (such as priority, origin, area, etc etc) then small bugs will simply not get entered most of the time because it takes too long. It’s hard to admit that people are lazy but I’ve seen it happen too many times, “I’ll just add this bug onto this other issue to avoid trying to remember what to put in field X”.

I also believe that people tend to rush filling in such fluff-fields and the result is that much of the data is junk.

What do we Track?

In our bug tracker we have nine fields per bug.

Three of these are automatically generated and cannot be modified (created date, creator, modified date).

The other six are: type (bug, feature or admin task), summary, details, timebox, status (created, ready for testing, pending release, closed) and assignee. That’s it. I’m even considering binning the type field as we rarely use it (fortunately it defaults to bug so there isn’t an admin overhead here).

We allow commenting – but there is only one field – comment.

Drawback – No Sexy Reporting

Sure, I can’t query the bugs database to see the most common origin of bugs, but, as a start-up we have a very good feel for this and knowing the exact numbers wouldn’t justify the cost in time of collecting this data.

I also feel that the lack of sexy reporting is an advantage – I don’t spend half my afternoon trawling through meaningless reports looking for imaginary trends!

Question for Large Companies

Do you actually get any use from all the random data you collect? Or is it slowing you down? Are bugs slipping the net because people don’t want to have the burden of reporting bugs? (Or the e-mail deluge that normally follows from reporting a bug).

Avoiding the fluff is a hard task and sometimes we should learn to just say “no, we can’t add a field onto our bug reports saying what coffee the reporter was drinking at the time”.

Agile Zen

I’d like to finish this post by mentioning a new tracker: Agile Zen. This is an immensely light weight tracker and if it had commenting… we’d switch over as quickly as possible!