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.

Test Frameworks

DUnit

http://dunit.sourceforge.net/

DUnitLite

http://code.google.com/p/dunitlite/

DSpec

http://sourceforge.net/projects/dspec/

Mocking/Faking

Pascal Mock

http://sourceforge.net/projects/pascalmock/

Delphi Mock Wizard

http://code.google.com/p/delphi-mock-wizard/

Simple Mock

http://delphixtreme.com/wordpress/?p=14

Ultra Basic MockObjects

http://sourceforge.net/projects/ubmock/

Code coverage

Discover for Delphi

http://www.cyamon.com/discover1.htm

AQ Time

http://www.automatedqa.com/products/aqtime/

Supporting tools

DUnit IDE integration

http://delphixtreme.com/wordpress/?page_id=8

Websites

Delphi-Extreme

http://www.delphixtreme.com/

http://www.delphixtreme.com/forums/

FitNesse

FitNesse

http://fitnesse.org/

Fit4Delphi

http://code.google.com/p/fit4delphi/

FitNesse.Tutorials

http://schuchert.wikispaces.com/FitNesse.Tutorials

Books

	Fit for Developing Software: Framework for Integrated Tests by Rick Mugridge; Ward Cunningham Publisher: Prentice Hall Pub Date: June 29, 2005 Print ISBN-10: 0-321-26934-9 Print ISBN-13: 978-0-321-26934-8 Pages: 384
	The Art of Unit Testing: with Examples in .NET by Roy Osherove Publisher: Manning Publications Pub Date: June 28, 2009 Print ISBN-10: 1-933988-27-4 Print ISBN-13: 978-1-933988-27-6 Pages: 320
	Test Driven Development: By Example by Kent Beck Publisher: Addison-Wesley Professional Pub Date: November 08, 2002 Print ISBN-10: 0-321-14653-0 Print ISBN-13: 978-0-321-14653-3 Pages: 240
	xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros Publisher: Addison-Wesley Professional Pub Date: May 21, 2007 Print ISBN-10: 0-13-149505-4 Print ISBN-13: 978-0-13-149505-0 Pages: 944

Well – its no firework, but it’s a start…

For those who are interested in the code, it’s available for  download here. The lib-folder contains two libraries that I use. First of all, there is the Free Pascal OpenGL Headers used for rendering. Second, there is a folder called ‘SDL’, which is a older version of the Delphi Container and Algorithm Library (DeCAL).  I started using it for many, many years ago, back when it was a commercial product. It was called Standard Delphi Library, but was renamed to avoid confusion with ‘Simple DirectMedia Library’. I guess it’s time to find something else, and when I start using Delphi 2009, I will for sure.

So, how did I put something unto the screen?

I started off with a simple TParticle class with information about position, velocity, color, time to live and age.

 TParticle = class(TObject)
  public
    constructor Create;

    procedure Update(DeltaFrame: int64);

    property Position: TVector3D read FPosition write FPosition;
    property Velocity: TVector3D read FVelocity write FVelocity;

    property Color: TColorFA read FColor write FColor;

    property TimeToLive: int64 read FTimeToLive write FTimeToLive;
    property Age: int64 read GetAge;
    property Dead: boolean read FDead write FDead;
  end;

Then followed a TParticleManager to hold all the particles.

 TParticleManager = class(TObject)
  public
    constructor Create;
    destructor Destroy; override;

    procedure AddEmitter(Emitter: TParticleEmitter);

    procedure ProcessFrame;

    property Particles: DArray read FPArticles;
  end;

For each ‘game loop’, the particle manager will loop through all particles, destroying those that have lived their age, and telling the others to update them self. When calling Update( ) on the particle, it pass in the tickcount since update. This is to ensure a relatively smooth and natural movement even if the fps is not stable.

 procedure TParticleManager.ProcessFrame;
  var
    CurrentFrame: int64;
    FrameDelta: int64;
  begin
    CurrentFrame := GetTickCount;
    FrameDelta := CurrentFrame - FLastFrame;

    RemoveDeadParticles;
    EmittNewParticles(FrameDelta);
    ProcessParticles(FrameDelta);

    FLastFrame := CurrentFrame;
  end;

It will also contain a list of TParticleEmitters. The particle emitter will get it’s chance to emit new particles once every loop. It is the emitters responsibility to give the new particles a initial position and velocity.

 TParticleEmitter = class(TObject)
  public
    constructor Create;
    procedure EmittParticles(TimeSinceLastFrame: int64; Particles: DArray);

    property ParticlesPrTick: extended read FParticlesPrTick write FParticlesPrTick;
  end;

The rendering is separated into it’s own class, TRendrer. This class will to all the OpenGL initialization-stuff. It is given a list of objects to render, where each item must implement the IRenderItem interface. In this way, the rendrer do not need to know anything about what it renders. It just setup a place for the rendering to happend, and asks the item to draw it self.

 TRendrer = class(TObject)
  public
    constructor Create(AHandle: THandle);
    destructor Destroy; override;

    procedure Render(ItemsToRender: DArray);

    procedure HandleResize(NewSize: TRect);
  end;

To make the particle able to render it self, I have made a sub class, TVisualParticle, which implements IRenderItem. For now, it just draws a small triangle in the particles color.

procedure TVisualParticle.Render;
begin
  glPushMatrix();
  glTranslatef(Position.x, Position.y, Position.z);

  glBegin(GL_TRIANGLES);
    glColor4f(Color.Red, Color.Green, Color.Blue, Color.Alpha);
    glVertex3f(-0.1,-0.1, 0);
    glVertex3f( 0.1,-0.1, 0);
    glVertex3f( 0.0, 0.1, 0);
  glEnd;

  glPopMatrix;
end;

From here, there are a couple of things that needs improvements. I need to explore OpenGL a bit more to get control over ‘the world’ that the particles lives in. Maybe a camera-model or something is needed. I don’t know. I also need to look into ways of rendering a little more interesting particles then triangles… And then there are physics – particles should be able to react to gravity and other forces as well. I’m not sure where I will start though. Time will show…

What caught my colleagues interest, was a small firework-effect when the development environment was cleared. So we started discussing it, and soon I was determined to show that it’s really not that hard to make such effects. Now, I have never before done anything like this before. I lack experience with both graphics programming and the necessary math/physics. But it can’t be that hard, can it?

Well, we’ll just have to wait and see, then. The first challenge will be to get something unto the screen, and than I can start look at how to make it look nice. I will try to steer away from available libraries and tutorials, and rather come up with something completely on my own. The visual part will require  some reading though…

You can take a look at it on the delphi.about.com-page: How to Mimic Office 2007 Rich Menus using Owner Drawn TMenuItems