Antonio Vidal has translated this post into Spanish: you can find it here.

Dependency injection is a very simple concept: if you have an object that interacts with other objects the responsibility of finding a reference to those objects at run time is moved outside of the object itself.

What does it mean for an object to "interact" with other objects? Generally it means invoking methods or reading properties from those objects. So if we have a class A that invokes method Calculate on class B, we can say that A interacts with B.

In the following example we show class A interacting with class B. We can equally say that A depends on class B to fulfill a responsibility. In this case, it not only invokes its method Calculate but it also creates a new instance of that class.

class A
{
  private B _b;

  public A
  {
    _b = new B();
  }

  public int SomeMethod()
  {
    return (_b.Calculate() * 2);
  }
}

In the following example, on the other side, the responsibility of getting a reference to an implementation of a class of type B is moved outside of A:

class A
{
  private B _b;
  public A(B b)
  {
    _b = b;
  }
  public int SomeMethod()
  {
    return _(b.Calculate * 2);
  }
}

In this case we say that a dependency (B) has been injected into A, via the constructor. Of course, you can also inject dependencies via a property (or even a regular method), like in the following example:

class A
{
  private B _b;

  public B B
  {
     get { return _b; }
     set { _b = value; }
  }

  public int SomeMethod()
  {
    if (_b != null)
        return _b.RetrieveValue() * 2;}
    else
        // HANDLE THIS ERROR CASE
        return -1;
  }
}

So this is all there is about dependency injection. Everything else just builds on this core concept.

Like for example Inversion Of Control (IoC) tools which helps you wiring together your objects at run time, injecting all dependencies as needed. So what exactly is Inversion of Control and how does it relate to Dependency Injection (DI)?

I like to associate IoC to the Hollywood Principle: "Don't call us, we'll call you". IoC is a design principle where reusable generic code controls the execution of problem-specific code: it is a characteristic of many frameworks, where the application is built extending or customizing a common skeleton; you put your own classes at specific points and the framework will call you when needed.

You can use an IoC container as a framework to perform Dependency Injection on your behalf: you tell the container which are the concrete implementation classes for your dependencies and the container will make sure that your constructors or setters will be called with the right objects.

Therefore, IoC containers are just a convenience to simplify how dependency injection is handled. But even if you don't use one you could still manually perform dependency injection.

(If you want to have a look at how an IoC container works you can jump to my mini tutorial on Ninject).

Why is the concept of dependency injection important? Because by applying it, you simplify your design (separating the responsibility of using an object from the responsibility of retrieving that object) and your code becomes much easier to test, since you can mock out the dependencies substituting them with fake (stub) objects. But that is the subject for another post.

Today I've found myself reading again the excellent paper Why Functional Programming Matters, where the author describes the core activity of programming in a functional fashion in terms of "glueing functions together".

It's been a while since I last played around with F#. So I decided this would be a good time to refresh some of the core concepts by translating some of the examples from his paper into F#.

Reduce

The paper starts off describing how a reduce function could be devised, extrapolating a common behavior from a certain set of functions. Let's first consider a function to sum all the items in a list:

    let add a b = a + b

    let rec sum l =
        match l with
        | [] -> 0
        | h::t -> add h (sum t)
  

Nothing too fancy going on here. Let's now consider a similar function that instead multiplies together all the items in a list:

    let mul a b = a * b

    let rec product l =
        match l with
        | [] -> 1
        | h::t -> mul h (product t)
  

If you compare the structure of the two functions sum and product you can see that the two are very similar. The are only two differences between the two:

• The value being returned when an empty list is matched (0 vs 1).
• The function being applied between the head of the list and the application of the recursive function to the remaining of the list (add vs mul)

It's easy, then, to extrapolate a more general reduce function, as follows:

    let rec reduce f a l =
        match l with
        | [] -> a
        | h::t -> f h ((reduce f a) t)
  

Let's consider all the pieces step by step:

• reduce is a (recursive) function accepting a function f, a value a and a list l.
• f is the function that we want to apply between two elements of the list (sum or mul in the two examples above)
• a is the value that we want to return when f is applied to the empty list (0 or 1 respectively), and
• l is the actual list we want to operate on.

Let's try this new function in the interactive window:

  > reduce;;
  val it : (('a -> 'b -> 'b) -> 'b -> 'a list -> 'b)
  > reduce add 0 [1;2;3];;
  val it : int = 6
  > reduce mul 1 [1;2;3];;
  val it : int = 6
  

As you see, the compiler infers the types involved in reduce as follows:

• ('a -> 'b -> b') is the description of f: a function that takes two arguments of type 'a and 'b and returns one item of type 'b (note that 'a and 'b may in some cases represent the same type, as with add and mul).
• 'b is a parameter of the same type as the one returned by f.
• 'a listis a list of items the same type as the first argument of f.
• 'b is finally the return type of the whole reduction process

.

There's an interesting special case: when 'b is 'a list. That is, when f has the following form: ('a -> a' list -> a' list). A function receiving an item and a list and returning another list. Can you think of any function like that? What about concatenating an item and a list?

    let cons a l = a::l
  

Let's see how the F# interactive interprets the new function we've just created and an example of usage:

    > cons;;
    val it : ('a -> 'a list -> 'a list)
    > cons 1 [2; 3];;
    val it : int list = [1; 2; 3]
    >
  

And we now consider cons as our f function, first parameter of the reduce, we can write for example:

    let append a b = reduce cons b a
    let copy l = reduce cons l []
  

where append concatenates two lists and copy simply replicates any given list:

    > append;;
    val it : ('a list -> 'a list -> 'a list)
    > append [1;2] [3;4];;
    val it : int list = [1; 2; 3; 4]
    >  copy;;
    val it : ('a list -> 'a list)
    > copy [1;2;3];;
    val it : int list = [1; 2; 3]
    >

In the following post we'll continue translating some more core functions from the "Why Functional Programming Matters" into F#. Stay tuned!

I thougth I’d just share a couple of Visual Studio C# code snippets to implement disposable classes, based on the well known .NET dispose pattern.

You can download it from here or simply copy and past it from the listing below. Feel free to rename the shortcut to whatever you like

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Base class disposable implementation.</Title>
      <Shortcut>bdisp</Shortcut>
      <Description>
        Code snippet to create a scheleton implementation
        of the IDisposable pattern for a base class.
      </Description>
      <Author>Stefano Ricciardi</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>ClassName</ID>
          <ToolTip>Name of the class.</ToolTip>
          <Default>ClassName</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
    public class $ClassName$: IDisposable
    {
        private bool _disposed = false;

        //Implement IDisposable.
        public void Dispose()
        {
          Dispose(true);
          GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
          if (!_disposed)
          {
            if (disposing)
            {
              // Free other state (managed objects).
            }
            // Free your own state (unmanaged objects).
            // Set large fields to null.
            _disposed = true;
          }
        }

        // Use C# destructor syntax for finalization code.
        ~$ClassName$()
        {
          // Simply call Dispose(false).
          Dispose(false);
        }
    }            ]]>
      </Code>
    </Snippet>
  </CodeSnippet>
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Base class disposable implementation.</Title>
      <Shortcut>ddisp</Shortcut>
      <Description>
        Code snippet to create a scheleton implementation of the
        IDisposable pattern	for a derived class.
      </Description>
      <Author>Stefano Ricciardi</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>DerivedClassName</ID>
          <ToolTip>Name of the derived class.</ToolTip>
          <Default>Derived</Default>
        </Literal>
        <Literal>
          <ID>BaseClassName</ID>
          <ToolTip>Name of the base class.</ToolTip>
          <Default>Base</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
  public class $DerivedClassName$: $BaseClassName$
  {
      private bool _disposed = false;

      protected override void Dispose(bool disposing)
      {
          if (!_disposed)
          {
              if (disposing)
              {
                  // Release managed resources.
              }
              // Release unmanaged resources.
              // Set large fields to null.
              // Call Dispose on your base class.

              _disposed = true;
          }

          base.Dispose(disposing);
      }
      // The derived class does not have a Finalize method
      // or a Dispose method without parameters because it inherits
      // them from the base class.
  }
]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Go to Part 1

Controlling the Life Cycle of your Objects

In the previous post we did not concern ourselves with the lifecycle of the object returned from Ninject kernel. Ninject provides the following 4 built-in lifecycles (scopes):

1. Transient (default)
2. Singleton (only one instance)
3. Thread (one instance per thread)
4. Request (one instance per web request).

You can create custom scopes if needed.

Singleton:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
        .To<TaxCalculator>()
        .InSingletonScope()
        .WithConstructorArgument("rate", .2M);

    var tc1 = kernel.Get<ITaxCalculator>();
    var tc2 = kernel.Get<ITaxCalculator>();

    Assert.Same(tc1, tc2);
}

Transient:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
        .To<TaxCalculator>()
        .InTransientScope()
        .WithConstructorArgument("rate", .2M);

        var tc1 = kernel.Get<ITaxCalculator>();
        var tc2 = kernel.Get<ITaxCalculator>();

        Assert.NotSame(tc1, tc2);
}

More Details on Injection Patterns

With Ninject you can inject:

1. Constructor parameters
2. Properties
3. Methods

Before considering each one in turn, we just need to introduce the [Inject] attribute which may be used to tag constructors, properties and methods requiring injection. Obviously, by tagging constructors, properties or methods, your objects cease to be POCOs.

Constructor Injection

We have already seen an example of constructor injection in Part I when the kernel auto-magically injected an implementation of ITaxCalculator to the Sale Area constructor. In that case, even if we didn't tag the constructor with the [Inject] attribute, the kernel was able to perform the required binding. How?

That was actually a special case: when there is only one constructor available, the tagging is not needed. On the other hand, if there's more than one constructor defined, then then kernel can inject a dependency to only one constructor that needs to have the [Inject] attribute:

public class Sale3
{
    private readonly ITaxCalculator taxCalculator;

    public Sale3() { }

    [Inject]
    public Sale3(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    // other stuff
}

Properties Injection

Instead of passing in the dependencies through the constructor, you can also inject them as properties. Injecting properties is pretty straightforward:

public class Sale2
{
    [Inject]
    public ITaxCalculator TaxCalculator { get; set; } 

    // implicit default constructor and other stuff... 

    public decimal GetTotal()
    {
        decimal total = 0M;
        foreach (var item in lineItems)
        {
            total += TaxCalculator.CalculateTax(item.TotalPrice)
                    + item.TotalPrice;
        } 

        return total;
    }
}

Usage (note that we never explicitely set the TaxCalculator):

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
                  .To<TaxcCalculator>()
                  .WithConstructorArgument("rate", .2M);

    var lineItem1 = new SaleLineItem("Gone with the wind", 10M, 1);
    var lineItem2 = new SaleLineItem("Casablanca", 5M, 2);

    var sale = kernel.Get<Sale2>(); // property injection!
    sale.AddItem(lineItem1);
    sale.AddItem(lineItem2);

    Assert.Equal(24M, sale.GetTotal());
}

There's an important caveat: if you have 2 or more properties injected, the order in which each dependency is injected is not predictable. This might complicate your design, if those dependencies are coupled somehow (e.g. dependency A needs dependency B). For this kind of situations, constructor or method injection is usually preferred.

Methods Injection

Finally, it’s also possible to tag methods for injection. As with constructor parameters, it’s possible to inject more than one value at once.

public class Sale4
{
    private ITaxCalculator taxCalculator;

    // other stuff

    // method injection, will be called by the kernel
    [Inject]
    public void SetTaxCalculator(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    public decimal GetTotal()
    {
        decimal total = 0M;
        foreach (var item in lineItems)
        {
            total += taxCalculator.CalculateTax(item.TotalPrice)
                  + item.TotalPrice;
        }

        return total;
    }
}

Usage (note that we never explicitely call the SetTaxCalculator):

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);

    var lineItem1 = new SaleLineItem("Gone with the wind", 10M, 1);
    var lineItem2 = new SaleLineItem("Casablanca", 5M, 2);

    var sale = kernel.Get<Sale4>(); // method injection!
    sale.AddItem(lineItem1);
    sale.AddItem(lineItem2);

    Assert.Equal(24M, sale.GetTotal());
}

Go to Part 1

What Is Ninject

There are several Inversion of Control (IoC) containers for .NET to pick from (such as Castle Windsor, Structure Map and Microsoft Unity, just to name just a few).  Ninject is one of the newest entries in the arena, but it’s now sufficiently stable at version 2.0.

Ninject tries to focus on “simplicity and ease of use”, removing features that are not deemed necessary (to the point that XML configuration is not offered out-of-the box).

In this and following posts we’ll explore some example of how to use Ninject. I assume that you are somehow familiar with the basic concepts of Inversion of Control and Dependency Injection; if that’s not the case, you should consider having a look at this wikipedia entry (better yet, take some time and read Martin Fowler famous post on the subject).  

Setup

Installing Ninject is quite easy: you simply download the pre-built DLLs it from here. Since Ninject is open source, you can also get the sources from github and build it on your own.

On my Windows machine, I have copied the DLLs on C:\Ninject.

Getting your Feet Wet With Ninject

Once you have Ninject DLLs somewhere on your hard-drive, in order to get started you only need to reference them (typically you only need to reference NInject.dll ). As we said, no XML configuration is required.

Let’s see a few basic examples (the complete source code with unit tests I present in this series are available on github).

"Hello, Ninject”

Suppose we have a fairly simple service to calculate the taxes for a given amount, defined in an ITaxCalculator interface:

decimal CalculateTax(decimal gross);

and a trivial implementation TaxCalculator as follows:

public class TaxCalculator : ITaxCalculator
{
    private readonly decimal _rate;

    public TaxCalculator(decimal rate)
    {
        _rate = rate;
    }

    public decimal CalculateTax(decimal amount)
    {
        return Math.Round(_rate * amount, 2);
    }
}

Now, one or more classes might need to use an ITaxCalculator implementation to fulfill their responsibility (such as calculating the total price for a shopping cart). We can say that an implementation of ITaxCalculator is a dependency to them.

Like many IoC containers, Ninject uses a central object (which it calls the kernel) to provide concrete implementations of dependencies at run-time. The Standard Kernel is the default implementation of such an object. Let's see it in action:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);

    var tc = kernel.Get<ITaxCalculator>();
    Assert.Equal(20M, tc.CalculateTax(100M));
}

As you can see, through a fluent interface we are instructing the kernel how to bind (resolve) requests for a ITaxCalculator to a TaxCalculator class (a concrete implementation), passing to its constructor a given tax rate (20% in this case).

The example continues showing how a client can retrieve an implementation of the service through the kernel (via the Get() method) and use it.

Some Magic

You might argue that the little example above is far from impressing. So let’s now see Ninject performing something more clever.

Suppose we have a Sale class modeling a ongoing transaction on a ecommerce site. Such a class in our example depends on a ITaxCalculatorto compute the final price of the shopping cart.

public class Sale
{
    private readonly ITaxCalculator taxCalculator;

    public Sale(ITaxCalculator taxCalculator)
    {
        this.taxCalculator = taxCalculator;
    }

    // more stuff....

    public decimal GetTotal()
    {
	// use the tax calculator to calculate the total
    }
}

We might create the sale in the obvious way, based on the preceding example:

kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);
var sale = new Sale(kernel.Get<ITaxCalculator>());>

More interestingly, it's possible to let Ninject to find out how a Sale should be built based on the binding information it has received:

kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);
var sale = kernel.Get<Sale>();

Ninject is smart enough to build a Sale class for us taking care of fulfilling the dependencies behind the scenes. This an example of autowiring, a most convenient feature of many IoC containers.

Go to Part 2

2011 brings us yet another Project Euler problem to tackle: this time is Problem 18, one of the most interesting that I've solved so far:

By starting at the top of the triangle below and moving to adjacent numbers on the row below, the maximum total from top to bottom is 23.

3
7 4
2 4 6
8 5 9 3

That is, 3 + 7 + 4 + 9 = 23.

Find the maximum total from top to bottom of the triangle below:

75
95 64
17 47 82
18 35 87 10
20 04 82 47 65
19 01 23 75 03 34
88 02 77 73 07 63 67
99 65 04 28 06 16 70 92
41 41 26 56 83 40 80 70 33
41 48 72 33 47 32 37 16 94 29
53 71 44 65 25 43 91 52 97 51 14
70 11 33 28 77 73 17 78 39 68 17 57
91 71 52 38 17 14 91 43 58 50 27 29 48
63 66 04 68 89 53 67 30 73 16 69 87 40 31
04 62 98 27 23 09 70 98 73 93 38 53 60 04 23

NOTE: As there are only 16384 routes, it is possible to solve this problem by trying every route. However, Problem 67, is the same challenge with a triangle containing one-hundred rows; it cannot be solved by brute force, and requires a clever method! ;o)

Analysis

This problem is easily solved resorting to dynamic programming, which we can loosely describe as decomposing the overall problem into easier sub-problems and combining their solutions to find the final answer.

In our case, if we consider the number associated with each node of the triangle as a cost, the overall problem can be expressed as finding the path with maximum cost from the upper vertex to the bottom row. A generic sub-problem would be the cost to reach the bottom row from a generic node at position i,j.

Given the cost of passing through a given node and the cost of reaching the bottom row from that particular node, we can define the following truth:

or, in other words, from each node i,j the cost of reaching the bottom is equal to the cost of the node itself plus the maximum path between one of the two adjacent nodes from the row below.

Let's confirm why this is the case with the help of the following figure: consider for example the first node from the left in the fourteenth (last-but-one) row (having cost 63): from there you can move to the bottom either going to node 04 or node 62. Clearly, if we want to pick the highest cost, we need to pick 62 (and we mark this choice with a grey line). The overall cost to reach the bottom from that node is thus 63 + max (04, 62) = 125.

Let’s consider now the second node from that row (66). From there, we have to choose between node 62 and 98: the highest cost path from there is thus 66 + max(62, 98) = 164. We can continue for all the nodes in the row to find the highest cost path from each node; the solution to such sub-problems is indicated in gray close to each node.

Having solved all sub-problems for row 14, we can now consider the row immediately above. In the following figure, I have replaced row 14 with the solutions of the sub-problems that we had just solved; the row above is row 13. Please note how we don’t care about row 15 anymore: its contribution to the overall problem is already captured in each sub-problems’ solution for row 14! Hence, we proceed in a similar way to solve the sub-problems for the row 13 just as we did for row 14:

We continue to follow a similar pattern moving upwards row after row, until we reach the tip of the triangle, always considering two rows at a time.

Solution

#light

let a = Array2D.zeroCreate<int> 15 15

a.[0,0] <- 75
a.[1,0] <- 95
a.[1,1] <- 64
a.[2,0] <- 17
a.[2,1] <- 47
a.[2,2] <- 82
a.[3,0] <- 18
// other initializations omitted for clarity
// full listing available on Github
// (https://github.com/stefanoric/YAPEFSHARP)
a.[14,10] <- 38
a.[14,11] <- 53
a.[14,12] <- 60
a.[14,13] <- 04
a.[14,14] <- 23 

let costs = Array2D.zeroCreate<int> 15 15

// costs for bottom row is the same as bottom row values
Array2D.blit a 14 0 costs 14 0 1 15 |> ignore

let max a b = if a > b then a else b

for i in 13 .. -1 .. 0 do
    for j in 0 .. i do
        costs.[i,j] <- a.[i,j] + max costs.[i+1,j] costs.[i+1, j+1]

let result () =
    costs.[0,0]

Most of the code for this solution is needed just to initialize the two dimensional array containing the triangle. For reading convenience, I have skipped most of the uninteresting rows, but you can find the complete solution on Github.

So, we have a matrix (2D array) for the cost of each nodes and another matrix for the solutions of the sub-problems associated to each node. Trivially, the costs and the solutions coincide for the bottom row (note the handy Array2D.blit function to copy a whole row from one matrix to the other).

Then, with a loop we move backward from the last-but-one row up to the tip of the triangle calculating the sub-problems solutions as explained above.

Project Euler problem 17 turned out to be quite an easy one.

If the numbers 1 to 5 are written out in words: one, two, three, four, five, then there are 3 + 3 + 5 + 4 + 4 = 19 letters used in total.

If all the numbers from 1 to 1000 (one thousand) inclusive were written out in words, how many letters would be used?

NOTE: Do not count spaces or hyphens. For example, 342 (three hundred and forty-two) contains 23 letters and 115 (one hundred and fifteen) contains 20 letters. The use of "and" when writing out numbers is in compliance with British usage.

Solution

The solution this time is almost trivial:

• "Zero" is considered to have 0 length (it will be obvious later on why this is the case)
• Numbers from 1 to 19 have their own unique names (i.e. they are not composed by putting together more words)
• Numbers from 20 to 99 are combined putting together a word like "thirty" and a number from 0 to 9. If the number is zero, we don't add anything (we don't say "twenty and zero")
• Numbers from 100 to 999 are combined putting together a words like "two hundred and" plus a number from 0 to 99 composed as explained above. Exact multiples of 100 are exception in that they don't have another trailing number (again, we don't say "two hundred and zero").

#light

let thousand    = "oneThousand"
let hundred     = "hundred"
let hundred_and = "hundredAnd"

let zero_to_nine = new System.Collections.Generic.Dictionary<int, string="">()
zero_to_nine.[0] <- ""
zero_to_nine.[1] <- "one"
zero_to_nine.[2] <- "two"
zero_to_nine.[3] <- "three"
zero_to_nine.[4] <- "four"
zero_to_nine.[5] <- "five"
zero_to_nine.[6] <- "six"
zero_to_nine.[7] <- "seven"
zero_to_nine.[8] <- "eight"
zero_to_nine.[9] <- "nine"

let ten_to_nineteen =  new System.Collections.Generic.Dictionary<int, string="">()
ten_to_nineteen.[10] <- "ten"
ten_to_nineteen.[11] <- "eleven"
ten_to_nineteen.[12] <- "twelve"
ten_to_nineteen.[13] <- "thirteen"
ten_to_nineteen.[14] <- "fourteen"
ten_to_nineteen.[15] <- "fifteen"
ten_to_nineteen.[16] <- "sixteen"
ten_to_nineteen.[17] <- "seventeen"
ten_to_nineteen.[18] <- "eighteen"
ten_to_nineteen.[19] <- "nineteen"

let twenty_to_ninety = new System.Collections.Generic.Dictionary<int, string="">()
twenty_to_ninety.[20] <- "twenty"
twenty_to_ninety.[30] <- "thirty"
twenty_to_ninety.[40] <- "forty"
twenty_to_ninety.[50] <- "fifty"
twenty_to_ninety.[60] <- "sixty"
twenty_to_ninety.[70] <- "seventy"
twenty_to_ninety.[80] <- "eighty"
twenty_to_ninety.[90] <- "ninety"

let len s = String.length s

let calculate_letters_under_one_hundred n =
    match n with
        | x when x < 10 -> len zero_to_nine.[x]
        | x when x < 20 -> len ten_to_nineteen.[x]
        | x when x < 100 -> len twenty_to_ninety.[((x / 10) * 10)] + len zero_to_nine.[(x % 10)]
        | _ -> failwith "Number is too big!"

let calculate_letters n =
    match n with
        | x when x < 100 -> calculate_letters_under_one_hundred x
        | x when ((x < 1000) && (x % 100 = 0)) -> len zero_to_nine.[(x / 100)] + len hundred
        | x when x < 1000 -> len zero_to_nine.[(x / 100)] + len hundred_and +  calculate_letters_under_one_hundred (x % 100)
        | 1000 -> len thousand
        | _ -> failwith "Numer is too big!"

let all_letters_up_to n =
    List.sumBy (fun i -> calculate_letters i) [1..n]

It’s time for another Project Euler exercise. This time around it’s problem 16:

2¹⁵ = 32768 and the sum of its digits is 3 + 2 + 7 + 6 + 8 = 26.

What is the sum of the digits of the number 2¹⁰⁰⁰?

Analysis

I have tried to found an elegant way to solve this problem at a mathematical level, but I couldn't gain any insight relating powers of 2 to their representation in base 10 (I'd love to know if such a thing exists). Therefore I resorted to solve this problem with brute force.

Luckily F# (and now all other .NET 4.0 cousin languages) sports the BigInteger numeric type which helps tackling such huge numbers.

There are basically two approaches to solve this problem:

• Transform the result of exponentiation into a string and iterate through the string adding up all the individual digits, or
• Do without strings, and decompose the big number into the individual digits on my own.

I have decided to take the second route because it seemed like a more interesting exercise (the first approach could probably lead to a one-liner). ^[1].

Let’s consider a generic number n and consider how we can describe it as a sum of powers of 10:

For example

and k = 2, d₀ = 3, d₁ = 2, and d₂ = 4

So, given a generic number n, we need to find the highest power of ten ( k ) such that

(logarithms will help us there). After k is found, we can start diving n by 10^k to find d_k and use the reminder of the division to calculate d_k-1 and so forth until we reach d₀.

Solution

#light

open System
open System.Numerics

let rec decompose_rec n power_of_ten accu =
    match power_of_ten with
        | i when i = 1I -> accu @ [n]
        |_ ->
            let d = n / power_of_ten
            let digits = accu @ [d]
            decompose_rec (n - (d * power_of_ten)) (power_of_ten / 10I) digits

let decompose n =
    let power = floor (log10 (float n))
    let initial_power_of_ten = BigInteger.Pow(10I, int32 power)
    decompose_rec n initial_power_of_ten []

let sum_digits n =
    decompose n |> List.sum

1. ^[1] A recruiter for a very big company once asked me something very similar during an interview as a coding exercise ↩

With Project Euler Problem 15 we approach the fascinating world of graphs (but, as we shall see, only in a very tangential fashion):

Starting in the top left corner of a 2×2 grid, there are 6 routes (without backtracking) to the bottom right corner.

How many routes are there through a 20×20 grid?

Analysis

With pen and paper the fact that a 2×2 grid has 6 possible routes can be easily confirmed. However, as soon as the grid size grows, it's simply not practical to start drawing all the possible ways to reach the lowest right corner from the top left one.

In order to find a general solution, it helps trying a dynamic programming approach: we first try to solve a smaller problem and then combine the solutions of more sub-problems to find the overall answer.

The smallest problem that we can consider is the number of possible routes in a 1×1 grid. What could be simpler? Considering all the three possible starting corners of such a grid we can see that:

• From both the bottom-left and the top-right corner there's only one possible route to the destination.
• From the top-left corner there are trivially two possible routes.

In the picture below, I have marked for each corners the number of possible routes to the destination for the 1×1 grid:

We can now consider the bigger 2×2 grid enclosing the smaller 1×1 grid representing the sub-problem we solved earlier:

• Both points on the outer sides of the grid have only one possible route to the destination. In fact, from there you can only proceed along the edge. So, we mark both of these points with 1.
• Let’s now consider the point immediately above the bottom left one on the grid: from this point we can either move down (to the point that we just marked with a “1”) or right to the point of the 1×1 grid that we had marked with a “2” previously. Hence, from this point we have 1 possible route if we decide to go down or 2 possible routes if we decide to go right: that makes 3 possible routes that can lead from this point to the destination.

We can generalize and deduce that for each point in the grid, the number of possible routes to the destination is equal to the sum of the routes available from the point immediately down and the point immediately right (points on the outer edge having only 1 possible route). This is the key to solve this problem for any kind of grid.

So, we have informally demonstrated the result for the 2×2 grid:

And similarly we can resolve the problem for a 3×3 grid:

Now, if you look closely at the patterns of the possible routes for each point in the grid, you may recognize what in Italy we call Il triangolo di Tartaglia (Tartaglia’s Triangle), which everywhere else in the world is most probably known as Pascal's Triangle:

(note that the triangle obviously continues ad infinitum).

The solution for a square grid of any size lies in the vertical diagonal (if you excuse the quasi-oxymoron), that is 1, 2, 6, 20, etc…. If we start counting rows from the top, first row being row 0, second row being row 1 and so on, and columns from the left also starting from 0, we can see that for a square grid of size n, the number of routes is given by the item in the n column within the 2*n row.

Now, it would be trivial, if somehow boring, to solve the problem for a 20×20 grid using a spreadsheet. All you have to do is to create the 20 x 2 = 40 rows of the Pascal triangle (with some copy and paste of the right formula for each cell), and pick the 20^th element from that road.

However, you don't actually have to create the whole triangle: the values of each row can be calculated using they binomial expansion: for a given row r, the value at column c is given by the following formula:

Perhaps more interestingly, you can calculate the same value without resorting to the factorial by using the following recursive formula (where r' is the row number +1 and  c is the column index):

Solution

So, after all this analysis, the solution comes up to be quite simple and maybe not that interesting per se. The recursive formula to calculate the values from the triangle's rows fits naturally the F# pattern matching:

#light

let rec pascal_item row_plus_one column =
    match column with
    | 0L -> 1L
    | _-> (row_plus_one-column) * (pascal_item row_plus_one (column-1L)) / column

let number_of_routes grid_size =
    pascal_item (int64(2*grid_size + 1)) (int64 grid_size)

Project Euler Problem 14 introduces the fascinating Collatz Conjecture:

Take any natural number n. If n is even, divide it by 2 to get n / 2, if n is odd multiply it by 3 and add 1 to obtain 3n + 1. Repeat the process indefinitely. The conjecture is that no matter what number you start with, you will always eventually reach 1.

The Euler problem to be resolved is phrased as follows:

The following iterative sequence is defined for the set of positive integers:

n –> n/2 (n is even)
n –> 3n + 1 (n is odd)

Using the rule above and starting with 13, we generate the following sequence:

13 –> 40 –> 20 –> 10 –> 5 –> 16 –> 8 –>  4 –> 2 –>  1

It can be seen that this sequence (starting at 13 and finishing at 1) contains 10 terms. Although it has not been proved yet (Collatz Problem), it is thought that all starting numbers finish at 1.

Which starting number, under one million, produces the longest chain?

As with many other Project Euler problems, we are requested to generate a sequence (in this case a sequence of “Collatz sequences”) and to single out one item matching a certain criteria. In this particular case, we need to create Collatz sequences for all numbers under 1 million and find out the longest one.

Solution

The basic algorithm has the following shape:

let is_odd x =
    x % 2L = 1L

let rec naive_sequence n (partial:int64 list) =
    match n with
        | 1L -> partial @ [1L]
        | x when is_odd x -> naive_sequence ((3L*x) + 1L) (partial @ [n])
        |_ -> naive_sequence (n/2L) (partial @ [n])

Using this recursive function, we could easily generate Collatz sequences for arbitrarily large numbers. But the performance would soon degrade when we start building sequence for numbers bigger than about 10 thousands.

In the process of generating all the sequences from 1 to 1 million, however, it’s easy to see that for each sequence that we build, there are a lot of subsequences that are identical, which are being calculated over and over.

Consider for example the two sequences having 5 and 24 as starting numbers respectively:

5 –> 16 –> 8 –> 4 –> 2 –> 1

24 –> 12 –> 6 –> 3 –> 10 –> 5 –> 16 –> 8 –> 4 –> 2 –> 1

As you can see, after a few iterations the sequence starting from 24 converges to the sequence starting at 5, which we have already calculated! (see this image from Wikipedia for a pictorial representation of this behavior)

As you would have guessed by now, the key to solve this problem is precisely caching the subsequences that are being calculated, so that the partial results can be reused for subsequent iterations.

So, with these considerations in mind, we can have a look at the final solution:

#light

open System.Collections.Generic

let is_odd x =
    x % 2L = 1L

let rec collatz_sequence n (partial:int64 list) (cache: IDictionary<int64, int64 list>) =
    if cache.ContainsKey(n) then
        let result = partial @ cache.[n]
        let sequence_starter = List.head result
        if not(cache.ContainsKey(sequence_starter)) then
            cache.Add(sequence_starter, result) |> ignore
        result
    else
        match n with
        | 1L ->
            let result = partial @ [1L]
            let sequence_starter = List.head result
            cache.Add(sequence_starter, result) |> ignore
            result
        | n when is_odd n -> collatz_sequence ((3L*n) + 1L) (partial @ [n]) cache
        | _ -> collatz_sequence (n/2L) (partial @ [n]) cache

let sequence_cache = new Dictionary<int64, int64 list>()

let calculate_sequence n =
    collatz_sequence n [] sequence_cache

let max_sequence_lengths (max:int64) =
    let all_sequences = [for i in 1L..max -> calculate_sequence i]
    let lengths = List.map List.length all_sequences
    let max = List.max lengths
    let max_index = List.findIndex (fun (x:int64 list) -> x.Length = max) all_sequences
    max_index + 1L

As you can see, the basic pattern of the algorithm is still the same. However, we have added a cache to store partial results which dramatically improve the performances (this version resolve the problem on my laptop in about 7 seconds).

The last function max_sequence_lengths is the main loop generating all the sequences, calculating the lengths and picking the sequence with the highest length.

Caching partial results is a common theme in functional programming, and is called memoization. The example provided above is not one of the cleanest examples of memoization. It turns out that combining memoization and tail recursion is a tricky problem.