As mentioned before, CouchDB provides a RESTful API. You will be sending requests over HTTP, and checking status codes for success. This makes it easy to test features, by using small utilities like HTTP Client and Curl. All GET operations should be easy enough to do through your browser, and some browsers have addons that lets you make other kind of requests too. So find a tool that suites you well, and start the expedition.

Say Hello to CouchDB

Before we start making databases and documents, you should check that the server is running. Make a simple GET request to the server to see if you get any response.

GET http://127.0.0.1:5984/

If the server is running, it will respond with a welcome message and a version number.

{"couchdb":"Welcome","version":"0.11.0"}

You can also check to see what databases allready exists on the server, by doing a GET request to /_all_dbs.

GET http://127.0.0.1:5984/_all_dbs

The resonse will be formatted as an JSON array with database names.

["business-cards","newdb","testdb"]

Databases

CouchDB exposes most everything as resources accessable by urls. This is one part of what makes it RESTful. So when you want to access one of the existing databases, you will make a GET request for the name of the database.

GET http://127.0.0.1:5984/business-cards

This request want return the complete database with all its documents. It will instead return some information about the database.

{"db_name":"business-cards", "doc_count":2, "doc_del_count":1, "update_seq":4, "purge_seq":0, "compact_running":false, "disk_size":16473, "instance_start_time":"1273129328746881", "disk_format_version":5}

As you can see, our business card database from our introduction contains two documents. It also contains one deleted document which is not purged yet.

Since the name of the database is used as an url, there has to be some constraints on what characters can be used. To make it easy to support different platforms, and avoid issues with casing, CouchDB will only allow lowercase letters in the range ‘a’ to ‘z’. It will also allow digits and the following characters: _ $ ( ) + – /

By allowing the /-character, it is possible to group different databases into namespaces, like /blog/posts and /blog/comments. It can be a little tricy to test, though. You will need to encode the / into %2F, but HTTP Client, which I use, doesn’t like that. It will encode the % into %25 and send %252F instead of %2F. I guess there is some way of escapting this, but I don’t know for sure.

So lets create our first database. I will make myself a database of geocaches. So what would be more natural then just to PUT it right there at the server?

PUT http://127.0.0.1:5984/geocaches

If the database was created as expected, we will get a positive response.

{"ok":true}

If the database name is taken, we will get an error response. The response will contain a standard HTTP status code, 412 Precondition Failed, and the body of the response will give us even more information.

{"error":"file_exists","reason":"The database could not be created, the file already exists."}

Similar, if we try to use one of the forbidden characters, we will get a 400 Bad Request with additional information on how to behave in the future.

{"error":"illegal_database_name", "reason":"Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed"}

Nice.

If you need to remove the database again, you make a…..?  Yes, a DELETE request.

DELETE http://127.0.0.1:5984/geocaches

If everything goes well, the server will respond with a happy ‘ok’, and the database with all its documents is gone. No ‘please, confirm’ or ‘are you sure’, so now you’re warned.

Documents

In the world of CouchDB, a document consists of key-value pairs. Every document needs an unique id, which is stored in the ‘_id’-key. When you create a new documet, CouchDB will provide one for you if you want it too. The id will then be in the form of a guid, a string of 32 hexadecimal values.

The id of a document will be used as part of the uri when you later want to retrieve or change your document. If the data you want to store already have a unique identification, you could use that and get more domain specific urls. Be careful though. Not every character is suitable to be part of an uri, and you would need to escape them appropriately .

Create

I want to store geocaches, and every geocache has an unique name consisting of letters and digits. I will therefore use this name as the id for my document. Heres my first geocache:

{
   "url": "http://www.geocaching.com/seek/cache_details.aspx?guid=ab5cc0fb-4f0f-4809-98a1-60697daa5e08",
   "sym": "Geocache Found",
   "lon": 18.973967,
   "lat": 69.696533,
   "urlname": "Nesten hjemme",
   "type": "Geocache|Traditional Cache",
   "time": "2009-06-07T07:00:00Z",
   "name": "GC1TCJR",
   "desc": "Nesten hjemme by Geo_Raiders, Traditional Cache (2/1.5)"
}

I want to store this as an document with the key GC1TCJR in the database geocaches, so lets PUT it up there.

PUT http://127.0.0.1:5984/geocaches/GC1TCJR
{“url”:”http://www.geocaching.com/seek/cache_details.aspx?guid=……."}

If everything goes by the plan, CouchDB will responde with a 201 Created status, together with something like this:

{"ok":true,"id":"GC1TCJR","rev":"1-f70033bafd9d72e174cecb67f58b2e4f"}

If a document with the same id already exists, you will get a 409 Conflict status and the following error:

{"error":"conflict","reason":"Document update conflict."}

You may wonder what the “rev” value returned is for. CouchDB will never change a document. Instead, it will make a new document stored with the same id. The reason for this is to handle concurrency, and you should not rely on this for any revision control in your application. You can compact a database to get rid of wasted space.

If we want CouchDB to generate a id for us, we could use a POST instead. We would also omit the id from the url, since the id yet remains to be decided.

POST http://127.0.0.1:5984/geocaches
{“url”:”http://www.geocaching.com/seek/cache_details.aspx?guid=……"}

Now that we have successfully stored our document, we can retreive it by doing a GET.

GET http://127.0.0.1:5984/geocaches/GC1TCJR

As you can see from the response, CouchDB has added the id and revision fields to our document.

{"_id":"GC1TCJR","_rev":"1-f70033bafd9d72e174cecb67f58b2e4f","url":"http://www.geocaching.com/……"}

Update

Storing updates is nearly as simple as creating new documents. The only difference is that the document must contain both the id and the rev values, and the rev value needs to point to the latest revision. So if you get a document first, make your changes, and then put it up on the server again, things should go nicely. If someone else has stored an update between your get and put request, you will get an conflict error that you need to resolve. How you resolve the conflict is up to the you. You could try to merge your changes with the new revision in the database, or you could simply update your rev value with the latest from the databse and do a new put, effectively overwriting what changes that may have been done.

PUT http://127.0.0.1:5984/geocaches/GC1TCJR
{"_id":"GC1TCJR","_rev":"1-f70033bafd9d72e174cecb67f58b2e4f","url":"http://www.geoinfo.com/……

CouchDB will respond with a 200 OK status, and inform you about the new revision number.

{"ok":true,"id":"GC1TCJR","rev":"2-6aa44736b02f96844fdfbf4eece00b83"}

Delete

Can you guess how to delete a document? Close. You make a DELETE request, but you have to include the latest revision in the url as well.

DELETE http://127.0.0.1:5984/geocaches/GC1TCJR?rev=1-f70033….

As for updating, CouchDB keep your old document around for a while. It will add a new revision, and mark it as a stub for a deleted document.

The response will tell you the new revision number.

{"ok":true,"rev":"3-6b8ecfd8bd5d1cb8ae3fd49aea9dfe8d"}

If you try to do a get on the deleted document, you will get a 404 Object not found response with additional information stating that the document was deleted.

{"error":"not_found","reason":"deleted"}

Listing

Now that you know the basic CRUD operations, it would be nice to get a list of all our documents. CouchDB provides a special url we can use for this.

GET http://127.0.0.1:5984/geocaches/_all_docs

The response will contain information of total number of rows, and an array of ids and revision numbers.

{"total_rows":4,"offset":0,"rows":[
  {"id":"GC13H9E","key":"GC13H9E", "value":{"rev":"1-8e3c239c5da38d0fbe91ffdd24582b02"}},
  {"id":"GC144MQ","key":"GC144MQ", "value":{"rev":"1-865f40ed3047aefdf8c45520c84c4321"}},
  {"id":"GC145KB","key":"GC145KB", "value":{"rev":"1-83ba674d10ce404be7fc90460b1a9a13"}},
  {"id":"GCYXEG","key":"GCYXEG", "value":{"rev":"1-880c0d1767c8f6db0ce815fe0b35afdb"}}
]}

The _all_docs uri can take some parameters that makes it possible to paginate the result. You can use a combination of ‘startkey’, ‘endkey’, ‘limit’ and ‘skip’. Here is a couple of examples that you can try:

GET http://127.0.0.1:5984/geocaches/_all_docs?limit=2
  =>First two documents
GET http://127.0.0.1:5984/geocaches/_all_docs?limit=2&skip=2
  =>Third and fourth document
GET http://127.0.0.1:5984/geocaches/_all_docs?startkey=GC144MQ&limit=2&skip=1
  =>Two next documents after GC144MQ

What’s next?

Well, then. You should now have enough information to start making basic use of CouchDB. There are still a lot to cover, though. Did you know that you can upload binary attachments to documents? You can. What you can’t, though, is to query your data using SQL. Instead you will be making views, but that has to be waiting for now.

The basics

So here is the most basic ideas behind CouchDB and how it works.

Documents

While a relational db stores rows in tables, CouchDB stores jason-formatted documents. While a table in a relational db has a defined set of columns that can have values, there is no definition on what values a document in CouchDB should contain. So when a table enforce every row to be in the same format, each and every document in a CouchDB database could contain completly different kind of values.

The book CouchDB: The Definitive Guide uses business cards as an illustration on this. In a traditional database, you would have a table where each row represents one business card. You then have to choose what columns you would have. You would need a name, a telephone number, a url to a website and an email address. After a while, you realise that you would need a column for a company name and a new column for a second telephonenumber for the company. In the third iteration, you realise that you sill need  more phonenumbers, and maybe even a fax. Now, should we make more telephone columns, or should we have a one-to-many relationship from a business card to a list of phonenumbers? And what about all our trendy business contacts with only a single url on their card? There would be a whole lot of emtpy columns then.

In CouchDB, you would have a business card database where each card would be represented by one document. The content of the document would be defined by the data on that given businesscard.

As you can see, this makes everything very flexible. No need for any migration of existing documents when you suddanly find your first business card with a twitter name on it.

HTTP and REST

CouchDB is basically a small webserver listening to a given port. When communicating with the server, you would make HTTP requests specifying what you want, and CouchDB would make an apropriate respons. Instead of inventing some new rpc format, it uses the basic http request methods for each and every method. So if you want to get a document, you send a GET request. Do create or update a document, you use PUT or POST, and to remove a document, you use DELETE.

A service designed in this way, is often refered to as RESTful.

JSON

Every response comming from CouchDB, and every document stored inside CouchDB, will be in the form of JSON. JSON, or JavaScript Object Notation,  is a standard made for representing objects in a way that should be easy both for human and machine to write and consume.

A JSON object consists of a set of name-value pairs, where the value can be either an array of values, a JSON object, a string, a number, true, fase or null. Even though the synax is simple, it is possible to represent list of complex, nested objects.

A JSON representation of one of our business cards could look something like this:

{
   "name": "Joseph A. Gutierrez",
   "website": "http://wallpaperdealer.com/",
   "phone": [
       "41-397-0567",
       "954-399-5693"
   ],
   "fax": "518-923-6525"
}

Installation

Like many other open source applications, CouchDB is distributed as source code, some dependencies to other open source technologies, and a description on how to build for you spesific platform. This makes it easy to port everything to different platforms and operating systems, but a little more complex for windows users like me that are used to get everything wrapped up nice in a install executable.

Luckly, there are people out there that provieds us with binaries, and a binary for CouchDB for windows is made available through the CouchDB Wiki.

The installer will suggest installing CouchDB as an service, which makes it easy enough for now.

Configuration

CouchDB stores configuration data in two ini files. You can find them where you installed CouchDB in the subfolder \etc\couchdb\. default.ini will contain the defaults, and local.ini will contain your overrides. Do not change default.ini. It will be overridden if you install or update CouchDB at a later time. If you find something in default.ini that you need to tweek, copy the settings into local.ini and make you change there.

The most basic settings is already present inside local.ini to make it easy for you to change. Settings that may be useful is httpd settings, logging and basic authentication.

Up and running?

After installation, you can check if everything is OK by navigating to the following url in your browser: http://localhost:5984/

If CouchDB is running, and if you have not made any changes to port number etc, you should get a welcome greeting from CouchDB, something similar to

{"couchdb":"Welcome","version":"0.11.0b916031"}

Start playing

If your CouchDB server greets you welcome, you can start play with it. You can either find a http client letting you compose custom requests, or you can use the administrative interface installed with CouchDB.

Directing your browser to http://localhost:5984/_utils/, you will see a web application called Futon. From there, you can create databases and documents, run CouchDBs suite of unit tests, check out the current configuration and so on.

Go nuts!

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.

In the fit4delphi package, inside the testrunner folder, you will find a project named DelphiTestRunner.dproj. You can use this project to automatically run a test, or a suite of tests, and store the result as a file. To do his, you have to tell the testrunner where the FitNesse server is running, and which file and in what format the result should be store in. This is done with command line parameters in the given form:

DelphiTestRunner.exe [options] host port page

Host and port must be the same as specified when starting FitNesse. The page parameter is the url for the wiki page you want to test. All subpages of this page will also be tested.

There are multiple options you can specify.

• -debug
  This option will print FitNesse protocol actions to the console.
• -v
  This option should give a verbose output about test progress to the console, but personally, I can’t make it work…
• -results file
  The result of the testrun is saved to a textfile with the given name.
• -html file
  The result of the testrun is saved to a html file with the given name.
• -xml file
  The result of the testrun is saved to a xml file with the given name. The xml format is given in the userguide.
• -nopath
  This option will make FitNesse ignore !path options specified in the wiki pages.
• -suiteFilter filter
  Specifying a filter will only run pages with tags matching the filter. You can read more about this in the userguide.

An example of a command line could be some thing like this:

DelphiTestRunner.exe –html results.html localhost 80 MyTestSuite

Get it running

So let see if we can make this work. Fit4Delphi comes with a older version of FitNesse. You can choose to use this version, or you can get a newer version from fitnesse.org. I like new shiny things, so I downloaded a brand new fitnesse.jar. Assuming that java already exists on your computer, fitnesse.jar is all you need to get going. Put it in a folder somewhere, e.g. c:\fitnesse\, and run

c:\fitnesse\java -jar fitnesse.jar

Fitnesse will now unpack it self before it starts. If you later want to upgrade to a newer version of FitNesse, you can download a new jar-file and new resources will be extracted next time you start FitNesse. When FitNesse starts, it will tell you what version it is and what port it is running on. It will also tell you a couple of other things, but the port number is what we need right now. The port number defaults to 80, the standard http port. So fire up you webbrowser, and navigate to http://localhost:80, and you will be presented with the default front page for FitNesse. To the left, you have a tree-structure showing what pages exists in the wiki, and to the right you have the content for the current page. In the FitNesse branch of the tree, you can find the user guide for FitNesse amoung all the acceptance tests for FitNesse itself. On the FrontPage, click the edit-button to the left. At the bottom of the page, write the name of your new testsuite, ‘DelphiTests’, or what ever. It need to be a ‘WikiWord’, though. When you save the document, you will see your inserted text together with a ‘[?]’. This means that the wiki sees your wikiword as a title for a page, but can’t find the page itself. When clicking on the questionmark, the wiki will create the page, and let you edit it. So let’s start with a simple table. Fill out the new page with something like the following:

|test table|
|in value|out value?|
|1|2|

After saving, you will see your table nicely formatted. Is there a Test button to the left? If not, click the Properties-button, and choose Test as page type. Now, click the Test-button… Nothing happends, right? FitNesse finds the table and want it to be tested, but can’t find anyone willing to work. It needs to know who to call for the job. It is done by defining the ‘COMMAND_PATERN’ variable. When testing delphi code, we will need  DelphiFitServer.exe to do the work for us, so we give FitNesse the path to this executable. I have copied both DelphiFitServer.exe and fit.bpl to a ‘bin’-folder in my FitNesse-folder. You will find the source in \fit4delphi\fitserver\ and \fit4delphi\fit\.

!define COMMAND_PATTERN {bin\DelphiFitServer.exe -v %p}

The –v parameters tell DelphiFitServer to print out messages, and the %p parameter represents the path where DelphiFitServer should look for fixtures. FitNesse builds this path from classpath-settings in the wiki. Let’s include one in our page:

!path bin\*.bpl

Let’s hit that Test button again and see if there is any progress. This time we get a lot of yellow on our page. While red tells us that a test did not pass, yellow tells us that something went wrong when trying execute the test. As you can see, DelphiFitServer couldn’t find fixture for our table. If you click the ‘Output Captured’ sign in the right corner, you will get some details on the execution. You can see what exe-file was used, and what bpl-files was loaded. We now need to add some testcode on our own.

Writing our first fixture

From the yellow text, we found that we need a class named ‘TestTable’. Acctually, FitNesse is quite flexible when it comes to naming. You can read more about it the documentation, but I will disclose that a class named ‘TTestTable’ should be accepted. So lets create a new delphi package. Add a reference to fit.bpl and the source path for fit4delphi\fit\source, fit4delphi\fit\source\exception and fit4delphi\RegExpr. Create a new unit, and define a new class deriving from TColumnFixture. You will need the file ColumnFixture in your uses section for this to compile. You will also need to enable detailed rtti for your class, and register it with a call to RegisterClass:

unit fitTestTable;

interface

uses
  ColumnFixture;

type
  {$M+}
  {$METHODINFO ON}
  TTestTable = class(TColumnFixture)
  published
  end;

implementation

uses
  Classes;

{ TTestTable }

initialization
  RegisterClass(TTestTable)

end.

Build the new package, and move it to the bin folder of your FitNesse installation. Run the test again, and you will find that there is now three exceptions instead of one. Progress! This time, it chokes on the column titles. Could not find field: in value. Well, lets add it, then. A published property named InValue of type double should do. Compile… Copy… Test…  One down, two to go. Of course it choked on the next column also. This time we need to add a function named OutValue returning a double.  Let’s fake the implementation for now, and just return 0.

   TTestTable = class(TColumnFixture)
  private
    FInnValue: double;
  published
    property InnValue: double read FInnValue write FInnValue;
    function OutValue: double;
  end;

Now, that got rid of both the remaining exceptions, but leaves us with some ugly red spots. This is actually good though: Our test runs with out problems, but fails. I will leave it up to you to make the test pass. It shouldn’t be to hard, and the reward of green colour should be enough to make you wanna write some real tests.

The unit contains three public methods:

function LoadModuleTests(LibName: string) :ITest;
procedure RegisterModuleTests(LibName: string);
procedure UnloadTestModules;

The LoadModuleTests( )-function, dynamically loads the given library (dll or dtl files), and returns an interface to the tests defined within. RegisterModuleTests( ) does the same, but also calls RegisterTest( ) with the interface from the library.

There is one requirement that the library has to satisfy. It must export a function named ‘Test’ that returns a ITest-interface. Following is a basic project file showing how this can be done:

library OurUnitTests;

uses
  TestFramework;

function Test: ITest;
begin
  result := RegisteredTests;
end;

exports
  Test name 'Test';

end;

The Test( )-function simply returns the result from the RegisteredTests( ) method from the TestFramework-unit. RegisteredTests( ) returns a ITestSuite containing all the test classes registered.

Here’s a samle project file that loads all dll-files from the executables folder, and runs all test through the GUITestRunner:

program RunTests;
uses
  Forms,
  TestFramework,
  GUITestRunner,
  TestModules,
  SysUtils,
  Windows,
  JclFileUtils,
  classes,
  Dialogs
  ;

  {$R *.RES}

procedure LoadTests;
var
  filelist: TStringList;
  str: string;
begin
  filelist := TStringList.Create;
  try
    BuildFileList('*.dll', faAnyFile, filelist);

    for str in filelist do
    begin
      try
        RegisterModuleTests(str)
      except
        on E: Exception do
          ShowMessage(e.Message);
      end;
    end;
  finally
    filelist.free;
  end;
end;

begin
  Application.Initialize;

  LoadTests;
  GUITestRunner.RunRegisteredTests;
  UnloadTestModules;
end.

The BuildFileList( ) method comes from JCL, and simply fills a TStringList with filenames from the given mask. As I said, this is a very basic project, but it shows how to use the TestModules-unit to dynamically load tests. This can easily be expanded to a more flexible solution. You could use command parameters to control what folder should be searched for libraries, or what testrunner should be used, GUI or XML or custom runner.