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

Find the maximum total from top to bottom of the given triangle.The 18th problem involves finding the optimal route from top to bottom in a pyramid  of 15 rows. It is possible to solve this using a brute force algorithm, testing every possible solution. Problem no. 67 is the exact same problem, but this time with a pyramid of 100 rows. The problem text includes a little warning, stating that a brute force approach would take a couple of billion years to complete…

I remember back when I was a kid, I used to solve labyrinths like ‘help the little mouse find its cheese’, I always started with the cheese. It was always easier to find the way back to the mouse. I would guess that the same would go for this one. If we can solve the problem from the bottom instead of the top, it should be easier to choose the right path.

So, lets start at the bottom of the four-row pyramid. We have four numbers: 8 5 9 and 3. Even though 9 is the larger one, we have no idea if 9 is where we want to end up, since the numbers leading to the first number, 8, could be higher. Imagine the third row to be 9 2 and 3. The only way down to the 8 would be through the 9 in the third row, and down to the 9 we could have come through the 2 or the 3. 8 + 9 = 17 looks like a much better total then 2 + 9 = 11 or 3 + 9 = 12. Moving up one more row, to the second row, lets imagine the numbers 1 and 7. If we went for the  8 + 9 combination, we would only have one choice up to the second row, making a total of 8 + 9 + 1 = 18. If we went for the 9 + 3 combination, the 7  would be our only choice, giving a total of 19. From the 2 in the third row, we could reach either one, but would not get a higher total any way, so lets just drop that option all together.

Now, what seemed like a great path, starting with 8 + 9, turned out to be beaten by another option higher in the pyramid. How could we predict that? We couldn’t. So what would make going from bottom to top a better solution then from the top to bottom? Well, we managed to throw away a couple of options. We never payed either the 5 or the 3 in the bottom row any attention. From the 5, we could have gone up through 9 or 2 in the third row, but if we have come to the 9, why should we go down to the 5 when we know that the 8 would give a better total? Same goes for the 2. Why go down to 5 for a total of 7 when we can go down to 9 for a total of 11? And that is the clue to solve this problem. We need to know what would give the greater total, left or right.

OK. So lets start at the bottom again, this time, with some of the numbers from the given pyramid in problem 18:

If we start with the 63, we could either go down to 04 or 62. Obviously, knowing this is the last row, we would go for 62 and a total of 125. From 66 we can go to 62 or 98. Once again, we would take the right path for a total of 164. From 04, we would pick 98, from 68, 27 or 89, 23 and so on.

Now we can easily know where we want to go next from the 14th row. Lets add the 13th row:

Since we already know the best path from each number in the 14th row down to the 15th, we can treat the trip from the 13th row down to the 14th in the same way. From the first number, 91, we know we can choose between 63 and 66. We know that if we choose 63, we can reach a maximum of 91 + 125 by going right from 63. If we choose 66, we know that we can reach a total of 91 + 128 by going left. From the second number, 71, we can go left through 66, or right through 04. By choosing right, we can reach a maximum of 71 + 102, so clearly left would be a better choice, which gives us 71 + 164.

Do you see the pattern? I think we are ready for some code! I started out with a NumberPiramid-class. It has a method for adding a row of numbers, and a method returning the calculated maximum total.

@interface NumberPiramid : NSObject {
  NSMutableArray *rows;
}

-(void)addRow:(NSString *)stringWithNumbers;
-(int)numberOfRows;
-(int)maximumTotal;

@end

The method addRow:stringWithNumbers takes all numbers for one row as a string separated by spaces. The string is split into an array of Number, a class able to hold both the number itself, and the totals for the left and right side.

-(void)addRow:(NSString *)stringWithNumbers;
{
  NSArray *numbers = [stringWithNumbers componentsSeparatedByString:@" "];
  NSMutableArray *row = [[NSMutableArray alloc] initWithCapacity:[numbers count]];
  for (NSString *number in numbers) {
    Number *n = [[Number alloc] initWithNumber:number];
    [row addObject:n];
    [n release];
  }
  [rows addObject:row];
  [row release];
}

So now, we have an array of arrays that we can use to find our total. The method maximumTotal will first traverse the arrays bottom up, adding the numbers one by one, always keeping the larger option. I have given the Number class a convenience method maxSum, that returns the larger number of leftSum and rightSum. When we have reached the top, we have our total.

-(int)maximumTotal;
{
  NSArray *row = [rows lastObject];
  NSArray *prevRow;
  for (int r = [self numberOfRows] - 2; r >= 0; r--) {
    prevRow = row;
    row = [rows objectAtIndex:r];
    for (int n = 0; n < [row count]; n++) {
      Number *number = [row objectAtIndex:n]>
      Number *left = [prevRow objectAtIndex:n];
      Number *right = [prevRow objectAtIndex:n + 1];
      number.leftSum = number.number + [left maxSum];
      number.rightSum = number.number + [right maxSum];
    }
  }
  Number *top = [row objectAtIndex:0];
  return [top maxSum];
}

And thats all there is. Problem 67 is the exact same problem, but with a larger pyramid. The numbers are given in a textfile, so we need a new method that can read the textfile line by line. Actually, I found it easier to just read the whole file into a string, using NSString initWithContentsOfFile:filename. I then split this string into lines with the same method I use to split a single row.

As before, the code is available through svn. There is a delphi implementation too.

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?

Well, lets see, then…

We would need a class that can convert an integer into written words. I will call it WrittenNumber, and give it a class method +(NSString *)fromInt:(int) to do the work.

@interface WrittenNumber : NSObject {
}
+(NSString *) fromInt:(int)number;
@end

Now, that I got my basic interface in place, I tried it out with the most basic test:

- (void)testSingleDigitOne {
    GHAssertEqualStrings([WrittenNumber fromInt:1], @"one", nil);
}

As expected, it failed :

euler17/testSingleDigitOne ✘ 0.00s

	Name: GHTestFailureException
	File: /../euler17.m
	Line: 40
	Reason: '' should be equal to 'one'.

I will not take you through every single step I took, including returning ‘one’, writing a new test and realize that returning ‘one’ didn’t work for other cases and so on… What we need, is to identify every word that we need to build up every number from one to 1000. Up to nineteen, there are all unique words. From there, most written numbers are combined by two or more words. So I put these words into a couple of static arrays:

static NSString * simpleNumbers[] = {
    @"", @"one", @"two", @"three", @"four", @"five", @"six", @"seven", @"eight", @"nine",
    @"ten", @"eleven", @"twelve", @"thirteen", @"fourteen", @"fifteen", @"sixteen", @"seventeen", @"eighteen", @"nineteen"
}; 

static NSString *tens[] = {
    @"", @"", @"twenty", @"thirty", @"forty", @"fifty", @"sixty", @"seventy", @"eighty", @"ninety"
};

I have padded the ‘tens’-array to make indexing a little easier. tens[2] = “twenty”, tens[8] = “eighty” and so on. Now, the algorithm that I ended  up with, was to start with the larger part of the number, converting it into text, and then handle the rest in the same way. Peele away the larger part, convert it to text, and repeat.

+(NSString *) processSimpleNumbers:(int)number
{
    return simpleNumbers[number];
}

+(NSString *) processTens:(int)number
{
    if (number < 20) {
        return [self processSimpleNumbers:number];
    }

    int div = number / 10;
    int rest = number % 10;
    NSString *tmp = tens[div];
    if (rest > 0){
        return [NSString stringWithFormat:@"%@-%@", tmp, [self processSimpleNumbers:rest]];
    } else{
        return tmp;
    }
}

+(NSString *) processHundreds:(int)number;
{
    if (number < 100) {
        return [self processTens:number];
    }

    int div = number / 100;
    int rest = number % 100;
    NSString *tmp = [NSString stringWithFormat:@"%@ hundred", simpleNumbers[div]];
    if (rest > 0){
        return [NSString stringWithFormat:@"%@ and %@", tmp, [self processTens:rest] ];
    } else {
        return tmp;
    }
}

+(NSString *) processThousands:(int)number;
{
    if (number < 1000){
        return [self processHundreds:number];
    }

    int div = number / 1000;
    int rest = number % 1000;

    NSString *tmp = [NSString stringWithFormat:@"%@ thousand", [self processHundreds:div]];

    if (rest > 0) {
        if (rest < 100) {
            return [NSString stringWithFormat:@"%@ and %@", tmp, [self processTens:rest]];
        } else {
            return [NSString stringWithFormat:@"%@ %@", tmp, [self processHundreds:rest]];
        }
    } else{
        return tmp;
    }
}

+(NSString *) fromInt:(int)number
{
    return [self processThousands:number];
}

I’m sure there are prettier ways of solving this, but it works. The remaining task, is trivial. Convert each number and accumulate the length of the strings after removing hyphens and spaces. Of cause, we could get rid of these characters right away by not returning them in the first place, but then again, I did not…

I have uploaded the source to my svn repository if you want to take a look. You’ll find the WrittenNumber class in the iPhone/src folder, and the unittests in the iPhone/tests folder.

The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.

Find the sum of all the primes below two million.

Soon, but not yet…

Using the same generator from problem 7, I go for an easy, but slow, solution for this one. There is one thing, though. Our generator generates up to the nth prime, but in this problem, we need to find every prime below 2000000. Already decided not to make a new prime generator, we cheat by asking it generate a lot of primes, and then jump out as soon as we hit a prime to big.

sum := 0;for prime in PrimeGenerator(500000) do
begin
  if prime >= 2000000 then
    break;
  sum := sum + prime;
end;

I choose to generate 500000 primes, pretty sure one prime out of four should be enough.

And that’s it – it’s all there at http://svn.vi-kan.net/euler.

A Pythagorean triplet is a set of three natural numbers, a < b < c, for which,

a² + b² = c²

For example, 3² + 4² = 9 + 16 = 25 = 5².

There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.

Both of us agreed there had to be some kind of mathematical formula for this kind of problem. The problem, though, was that non of us new this formula, and there wasn’t that many math books in the car that day… So instead of trying to guess the magic formula, we tried to optimize the search for the right numbers.

We could put three for loops inside each other, scanning the numbers from 1 to 1000 for each. Trying 1 + 1 + 1 as a possible solution isn’t that clever, though. Neither is the combination 1000 + 1000 + 1000.

Let’s take a look at the maximum possible values for a, b and c. The fact that a < b < c makes this kind of easy.  Since all three numbers must be positive, c can’t be larger than 997 to make room for a = 1 and b = 2. The number b can’t be larger than 499, which makes room for a = 1 and c = 500. And finally, a can’t be larger than 332, which makes room for b = 333 and c = 335.

    for a := 1 to 332 do
      for b := a+1 to 498 do
        for c := b+1 to 998 do
        begin
          ...
        end;

Now, the test it self should be easy:

if (a + b + c = 1000) and (a*a + b*b = c*c) then
  ...

We can do one more easy optimization. I our current c makes for a larger sum than 1000, we can break out of the innermost loop. This actually saves us a lot of cycles.

        for c := b+1 to 998 do
        begin
          sum := a + b + c;
          if (sum) > 1000 then
            break;

          if (sum = 1000) and (a*a + b*b = c*c) then
          begin
            ...
          end;
        end;

And that’s it. The complete solution is available as usual. Check it out at http://svn.vi-kan.net/euler.

Find the greatest product of five consecutive digits in the 1000-digit number.

73167176531330624919225119674426574742355349194934
96983520312774506326239578318016984801869478851843
85861560789112949495459501737958331952853208805511
12540698747158523863050715693290963295227443043557
66896648950445244523161731856403098711121722383113
62229893423380308135336276614282806444486645238749
30358907296290491560440772390713810515859307960866
70172427121883998797908792274921901699720888093776
65727333001053367881220235421809751254540594752243
52584907711670556013604839586446706324415722155397
53697817977846174064955149290862569321978468622482
83972241375657056057490261407972968652414535100474
82166370484403199890008895243450658541227588666881
16427171479924442928230863465674813919123162824586
17866458359124566529476545682848912883142607690042
24219022671055626321111109370544217506941658960408
07198403850962455444362981230987879927244284909188
84580156166097919133875499200524063689912560717606
05886116467109405077541002256983155200055935729725
71636269561882670428252483600823257530420752963450

I can’t see any smart solution for this problem. A simple brute force scan through the series of digits will have to do.

I start out with the number as a string. That makes it easy to loop through digit by digit.  To make it even easier, I have made an array of five bytes that I place ‘over’ the current character. This gives me a ‘view’ of the five current digits that needs to be multiplied as bytes instead of characters.

const
  SUBJECT = '73167176531330624919225119674426574742355349 .... 57530420752963450';

type
  PFiveDigits = ^TFiveDigits;
  TFiveDigits = array[0..4] of byte;

begin
  for I := 1 to length(Subject) - 6 do
  begin
    FiveDigits := @SUBJECT[i];
  end;
end;

A character in the range 0 to 9 has byte value in the range of 48 to 57. Before we multiply the values, we have to normalize them. We can do that by subtracting 48 from each byte value.

const
  NULLCHAR = ord('0');
  ...
  present := (FiveDigits[0]-NULLCHAR) * (FiveDigits[1]-NULLCHAR) * (FiveDigits[2]-NULLCHAR) * (FiveDigits[3]-NULLCHAR) * (FiveDigits[4]-NULLCHAR);

Now we just have to keep track of the highest produced product do find the answer.

    largest := 0;
    for I := 1 to length(Subject) - 6 do
    begin
      FiveDigits := @SUBJECT[i];
      present := (FiveDigits[0]-NULLCHAR) * (FiveDigits[1]-NULLCHAR) * (FiveDigits[2]-NULLCHAR) * (FiveDigits[3]-NULLCHAR) * (FiveDigits[4]-NULLCHAR);
      if present > largest then
      begin
        largest := present;
        position := i;
      end;
    end;

As usual, you will find the code at http://svn.vi-kan.net/euler.

By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6^th prime is 13.

What is the 10001^st prime number?

Algorithms conserning primes is a large and complex field. I guess the are many different solutions to this problem, so the question will be how efficient the one that I find will be.

One thing is for sure, though. We need a way of finding primes. As far as I know, there is no formula to find the n^th prime. We have to find the first 10 000 primes first before we can find our wanted one.

A Prime Generator

I will use a enumerator-pattern for our prime generator. For that, we will need two classes. First we will need a factory-class that implements the GetEnumerator function. Then we will need the class that handles the actual enumeration.

type
  TPrimeGenerator = class
  public
    function GetCurrent: extended;
    function MoveNext: boolean;
    property Current: extended read GetCurrent;
  end;

  TPrimeGeneratorFactory = class
  public
    function GetEnumerator: TPrimeGenerator;
  end;

With this implementation, we will be allowed to write code like this:

for prime in TPrimeGeneratorFactory.Create do
begin
  ...
end;

This code would generate an awful lot of primes, though. It would be nice to give it some kind limit. We can add that to the constructor, and check in the MoveNext method if the limit is reached. We would also need some live-time management on both the factory and the generator. The generator it self can be created and destroyed by the factory, but we can also make it easier by letting the factory implement an interface. If we do, delphi will manage it’s lifetime for us.

type
  TPrimeGenerator = class
  public
    constructor Create(numberOfPrimes: integer);
    ...
  end;

  IPrimeGeneratorFactory = interface
    function GetEnumerator: TPrimeGenerator;
  end;

  TPrimeGeneratorFactory = class(TInterfacedObject, IPrimeGeneratorFactory)
  public
    constructor Create(numberOfPrimes: integer);
    destructor Destroy; override;
  end;

  function PrimeGenerator(numberOfPrimes: integer): IPrimeGeneratorFactory;

Now, we can rewrite our for … in – loop, and just get the number of primes that we want. We will know longer have any leaks either.

for prime in PrimeGenerator(10001) do
begin
  ...
end;

Finding Primes

Our generator doesn’t actually generate primes yet, though. Let’s see if we can make it do so. So how do we find primes? What is a prime? Wikipedia gives us the following definition of prime numbers:

In mathematics, a prime number (or a prime) is a natural number which has exactly two distinct natural number divisors: 1 and itself.

So if we loop through all numbers, and test if it’s possible to devide it by any other number, we should have our primes. The problem is, though, that this takes time. A lot of time. We have to find a way of shortening down the ammount of numbers we need to check. The first thing we should remove, is all even numbers. Every single even number is divisible by the number 2, so they can’t be primes. Except for the number 2 it self – it’s a prime, cause has only two divisors: 1 and itself.

Since 2 is the first prime number, it would be an easy exception to handle, and we have effectively cut shortened down possible primes to the half of what we started with.

Let’s write our FindNextPrime method:

function TPrimeGenerator.FindNextPrime(PreviousPrimeFound: extended): extended;
var
  found: boolean;
  currentNumber: extended;
begin
  currentNumber := PreviousPrimeFound;
  repeat
    if (CurrentNumber = 1) or (currentNumber = 2) then
    begin
      currentNumber := currentNumber + 1;
      result := true;
    end
    else
    begin
      currentNumber := currentNumber + 2;
      found := CheckIfPrime(currentNumber);
    end;
  until found;

  result := currentNumber;
end;

We here assume that PreviousPrimeFound equals 1 when no previous prime is found. So if the previous prime is 1 or 2, we just increment by one, knowing that both 2 and 3 is prime numbers, and signal a successfull found. If previous prime was not 1 or 2, it has to be 3 or any other odd number, so we increment by two to skip even numbers.

Let’s take a look at the CheckIfPrime( ) method. How do we check if a number is divisible by any other number? I guess we have to check:

function TPrimeGenerator.CheckIfPrime(number: integer): boolean;
var
  i: integer;
begin
  result := true;
  for i := 2 to number - 1 do
  begin
    if number mod i = 0 then
    begin
      result := false;
      break;
    end;
  end;
end;

Can you see a bottleneck here? For every number we test, there is one more number to devide. How can we optimize this?

First of all, every natural number can be expressed as a product of primes. 12 = 2 x 2 x 3, 20 = 2 x 2 x 5 and so on. So if a number is divisible by a non prime number, it should also be divisible by a prime number. So if we can find a way of just dividing by primes we would speed up things a lot.

So let’s add a list of previous found primes to the generator class, and loop through that list instead of all numbers.

function TPrimeGenerator.CheckIfPrime(number: extended): boolean;
var
  itr: DIterator;
  prevPrime: extended;
  found: boolean;
begin
  found := false;
  itr := FPrimes.start;
  while IterateOver(itr) do
  begin
    prevPrime := getExtended(itr);

    if Frac(number / prevPrime) = 0 then
    begin
      found := true;
      break;
    end;
  end;

  result := not found;
end;

This makes things a lot faster, but I think we still can gain something. In the same wikipedia article that I refered to earlier, it is sufficient to test primes smaller than the sqaure root of the number we are currently testing. So let’s add that to our loop:

function TPrimeGenerator.CheckIfPrime(number: extended): boolean;
var
  itr: DIterator;
  prevPrime: extended;
  found: boolean;
  root: extended;
begin
  root := sqrt(number);
  ...
  while IterateOver(itr) do
  begin
    prevPrime := getExtended(itr);
    if prevPRime > root then
      break;

    if ...
  end;
  ...
end;

The Solution

Just like the solution for problem 6, you can find the complete code at http://svn.vi-kan.net/euler. It gives the answer in about 40-50 ms.

The sum of the squares of the first ten natural numbers is,

1² + 2² + … + 10² = 385

The square of the sum of the first ten natural numbers is,

(1 + 2 + … + 10)² = 552 = 3025

Hence the difference between the sum of the squares of the first ten natural numbers and the square of the sum is

3025  385 = 2640.

Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.

This problem has two distinct parts. First, there is the sum of a sequence of the squared natural numbers, then there is the sum of a sequence of natural numbers, squared.

Sum of a series of squared natural numbers

The problem tells to summarize the square of the first hundred natural numbers. That gives us the following sequence:

1² + 2² + … 99² + 100²

The simplest solution would be a brute force loop like this one:

function sumSquaredNumbers( ): longword;
var
  i: integer;
begin
  result := 0;
  for i := 1 to 100 do
    result := result + (power(i, 2));
end;

That wouldn’t be much fun, though. There has to be a more general, optimized algorithm for this kind of work. First of all, we should make the function workable for any series length. That should be easy – just switch the hardcoded 100 with an given parameter:

function sumSquaredNumbers(serieslength: integer): longword;
var   i: integer;
begin
  for i := 1 to seriesLength do
    result := …
end;

But the code is still the same, though. Nothing was optimized in any way. We still have the loop, making our function linear.

Google to the rescue!

math.com have a nice section on Series Expansions, which includes a table of power summations. This table states that

n
∑	k2	= 1 + 4 + 9 + … + n2	= (1/3)n3 + (1/2)n2 + (1/6)n
k=1

Why this should be true, I honestly can’t tell, but a fast comparison to our brute force solution shows that it gives us the right numbers. That’s good enough for now:

function sumSquaredNumbers(seriesLength: integer): longword;
begin
  result := trunc(
                ((1/3) * power(seriesLength, 3))
              + ((1/2) * power(seriesLength, 2))
              + ((1/6) * seriesLength)
              );
end;

I think this is a nice solution, and a constant one as well. It doesn’t matter if the series is of length one, hundred or thousand – the computation should take the same amount of time.

Sum of a series of natural numbers, squared

This part should be a lot easier. We could start with a brute force solution to this part too, but I think we could come up with something smarter right away.

I already know of a simple optimization. If you add the first and last number in the series, you will get the same as if you add the second and next to last number:

	1	2	3	4	5	6	7	8	9	10
+	10	9	8	7	6	5	4	3	2	1
=	11	11	11	11	11	11	11	11	11	11

As you can see, every pair of numbers makes the same sum when added together. So for any given series, you can take the first and the last number and add them together, then you can multiply the sum by the length of the series, and finally divide by two.

n
∑	k	= 1 + 2 + 3 + … + n	= (1 + n) * n / 2
k=1

I know there are other solutions to this, but this one will do.

function sumSquared(seriesLength: longword): longword;
begin
  result := trunc(power(((1 + seriesLength) * seriesLength / 2), 2));
end;

The solution

Now that we have solved each of the two sub parts of the problem, I guess we’re ready to solve the main thing.

Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.

Since we know the sum of the squares, and we now the square of the sum, it’s just a matter of substract the one from the other:

function diff(serieslength: longword): longword;
begin
  result := sumSquared(serieslength) - sumSquaredNumbers(serieslength);
end;

I have uploaded my complete solution to http://svn.vi-kan.net/euler. The code also contains a simple stopwatch to time the code. This code is so simple, though, that it’s hard to get any measures.

And that’s it. Let’s see if we can solve the next one too.