Just what do you think you're doing, Dave?

The first bit was easy: I’m “lucky” enough to have one of the older Xboxes, which meant I’d had to get a Kinect with separate power, which is the one required by the SDK. Now all I needed was a Windows machine to develop on.

For all my Visual Studio stuff at home I use a virtual machine, and unfortunately I missed the point in the readme about “Kinect for Windows applications cannot run in a virtual machine”. Doh. That would explain why, try as I might I couldn’t get VirtualBox to detect the device when I plugged it into the host. Whatever I did I ended up with a ‘resource is busy’ error.

I even tried another VM, this time from VMWare. It got further, with the guest seeing the devices, but whenever I tried to run the sample apps the API initialisation call failed. Unfortunately the samples make a bit of a rookie mistake and don’t display the error code associated with the failure; the only way to get the underlying HRESULT is to debug the app. As it turned out the error was the catch-all 80080014, which is attributed to various USB issues.

So, I finally relented and decided to once again set-up Bootcamp, which I’d stopped using a while back: why bother when VMs had done everything I needed? Again I was snookered, this time by the incompatibility of the EFI firmware in my ageing MacBook with the Win7 x64 install disc (which I’d had to actually burn onto optical media – can’t remember the last time I burnt a real physical disk)!

Eventually, I got Win7 x86, Visual Studio and the Kinect SDK installed on the metal, plugged in the sensor and – whoa – the devices were recognised and the drivers installed and… the samples ran!

From this point doing some hacking was pretty straightforward. I set about creating a project that used the skeletal tracking ability from the SDK. The project needs to reference the Microsoft.Research.Kinect assembly, then we can open some namespaces and initialise the API:

open System
open Microsoft.Research.Kinect
 
let nui = Nui.Runtime()
nui.Initialize(Nui.RuntimeOptions.UseSkeletalTracking)

The API uses .NET events to communicate back to the application that some form of data is available. Depending on the options that you specify at init time, any of the skeletal, depth frame or colour data will be returned in the event arguments. This seems like a good place to use F# Async’s event integration: Async.AwaitEvent. We can quite easily write some code that will create an Async task that will repeatedly listen for events:

    let skeleton (nui : Nui.Runtime) =
        let rec loop () =
            async { 
                let! args = Async.AwaitEvent nui.SkeletonFrameReady
                // Do something with the args
                return! loop () 
            }
        loop ()
    // Start the process of listening for events...
    skeleton nui |> Async.Start

This seems to work nicely, although I’m not sure of the overhead involved, perhaps a solution involving Rx would be more appropriate. Anyway, let’s do something with the data we get in the event, like getting all the skeletons that are being tracked, and passing them to a draw function:

                args.SkeletonFrame.Skeletons 
                |> Seq.filter (fun s -> s.TrackingState = Nui.SkeletonTrackingState.Tracked)
                |> Seq.iter draw

All that’s left is doing something cool in draw! Oh, and setting up all the GUI stuff necessary to actually get some pixels on the screen. I went for the WPF approach (as the managed samples do), which involves creating a simple object tree to display a rectangle in a canvas in a grid in a window, and doing a bit of marshalling back from the thread pool (where our Async code runs) to the main GUI thread.

Here’s all the code for possibly the most tedious thing you could do with a Kinect! But hey, it’s a starting point, right? I’m sure at some point I’ll get around to doing something cooler than a couple of small red rectangles with it…

open System
open System.Windows
open Microsoft.Research.Kinect
 
[<STAThread>]
do
    let nui = Nui.Runtime()
    nui.Initialize(Nui.RuntimeOptions.UseSkeletalTracking)
 
    // lifted straight from the sample code
    let getDisplayPosition w h (joint : Nui.Joint) =
            let mutable depthX = 0.0f
            let mutable depthY = 0.0f
            nui.SkeletonEngine.SkeletonToDepthImage(joint.Position, &depthX, &depthY)
            let depthX = depthX * 320.0f; //convert to 320, 240 space
            let depthY = depthY * 240.0f; //convert to 320, 240 space
            let mutable colorX = 0
            let mutable colorY = 0
            let iv = new Nui.ImageViewArea()
            // only ImageResolution.Resolution640x480 is supported at this point
            nui.NuiCamera.GetColorPixelCoordinatesFromDepthPixel(Nui.ImageResolution.Resolution640x480, iv, 
                (int)depthX, (int)depthY, 0s, &colorX, &colorY)
 
            // map back to visible area
            new Point((w * (float)colorX / 640.), (h * (float)colorY / 480.))
 
    // Set-up the WPF window and its contents
    let width = 1024.
    let height = 768.
    let w = Window(Width=width, Height=height)
    let g = Controls.Grid()
    let c = Controls.Canvas()
    let hd = Shapes.Rectangle(Fill=Media.Brushes.Red, Width=10., Height=10.)
    ignore <| c.Children.Add hd
    ignore <| g.Children.Add c
    w.Content <- g
 
    // We simple move the rectangle to where the head is
    let draw (s : Nui.SkeletonData) =
        let point = getDisplayPosition width height s.Joints.[Nui.JointID.Head]
        ignore <| w.Dispatcher.BeginInvoke(Threading.DispatcherPriority.Normal, Action(fun () ->    
            hd.SetValue(Controls.Canvas.TopProperty, point.Y)
            hd.SetValue(Controls.Canvas.LeftProperty, point.X)))
 
    let skeleton (nui : Nui.Runtime) =
        let rec loop () =
            async { 
                let! args = Async.AwaitEvent nui.SkeletonFrameReady
                args.SkeletonFrame.Skeletons 
                |> Seq.filter (fun s -> s.TrackingState = Nui.SkeletonTrackingState.Tracked)
                |> Seq.iter draw
                return! loop () 
            }
        loop ()
 
    skeleton nui |> Async.Start
 
    let a = System.Windows.Application()
    ignore <| a.Run(w)
 
    nui.Uninitialize()

The moral of the story? Don’t be like me, and make sure you actually read the FAQing readme, then maybe you’ll spend more time doing a decent demo and less time plugging and unplugging your Kinect!

The change

The change itself is simple: static fields can no longer be public. Static fields can still be created, but they must be private.

In pre-2.0 versions of F# it was possible to declare a static field on a type like this:

type MyType() =
    [<DefaultValue>]
    static val mutable public MyProperty : int

Resulting in a type containing a static field, as you’d expect:

    .field public static int32 MyProperty

The code now generates the compiler error:

error FS0881: Static 'val' fields in types must be mutable, private and marked with the '[<DefaultValue>]' attribute. They are initialized to the 'null' or 'zero' value for their type. Consider also using a 'static let mutable' binding in a class type.

Notice that there are already some gnarly aspects to the definition of the property; notably the use of the [<DefaultValue>] attribute, which indicates that the field is un-initialized. This gives us a hint that there might be some inherent problems.

Why do we even need them?

In a word or three: WPF dependency properties.

The recommended way of implementing dependency properties in other .NET languages is to use public static fields, e.g. in C#:

    public static readonly DependencyProperty MyPropertyProperty =
        DependencyProperty.Register( 
          "MyProperty", typeof(int), typeof(MyType));

This is one of the few places where C# is terser than F#. Here we can declare and define the value in one line (ish), whereas F# requires a separate declaration of the field (as above) then initialisation in the static constructor (static do).

Why was it removed?

I got the answer from the horse’s mouth. Don Syme said that:

We deliberately removed the ability to create public static fields in Beta2/RC, because of issues associated with initialization of the fields (i.e. ensuring the “static do” bindings are run correctly, and if they are run, then they are run for the whole file, in the right order, with no deadlocks or uninitialized access when initialization occurs from multiple threads).

You can imagine how this would be a problem; there would need to be a way of ensuring that whichever static field was accessed it caused the static constructor to run, which may itself access static fields. All pretty nasty. In fact, Don mentioned that C# suffers from much the same synchronisation issues, but just tends to be used in a way that means it’s less likely to be noticed!

The alternative

At least in theory it’s possible to create a type that uses static properties rather than static fields to store its registered DependencyProperty information.

type Foo () =
    inherit FrameworkElement()
    static mutable private _myPropertyInternal : DependencyProperty 
    static member this.MyProperty with get () = _myPropertyInternal

Whether or not this works depends very much on how calling code accesses DependencyProperty information. If it uses reflection to access the field directly it will obviously fail. But if it uses a more robust/flexible method then it should be OK. Empirically it seems that the WPF framework code itself does the latter, for instance, when it’s instantiating objects from XAML, and it works properly independently of how it’s implemented.

The conclusion

So the conclusion is “wontfix”: the behaviour is by design. Unfortunately it has the effect that it’s no longer possible to create a type with an identical IL “signature” in both F# and C#. It seems a bit of a shame, but I guess the trade-off is that we’re protected against insiduous initialisation issues, so it will probably turn out to be the right thing in the long term.

type public MyControl() =
    inherit ItemsControl()
 
    [<defaultValue>]
    static val mutable FooProperty : DependencyProperty
 
    static member OnFooChanged (dob:DependencyObject) args =
        (dob :?> MyControl).Update ()
 
    [<system.ComponentModel.Bindable(true)>]
    member public this.Foo
        with get() : string  = string (base.GetValue(MyControl.FooProperty))
        and  set(r : string) = base.SetValue(MyControl.FooProperty, r)
 
    override this.OnPropertyChanged (args) =
        match args.Property.Name with
        | "Foo" -> this.Update ()
        | _          -> ()
 
    member internal this.Update () =
        System.Diagnostics.Debug.WriteLine (sprintf "Updating %A" (base.GetValue(MyControl.FooProperty)))
 
    static do
        let metadata = PropertyMetadata(null, PropertyChangedCallback (MyControl.OnFooChanged) )
        MyControl.FooProperty <- DependencyProperty.Register("Foo", typeof<string>, typeof<MyControl>, metadata)

Constructor

We don’t have one! Well, that’s not strictly true. There’s no per-instance set-up that we need to do here, so instead we have a default, parameter-less constructor implied by the “empty brackets” syntax in the type declaration. If we wanted to execute some code in the constructor, we could add the following:

    do
        Debug.WriteLine "Constructing."

It’s also possible to add further constructors (perhaps parameterised differently) but when using WPF bear in mind that instances of your class will often be created from a XAML declaration, which generally uses the default constructor and then sets properties as required. Mutable objects: ug.

Inheritance

Our type derives from the WPF ItemsControl class using the inherit keyword. Of course, we’re still subject to the single-inheritance limit of .NET (not a bad thing, if you ask me – no more tortured object hierarchies):

type public MyControl() =
    inherit ItemsControl()

Note that we have to include the empty brackets on the inherited type name, as this will be constructed implicitly when our derived class is constructed. We can access the inherited class from elsewhere in the code using the base keyword.

Static members

Dependency properties are a WPF construct that provide external storage of property values. They allow deep trees of objects to efficiently use lots of properties where they often have the default value, which is commonly the case in WPF. In order to use them with your class you have to do a few things, including creating a static value to hold the property and its metadata. We create a mutable static member for this:

    [<defaultValue>]
    static val mutable FooProperty : DependencyProperty

Why a mutable static value? If you’ve used F# already you might be aware that it’s also possible to declare an immutable static variable and its initial value in one shot with a let:

    static let FooProperty = DependencyProperty.RegisterProperty ("Foo", typeof<string>, typeof<MyControl>)

Unfortunately, this results in your DP being private. Although the CLR property is still accessible, anything that attempts to access the DP directly – for instance, code within the WPF libraries – won’t see it. This means you have to use the mutable style, which is unfortunate.

Static methods

We’ve declared a static member function that is used to receive notifications when our DP is changed (although it’s complete overkill in this example, because we’ve already declared our DP with metadata that tells it to notify us when it changes):

    static member OnFooChanged (dob:DependencyObject) args =
        (dob :?> MyControl).Update ()

As you’d expect, there’s no this parameter on the signature, a static member doesn’t have any implicit object instance to work on. Luckily the arguments to most event functions include the DependencyObject that raised the notification. That means we can downcast dynamically to our expected type (with : ?>) and use it. Bear in mind that this is more like casting than as in C#, as it will throw an InvalidCastException at runtime rather than returning null.

Properties

In order for our dependency property to be easily accessible we can expose it as a plain old CLR property. The implementation of the getter and setter simply defers all of the actual work of storing and retrieving the value to the underlying dependency property.

    member public this.Foo
        with get() : string  = string (base.GetValue(MyControl.FooProperty))
        and  set(r : string) = base.SetValue(MyControl.FooProperty, r)

Notice how we have to cast the obj returned from GetValue into the correct type. This is another example of having to bridge the gap between the dynamically typed WPF property system and F#’s static typing.

Overridden members

As well as providing new member functions and properties, we may need to override existing ones. Member functions marked abstract in the base class can be overridden using the override keyword:

    override this.OnPropertyChanged (args) =
        match args.Property.Name with
        | "Foo" -> this.Update ()
        | _          -> ()

The F# compiler provides the same kind of checking that the C# compiler does, warning you if you inadvertantly hide a base class function by creating an override with the same name but not marking it with override.

Static constructor

As mentioned before, we use the static constructor to initialise our mutable static variables. The syntax is similar to the do syntax of a normal constructor, with the addition of the static keyword:

    static do
        let metadata = PropertyMetadata(null, PropertyChangedCallback (MyControl.OnFooChanged) )
        ...

Static constructors are run once per class, regardless of how many instances of the class you have. WPF relies quite heavily on static, class-based functionality; mostly because a lot of what’s set-up is per-class configuration – it’s not going to change during the lifetime of the application – so you may find yourself doing a fair amount of work in a static constructor.

So, there’s a quick run around some of the object-oriented features of the F# language: classes, inheritance, instance constructors, overridden member functions, static member functions and constructors. You can see how using WPF means you lose some of the benefits of the F# language; notably immutability and static typing. If you’re an experienced functional programmer getting deep into creating WPF or Silverlight custom controls you may find yourself using these OO constructs more than you’d like. Although F# makes it relatively painless in practice, mixing this heavily object oriented style of programming with a functional approach can still be a little hard to stomach at times.

I had a look at the text of the first exception, and from that it was obvious:


Unable to cast COM object of type 'System.__ComObject' to interface type 'IWhatever'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CAD939D0-5E5D-11D7-AA0B-0002B33FE9DX}' failed due to the following error: Bad variable type. (Exception from HRESULT: 0x80020008 (DISP_E_BADVARTYPE)).


The message contains curly brackets around the IID, and they’re being intrepreted as insertion points by a call to String.Format!

Workaround

So that explained why it only happens in debugger runs; as this post helpfully points out the WPF databinding is enabled by default in that case. To workaround it, you can disable logging programmatically or using the App.config file to only display Critical output. So if your app is named foo.exe, create a file foo.exe.config that contains:

<configuration>

  <system.diagnostics>

    <sources>

      <source name="System.Windows.Data" switchName="SourceSwitch"/>

    </sources>

    <switches>

      <add name="SourceSwitch" value="Critical" />

    </switches>

  </system.diagnostics>

</configuration>

Fix…?

Hopefully there’ll be a fix for this at some point soon, as disabling the logging is a pretty large hammer to crack this small nut.

Calculating option values using F#

The first thing you need is an approximation to the cumulative normal distribution. I used the Abromowitz and Stegun approximation, which should give us enough precision. It’s fairly concise to implement in F#:

let ncdf x =
  let b1 =  0.319381530
  let b2 = -0.356563782
  let b3 =  1.781477937
  let b4 = -1.821255978
  let b5 =  1.330274429
  let p  =  0.2316419
  let c  =  0.39894228
  match x with
  | x when x >= 0.0 ->
    let t = 1.0 / (1.0 + p * x)
    (1.0 - c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1))
  | _ ->
    let t = 1.0 / (1.0 - p * x)
    (c * Math.Exp( -x * x / 2.0)* t * (t*(t*(t*(t*b5+b4)+b3)+b2)+b1))

The CDF should be near 0 for low values, around 0.5 for zero, and near 1 for high values. Let’s check:

> [-5.0; 0.0; 5.0] |> List.map ncdf;;
val it : float list = [2.871049992e-07; 0.500000001; 0.9999997129]

Looks good.

Now let’s put it to use by implementing the option pricing formula for call options:

let call strike spot (rate:float) (now:float) (expiry:float) (vol:float) =
    let exp = expiry-now
    let d1 = (Math.Log(spot/strike) + ((rate+(vol*vol)/2.0)*exp))/(vol * Math.Sqrt(exp))
    let d2 = d1 - (vol * (Math.Sqrt(exp)))
    (spot * ncdf d1) - (strike * Math.Pow(Math.E, -rate*exp)*(ncdf d2)), ncdf d1

Notice that the function returns a tuple of (value,delta). Give that the greeks are available analytically we may as well return them at the same time as the value.

We can poke this a bit to check that it’s doing the right thing. A call option that’s way in-the-money (i.e. spot > strike) near to expiry, has a lot of intrinsic value:

> call 10.0 100.0 0.0 0.0 0.1 0.5;;
val it : float * float = (90.0, 1.0)

An at-the-money call option should have a delta close to 0.5 at expiry:

> call 10.0 10.0 0.0 0.0 0.1 0.5;;
val it : float * float = (0.6301280626, 0.5315064031)

All seems fine.

So lets see what we can do about visualising these relationships.

Using WPF with F#

You’d be forgiven for thinking that the XAML markup language is the only way to construct user interfaces in WPF. Indeed, if you want to avoid writing code it’s the way to go. But unfortunately it’s not possible to use F# as the code-behind XAML files, so you’re forced to use C#. And it’s also not as dynamic or immediate as it could be; involving the usual write, compile, run iteration. We can do better in F# using scripts and F# interactive (FSI).

The key is to construct the WPF object model imperatively, rather than declaratively with XAML. Yeah, I know this is normally the opposite of what you’d want to do.

For instance, here’s some code to create a Canvas. Note the use of a construction expression to both create the object and set some of it’s properties. This is just syntactic sugar which helps to make the object look slightly less mutable than it actually is:

    let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0)
    c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy))

We can use the WPF canvas panel to enable us to explicitly place points (or rather, Rectangles) on our plot, it uses absolute locations rather than the implied flow layout of the other containers (Grid, StackPanel etc). Putting this together, we can write a function which will take a parent Panel, and a list of (x,y) tuples and create a plot:

let plot (panel:Panel) (pts:(double * double) list) =
    let bgc = new Canvas(Name="Canvas", Width=300.0, Height=300.0)
    let c = new Canvas(Name="Canvas", Width=250.0, Height=250.0)
    c.SetValue(Canvas.LeftProperty, 25.0)
    c.SetValue(Canvas.TopProperty, 25.0)
    c.Background <- SolidColorBrush(Color.FromRgb(228uy,228uy,228uy))
    let x,y = pts |> List.unzip
    let xmin,xmax = x |> List.min, x |> List.max
    let ymin,ymax = y |> List.min, y |> List.max
    let xscale = c.Width / (xmax-xmin)
    let yscale = c.Height / (ymax-ymin)
    pts
    |> List.map (fun pt ->
        let p = new Rectangle(Width=2.0,Height=2.0)
        p.Stroke <- new SolidColorBrush(Color.FromRgb(0uy,0uy,0uy))
        p.SetValue( Canvas.LeftProperty, (fst pt - xmin) * xscale)
        p.SetValue( Canvas.TopProperty, c.Height - (snd pt - ymin) * yscale)
        p
        )
    |> List.iter (fun rect ->
        ignore <| c.Children.Add rect)
    ignore <| bgc.Children.Add (fst (makeYScale ymin ymax))
    ignore <| bgc.Children.Add (fst (makeXScale xmin xmax))
    ignore <| bgc.Children.Add c
    ignore <| panel.Children.Add bgc
    ()

The function returns nothing (unit in F# parlance) and performs a side-effecting modify of the passed Panel. I’ve omitted the makeXScale and makeYScale functions, as they’re a bit gnarly, and don’t really serve to demonstrate anything in particular.

Now we need to create some data to plot. We can do this in many ways, but one thing I looked at was creating a set of call option values with varying time to expiry. I thought this could use a floating point sequence, but it generated a deprecation warning, so I decided to do it long hand instead. This function returns a list of (time,value) tuples, where time range from rfrom to rto in num steps and value is calculated using the passed function f.

let varyExpiry f num rfrom rto =
    List.init num (fun n ->
        let s = rfrom + ((float n/float num) * (rto-rfrom))
        float s, fst <| f 10.0 10.0 0.05 0.0 s 0.5 )

We can pass the resulting list directly to our plot function, but first we need to create a window to display it in:

let w = new Window(Name="Plot",Width=500.0,Height=500.0)
let wp = new WrapPanel()
w.Content <- wp
w.Visibility <- Visibility.Visible

Executing this code in FSI will display a blank window (probably behind your active window if you're within Visual Studio). Then we can add the plot to the graph:

plot wp (varyExpiry call 100 10.0 100.0)

Voila! Obviously the plot is very, very basic, but it's an interesting experiment, and it does makes it extremely easy to plot functions interactively in almost the same way as you can with applications like Excel and MatLab. Pretty powerful.

Call option values for varying expiries

Call and put option values for varying expiries