Rash thoughts about .NET, C#, F# and Dynamics NAV.

In the last part of this blog series I showed how we can utilize the DistributionMonad in order to solve the famous Monty Hall problem. This time I want to show you how we can use it to solve some basic Texas hold’em poker questions.

We start by defining a model for poker in F#:

As you can see we model cards as tuples of a rank and a suit. The complete deck is just a combination of all ranks with all suits.

Now we need some additional helpers for the DistributionMonad, which will allow us to draw cards from the deck. You can find further explanations about these helpers in the excellent paper by Martin Erwig and Steve Kollmansberger called "Functional Pearls: Probabilistic functional programming in Haskell". Like the DistributionMonad itself, these helpers are already in the FSharp.Monad project and you get the bits from nuget.org.

Now we are ready to perform our first query. Let’s see how we can compute the probability of drawing the Ace of Clubs and the Ace of Spades:

But we can easily go a step further:

If you keep this model in mind you might come up with a poker odds calculator on a smart phone. This might be your chance to get rich. 😉

In the last part of this blog series I showed a DistributionMonad, which allows to perform queries to probability scenarios. Today we will use this monad in order to solve the famous Monty Hall problem. This article is based on the excellent paper by Martin Erwig and Steve Kollmansberger called "Functional Pearls: Probabilistic functional programming in Haskell".

“Suppose you’re on a game show, and you’re given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what’s behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice?”

[problem definition from Wikipedia]

Let’s start by modeling the first choice using the DistributionMonad:

As we can see the solution is 1/3 as we expected and if we don’t switch, we stay with these odds. But if we switch we might improve the probability for a car. Remember the host will always remove a Goat after your first pick. Let’s analyze the second pick if we switch:

If the Car is behind door 2 or door 3 the situation is symmetrical and therefor we can conclude, the following:

And if we run this, we get this nice solution:

Next time I will show how we can use the DistributionMonad to solve some basic poker scenarios.

In part I of this blog series I showed a simple InfinityMonad, which allows to treat special calculations as infinity and in the second part I showed the UndoMonad, which defines an environment which allows to undo and redo state changes.

This and the following posts are based on a famous paper by Martin Erwig and Steve Kollmansberger called "Functional Pearls: Probabilistic functional programming in Haskell".

Let’s start by looking at a small scenario:

This simple query calculates the probability of the event, that an dice roll gives a value greater than 3 and an independent coin flip gives “Heads”. In order to do this the DistributionMonad enumerates all possibilities and calculates the joint probability using the following formula:

If we want the nice syntactic sugar we can easily define a computation expression builder:

In order to allow easier access to our monad, we define some helper functions and basic distributions for fair coins and dices:

In the next part of this blog series I will show how we can utilize the DistributionMonad in order to solve the famous Monty Hall problem.

In part I of this blog series I showed a simple InfinityMonad, which allows to treat special calculations as infinity. This time I want to demonstrate a ported version of the UndoMonad (see the Haskell version). This monad defines an environment which allows you to undo and redo state changes. You probably know this behavior from your favorite text editor.

Let’s start by using this monad in a small sample:

The definition of this monad is easy if we use the StateMonad, which is already implemented in the FSharp.Monad project (you get the bits from nuget.org). We only need to define the kind of state which should be passed through the monad.

Now we need some helpers, which allow to access and manipulate our history.

In the next part I’ll show a DistributionMonad, which allows to perform queries to probability scenarios.

At the moment I am collecting some samples for the FSharp.Monad project (you get the bits from nuget.org) and I think I should describe some of these monads here, since they are not that common.

Today I will start with a very small monad which encapsulates infinity as a special value. I found the the idea to this specific monad at http://visualizationtools.net. Let’s start with the basic definition. Like every monad we need a container type and the two functions return and bind. Return will be used to get values into the monad and bind allows us to chain functions inside the monad.

The next thing is to create a computation expression builder which allows us to use the nice syntactic sugar in F#.

Now we can start using the monad. As a small sample we define a safe division function which treats all “division by zero” cases as infinity.

And we can use this division inside computation expressions.

Remark: You can easily define this InfinityMonad in terms of the common MaybeMonad. You can see this in the UnitTests of the FSharp.Monad project.

Next time I will show an UndoMonad which defines an environment which allows to undo and redo state changes.

Letzte Woche habe ich im Rahmen der F# Gruppe der .NET Online User Group einen Vortrag zu “Higher-Order-Functions in C#” gehalten. Unter http://vimeo.com/17048170 ist die Aufzeichnung nun zu finden.

Funktionale Programmiersprachen nehmen seit geraumer Zeit einen hohen Stellenwert in der Wissenschaft ein. Mittlerweile ziehen viele der funktionalen Konzepte bereits in den Mainstream ein. Bei diesem Treffen wollen wir einen Einblick in funktionale Konzepte und deren Umsetzung in C# gewinnen. Insbesondere soll auf "Funktionen höherer Ordnung", "Pattern Matching", "Unveränderlichkeit" und parallele Programmierung eingegangen werden.

Vortragsabstract

Today I’m starting a new blog post series about solving code katas in F# and with the help of my NaturalSpec project. A code kata is a programming exercise which helps to improve your skills through practice and repetition. In this series we want to use the Test Driven Development TDD approach which means in the context of NaturalSpec that we have to write our specs before we implement the algorithm.

Problem Description

“The game of yahtzee is a simple dice game. Each round, each player rolls five six sided dice. The player may choose to reroll some or all of the dice up to three times (including the original roll). The player then places the roll at a category, such as ones, twos, sixes, pair, two pairs etc. If the roll is compatible with the score, the player gets a score for this roll according to the rules. If the roll is not compatible, the player gets a score of zero for this roll.

The kata consists of creating the rules to score a roll in any of a predefined category. Given a roll and a category, the final solution should output the score for this roll placed in this category.”

[codingdojo.org]

Category 1 – Ones, Twos, Threes, Fours, Fives, Sixes

“Ones, Twos, Threes, Fours, Fives, Sixes: The player scores the sum of the dice that reads one, two, three, four, five or six, respectively. For example, 1, 1, 2, 4, 4 placed on "fours" gives 8 points.”

After reading this category description we could come up with the following spec:

Since we really want to implement six different categories we should also add some more scenarios like this one:

Now we have some specs but they will all fail since we don’t have anything implemented yet. So we have to come up with a model of dice rolls and categories. As the specs suggests we model the dice roll as a tuple of ints and the category as a discriminated union:

The tuple is a natural choice for the dice roll, but for easier calculation we add a helper function which converts it into a list. This allows use to use the standard list functions and therefore summing the values becomes trivial:

Now we can run our scenarios with any NUnit runner. I’m using the default NUnit GUI runner here, which gives me a picture like this:

Category 2 – Pair

“Pair: The player scores the sum of the two highest matching dice. For example, 3, 3, 3, 4, 4 placed on "pair" gives 8.”

The kata description gives us some new scenarios. As seen above we should specify them before writing the code.

Since we use a new category we now have to extend our model and the calcValue function:

Category 3 – Two pairs

“Two pairs: If there are two pairs of dice with the same number, the player scores the sum of these dice. If not, the player scores 0. For example, 1, 1, 2, 3, 3 placed on "two pairs" gives 8.”

Implementing this category is a little bit tricky but with the help of our Pair function and some more standard sequence combinators we can get our spec green:

Category 4 – Three of a kind

“Three of a kind: If there are three dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 3, 3, 3, 4, 5 places on "three of a kind" gives 9.”

Now it is time to refactor our code. The sumAsPair function should be extended to a sumAsTuple function:

Category 5 – Four of a kind

“Four of a kind: If there are four dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 2, 2, 2, 2, 5 places on "four of a kind" gives 8.”

With the help of the takeBestTuple function this becomes trivial:

type Category =

| Ones

  // …

| FourOfAKind

let calcValue category roll =

      // …

    | FourOfAKind  -> takeBestTuple 4 list

Category 6 – Small straight

“Small straight: If the dice read 1,2,3,4,5, the player scores 15 (the sum of all the dice), otherwise 0.”

As in all the above scenarios we don’t assume any specific order in our rolls but for this category it is easier to test if the data is sorted:

Category 7 – Large straight

“Large straight: If the dice read 2,3,4,5,6, the player scores 20 (the sum of all the dice), otherwise 0.”

Of course the implementation is exactly the same as for the small straight:

Category 8 – Full house

“Full house: If the dice are two of a kind and three of a kind, the player scores the sum of all the dice. For example, 1,1,2,2,2 placed on "full house" gives 8. 4,4,4,4,4 is not "full house".”

Implementing the FullHouse category is easy if we reuse our solutions to the Two pairs category:

Category 9 – Yahtzee

“Yahtzee: If all dice are the have the same number, the player scores 50 points, otherwise 0.”

Here we can use NaturalSpec’s ScenarioTemplates in order to specify all Yahtzees:

The implementation is pretty easy:

Category 10 – Chance

“Chance: The player gets the sum of all dice, no matter what they read.”

This seems to be the easiest category as we only have to sum the values:

Conclusion

We used a lot of F#’s sequence combinators, pattern matching and discriminated unions in this kata. I think this shows that F# is very well suited for such a problem and with NaturalSpec we can easily use a TDD/BDD approach.

The complete source code can be found in the NaturalSpec repository.

If you want to know more about a specific part of the kata or NaturalSpec feel free to contact me.

In my last article (Introducing NaturalSpec – A Domain-specific language (DSL) for testing) I used NaturalSpec in two small samples. This time I will show how we can set up a NaturalSpec environment to write our first automatically testable scenarios.

1. Choosing an IDE

The first step is to choose an integrated development environment for NaturalSpec. At the current project status you should be able to use NaturalSpec with Visual Studio 2008, Visual Studio 2010 beta 2, the freely available Visual Studio 2008 Shell or the free IDE SharpDevelop 3.0.

2. Installing the testing framework

As NaturalSpec uses NUnit as the underlying testing framework we have to install NUnit 2.5. I also recommend installing TestDriven.Net in order to get a Unit Test runner within Visual Studio.

3. Installing F#

NaturalSpec is completely written in F# and all specs will also be written in F#. This doesn’t imply you have to learn programming in F# but we need the F# compiler to get things working. You can download the F# October 2009 CTP from the Microsoft F# Developer Center.

4. Downloading the latest version of NaturalSpec

You can download a .zip with the latest NaturalSpec libraries from GoogleCode.

5. Creating a spec

This part is written for using Visual Studio 2008. If you use SharpDevelop or Visual Studio 2008 Shell this might differ in some detail.

Start Visual Studio 2008 and create a new F# class library.

Rename Module1.fs in ListSpec.fs and delete script.fsx from the project:

Create a folder “Lib” and unzip the NaturalSpec libraries into it.

Add NaturalSpec.dll and nunit.framework.dll as references to your project:

Copy the following code into ListSpec.fs:

module ListSpec

open NaturalSpec

[<Scenario>]
let When_removing_an_3_from_a_small_list_it_should_not_contain_3() =
  Given [1;2;3;4;5]
    |> When removing 3
    |> It shouldn't contain 3
    |> Verify

If you have TestDriven.Net installed you can run your spec via right click in the solution explorer:

If you don’t like the TestDriven.Net test runner you might want to use the NUnit GUI runner. The output should look like:

In addition the test runner should produce a Spec output file with the name “Spec.txt” within the same folder.

Summary

In a minimal environment you need SharpDevelop, the F# compiler, NUnit and the NaturalSpec libraries for using NaturalSpec.

In the next post I will show how you can use NaturalSpec to create a spec for C# projects.

This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at lazy evaluation.

Question 5 – What is the difference between “Lazy Evaluation” and “Eager evaluation”?

Lazy evaluation is a technique of delaying a computation until the result is required. If we use eager evaluation an expression is evaluated as soon as it gets bound to a variable.

One participant answered that lazy evaluation is used in most programming languages to calculate boolean expressions faster. For instance in the expression “x() or y()” the function y() is never called if x() returns true.

Of course this answer is correct, but this "short-circuit evaluation" is only a special case of lazy evaluation. The program would also work correctly without it. But if we want to define an infinite sequence then we can not use eager evaluation. Let’s look at an example:

// val fibs: seq<int>
let fibs = (1, 1) |> Seq.unfold(fun (n0, n1) -> Some(n0, (n1, n0 + n1)))

We do not need to understand the concrete syntax of this code here. We’ll discuss this later. Let’s just say fibs is bound to an infinite sequence (IEnumerable<int>) of Fibonacci numbers. You could also write this in C#:

/// <summary>
/// Infinite sequence of Fibonacci numbers.
/// </summary>
public static IEnumerable<int> Fibs()
{
    var n0 = 1;
    var n1 = 1;
    while(true)
    {
        yield return n0;
        var t = n1;
        n1 = n1 + n0;
        n0 = t;
    }
}

The trick is IEnumerable evaluates the elements lazy. Only at the time we take an element from the sequence the element will be computed:

fibs
  |> Seq.take 10
  |> Seq.to_list
  |> printfn "%A" // prints [1; 1; 2; 3; 5; 8; 13; 21; 34; 55]

If we would use eager evaluation then “Seq.take” would never been called. But we can go one step further. If we want to get the first 10 even-valued terms in the Fibonacci sequence, we can write this code:

fibs 
  |> Seq.filter (fun fib -> fib % 2 = 0) // lazy (via pipe)
  |> Seq.take 10                         // lazy (via pipe)
  |> Seq.to_list                         // eager
  |> printfn "%A" 
  
// prints [2; 8; 34; 144; 610; 2584; 10946; 46368; 196418; 832040]

This would be a little bit tricky if we use eager evaluation, but of course this nice laziness comes with some costs for storing intermediate results (and code). So eager evaluation is still often the better choice and sometimes (e.g. DateTime.Now()) it makes no sense to use lazy evaluation – at least not if we don’t reevaluate the function.

Yesterday I was talking about F# at the .NET Developer Group Braunschweig. It was my first talk completely without PowerPoint (just Live-Coding and FlipChart) and I have to admit this is not that easy. But the event was really a big fun and we covered a lot of topics like FP fundamentals, concurrency and domain specific languages (of course I showed “FAKE – F# Make”).

Now I have a bit time before I go to the next BootCamp in Leipzig. Today Christian Weyer will show us exciting new stuff about WCF and Azure.

In the meanwhile I will write here about another important question (see first article) from the F# BootCamp in Leipzig:

Question 4 – Try to explain “Currying” and “Partial Application”. Hint: Please show a sample and use the pipe operator |>.

Obviously this was a tricky question for FP beginners. There are a lot of websites, which give a formal mathematical definition but don’t show the practical application.

“Currying … is the technique of transforming a function that takes multiple arguments (or more accurately an n-tuple as argument) in such a way that it can be called as a chain of functions each with a single argument”

[Wikipedia]

I want to show how my pragmatic view of the terms here, so let’s consider this small C# function:

public int Add(int x, int y)
{
   return x + y;
}

Of course the corresponding F# version looks nearly the same:

let add(x,y) = x + y

But let’s look at the signature: val add : int * int –> int. The F# compiler is telling us add wants a tuple of ints and returns an int. We could rewrite the function with one blank to understand this better:

let add (x,y) = x + y

As you can see the add function actually needs only one argument – a tuple:

let t = (3,4)         // val t : int * int
printfn "%d" (add t)  // prints 7 – like add(3,4)

Now we want to curry this function. If you’d ask a mathematician this a complex operation, but from a pragmatic view it couldn’t be easier. Just remove the brackets and the comma – that’s all:

let add x y = x + y

Now the signature looks different: val add : int -> int –> int

But what’s the meaning of this new arrow? Basically we can say if we give one int parameter to our add function we will get a function back that will take only one int parameter and returns an int.

let increment = add 1      // val increment : (int -> int)
printfn "%d" (increment 2) // prints 3

Here “increment” is a new function that uses partial application of the curryied add function. This means we are fixing one of the parameters of add to get a new function with one parameter less.

But why are doing something like this? Wouldn’t it be enough to use the following increment function?

let add(x,y) = x + y       // val add : int * int -> int 
let increment x = add(x,1) // val increment : int -> int
printfn "%d" (increment 2) // prints 3

Of course we are getting (nearly) the same signature for increment. But the difference is that we can not use the forward pipe operator |> here. The pipe operator will help us to express things in the way we are thinking about it.

Let’s say we want to filter all even elements in a list, then calculate the sum and finally square this sum and print it to the console. The C# code would look like this:

var list = new List<int> {4,2,6,5,9,3,8,1,3,0};
Console.WriteLine(Square(CalculateSum(FilterEven(list))));

If we don’t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

With the help of curried functions, partial application and the pipe operator we can write the same thing in F#:

let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0]

let square x = x * x

list
 |> List.filter (fun x -> x % 2 = 0) // partial application
 |> List.sum
 |> square
 |> printfn "%A"                     // partial application

We describe the data flow in exactly the same order we talked about it. Basically the pipe operator take the result of a function and puts it as the last parameter into the next function.

What should we learn from this sample?

1. Currying has nothing to do with spicy chicken.
2. The |> operator makes life easier and code better to understand.
3. If we want to use |> we need curryied functions.
4. Defining curryied functions is easy – just remove brackets and comma.
5. We don’t need the complete mathematical theory to use currying.
6. Be careful with the order of the parameter in a curryied function. Don’t forget the pipe operator puts the parameter from the right hand side into your function – all other parameters have to be fixed with partial application.