A Tidy Little Towers of Hanoi implementation in C++

25 Feb 2013

I’ve got an interview coming up in the next couple of weeks for a fairly large software company. Something that’s regarded as a bit of a classic problem is the Towers Of Hanoi puzzle. The story goes something like this:

There is a history about an Indian temple in Kashi Vishwanath which contains a large room with three time-worn posts in it surrounded by 64 golden disks. Brahmin priests, acting out the command of an ancient prophecy, have been moving these disks, in accordance with the immutable rules of the Brahma, since that time. According to the legend, when the last move of the puzzle will be completed, the world will end. (Wikipedia)

The “immutable rules of the Brahma” are:

  • Only one disk may be moved at a time.
  • Each move consists of taking the upper disk from one of the rods and sliding it onto another rod, on top of the other disks that may already be present on that rod.
  • No disk may be placed on top of a smaller disk.

You can actually buy these as children’s toys, and the thing is, kids start to pick it up pretty quickly. There’s a pattern to it, and there’s only one way of doing it, so it’s something that’s easy to learn intuitively. It’s a little bit harder to codify, however. Here’s the solution I came up with:

  1. Start with all of the discs on pillar A.
  2. To move all the discs to pillar B:
    1. Move the stack of discs less the bottom disc to pillar C
    2. Move the last disc to pillar B
    3. Move the stack of discs on pillar C back to pillar B.

You’ll notice that this is a recursive solution - it works out to only be a few lines of code. Here’s what I came up with:

//moves n discs from stack one to stack two, using stack 3 as intermediate.
template <typename T>
void MoveDisksHanoiStyle(Stack& s1, Stack& s2, Stack& s3, size_t n) {
    // base cases.
    if (n == 0)
        return;
    if (n == 1) {
        s2.push(s1.pop());
        PrintHanoiTowers<T>();
        return;
    }
    MoveDisksHanoiStyle(s1, s3, s2, n - 1);
    s2.push(s1.pop());
    PrintHanoiTowers<T>();
    MoveDisksHanoiStyle(s3, s2, s1, n - 1);
}

Whilst the algorithm wasn’t too bad, I found setting up the infrastructure fairly difficult. I was using my own custom Stack implementation (another practice question), and printing stacks is either destructive and O(n) or an O(2n) operation (copy all the elements to one stack, then copy them back). So, I needed a copy constructor that copied the linked list internal to the stack. Headache! The other little bit of trickery here is the PrintHanoiTowers<T>() function: because we’re swapping s1, s2, and s3 on each recursion, we can’t just print s1, s2, and s3 per-se. Here’s the function:

template <typename T>
void PrintHanoiTowers(Stack<T>* s1_save = 0, Stack<T>* s2_save = 0, Stack<T>* s3_save = 0) {
    static Stack<T>* s1_ptr = 0;
    static Stack<T>* s2_ptr = 0;
    static Stack<T>* s3_ptr = 0;
    if (s1_save) s1_ptr = s1_save;
    if (s2_save) s2_ptr = s2_save;
    if (s3_save) s3_ptr = s3_save;
 
    Stack<T> s1(*s1_ptr);
    Stack<T> s2(*s2_ptr);
    Stack<T> s3(*s3_ptr);
 
    while (s1.count() || s2.count() || s3.count()) {
        size_t s1c = s1.count();
        size_t s2c = s2.count();
        size_t s3c = s3.count();
        if (s1c >= s2c && s1c >= s3c)
            cout << setw(4) << s1.pop();
        else
            cout << setw(4) << "";
        cout << " ";
        if (s2c >= s1c && s2c >= s3c)
            cout << setw(4) << s2.pop();
        else
            cout << setw(4) << "";
        cout << " ";
        if (s3c >= s1c && s3c >= s2c)
            cout << setw(4) << s3.pop();
        else
            cout << setw(4) << "";
        cout << endl;
    }
    cout << setfill('-') << setw(14) << "" << setfill(' ') << endl;
}

What we’re doing here is:

  • Saving pointers to s1, s2, and s3 when we call with non-default parameters, and then
  • Copying the stacks on every call,
  • Then destructively removing and printing elements from all the stacks.

You can find my full working code for this solution (including a linked-list implementation, and a stack implementation) at my github exercises repo.

IPCTK: Run code out of process, use like a normal object

12 Feb 2013

Multithreading and the Singleton Pattern

In December of last year, as part of my undergraduate thesis, I developed a piece of software that statistically extrapolated electrical network data. This software required a lot of simulations - I needed a year’s worth of data at 15 minute intervals.

Doing the math:

365 days * 24 hours * 4 measurements/hour = 35040

Each simulation took 2.5 seconds to run, and so those 35040 simulations were going to take just over a day to run.

I was at a stage about a week out from the end of the project, and a spare day just to run simulations wasn’t really viable.

So, I did what any programmer would do - I tried to multi-thread my application.

The simulator I was using, however, wasn’t particularly keen on the idea - turns out, the API implements a singleton pattern. Just for the record - it was not an appropriate choice in this situation (I’m not really sure it’s ever a great choice actually).

If I was going to multi-thread this application, I was going to have to multi-process it.

Inter-process Communication

The basic procedure is:

  • Spawn a child process (in this case, the simulator)
  • Connect some anonymous pipes between the child and parent processes
  • Use stream-based I/O for communication between processes.

That’s fine, but it’s a lot of boilerplate code - what if there was a way to automate it?

Aspect-Oriented Programming with PostSharp

PostSharp is a great developer tool, based on the idea of applying attributes to .NET code that somehow modify the behaviour of the attribute target. I wondered if it was possible to write a ‘RunOutOfProcessAttribute’ that could just be slapped on top of a class to force it to run in another process?

Turns out it is: PostSharp has an aspect (MethodInterceptionAspect) that pulls the method body out of a method, replaces it with your custom code, and then allows you to call the method body later.

For our purposes, what we need to do in that custom code is:

  • Test to see if this code is running in-process or out-of-process
  • If it’s running in-process, forward the call to our external process
  • If it’s running out-of-process, run the code, and forward the result back to the calling process.

Use Procedure

The basic use procedure is:

  1. Add a new Exe project to your solution.
  2. Add classes to the Exe.
  3. For each class that you want to run out-of-process:
  4. Mark the class with the [RunOutOfProcess] attribute.
  5. Make sure the class implements IDisposable.
  6. Make sure that no initialisation logic is in the constructor - instead, just put in a call to an Init() function with the same parameters as the constructor. (this is a workaround for a PostSharp quirk)
  7. Mark your Init() function with the [Initializer] attribute.
  8. In the Exe entry point, simply add a call to IPCTK.OutOfProcessHandler.Loop(arg0, arg1);, where arg0 and arg1 are the first and second command-line parameters respectively.

Then, just add a reference to your new Exe project and start using the classes. Any classes marked with [RunOutOfProcess] will be… erm, Run Out Of Process.

A Couple of Useful Bits and Pieces

Attribute Targeting

MethodInterceptionAspects apply only to methods, not to classes. To ensure that we can put [RunOutOfProcess] on classes and obtain the desired behaviour, we define the RunOutOfProcessAttribute as follows:

[Serializable] //Required by PostSharp
[MulticastAttributeUsage(MulticastTargets.Method)] //target all methods of class...
[AttributeUsage(AttributeTargets.Class)] //...but only allow the attribute to be applied to the class
public sealed class RunOutOfProcessAttribute : MethodInterceptionAspect 

We then add the following CompileTimeValidate hook, which silently ignores private/protected member functions:

//Applies the attribute only to:
// classes implementing IDisposable,
// only on public methods,
// or on methods marked with [Initializer]
public override bool CompileTimeValidate(MethodBase method)
{
    if (method.DeclaringType.GetInterface("IDisposable") == null)
        throw new InvalidAnnotationException("Class must implement IDisposable " + method.DeclaringType);

    if (!method.Attributes.HasFlag(MethodAttributes.Public) && //if method is not public
        !MethodMarkedWith(method,typeof(InitializerAttribute))) //method is not initialiser
        return false; //silently ignore.

    return true;
}  

Serialisation

IPCTK works by serialising/deserialising the arguments to and return values from methods and sending these along anonymous pipes. As such:

  • The toolkit is most useful when the ratio of expected compute time to input/output size is high.
  • If anything needed to be optimised ever, it was serialisation for this purpose.

NetSerialiser would probably offer a good performance improvement, at the expense of being unable to serialise implementers of ISerializable. Maybe I’ll look into this in a future version.

More Info

For more information, take a look at the IPCTK project page on github.

NuGet: Adding Install Scripts to Project-based Packages

18 Jan 2013

ElecNetKit is bundled into a set of NuGet packages in order to simplify the setup procedure. The ElecNetKit.Engines.OpenDSS package, however, requires the OpenDSS COM component to be installed in order to run.

Rather than leave my users hanging without any idea as to why they couldn’t use the OpenDSS engine within ElecNetKit, I added a PowerShell script that notifies the package installer if OpenDSS is not installed:

try {
$obj = New-Object -ComObject OpenDSSengine.DSS
}
catch {
    $null = [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
    $yesno = [System.Windows.Forms.MessageBox]::Show(
    "It looks like you don't have OpenDSS installed. Head over to" +
    "http://sourceforge.net/projects/electricdss/ and grab a copy?", "Hey!", 4)
    if ($yesno -eq "YES")
    {
        start 'http://sourceforge.net/projects/electricdss/'
    }
}

NuGet can run powershell scripts upon package installation, so long as they’re located inside the package’s ‘tools’ directory. When you’re dynamically generating packages from project output, however, it’s not immediately clear how to add such files.

If you take a look at the NuGet.exe source file Commands/ProjectFactor.cs, on about line 155:

// if there is a .nuspec file, only add content files if the  element is not empty.
if (manifest == null || manifest.Files == null || manifest.Files.Count > 0)
{
// Add content files
AddFiles(builder, ContentItemType, ContentFolder);
}

Turns out you can just add the <files> element to your .nuspec file and the files get included along with the project outputs. Here’s the relevant fragments from my .nuspec:

<files>
    <file src="NugetScripts\*.ps1" target="tools"></file> 
</files>
</package>

On a side note, open-source tools are the best!

Git: Undoing a fast-forward merge when you should've just used a new branch

14 Jan 2013

The Problem

Here’s the scenario:

I had a git repo that looks like this:

A-B----     master
   \   /
    C-D     *develop

I was on the develop branch. Here’s the foolish thing that I did:

  • I forgot that develop differed from the master branch,
  • Made a change on develop, committed it, and merged it into master, and
  • Pushed the change to my remote (called publish).

There were no changes after B on the master branch, and as such, when I merged, git did a fast-forward. My repo now looked like this:

A-B-C-D   master, develop, remotes/publish/master, remotes/publish/develop.

I wanted to keep develop at D, but revert master to B, and then merge the changes made at D into master.

What I Should’ve Done to Start With

What I should’ve done was:

git checkout master     #change to `master` branch
git checkout -b hotfix  #make a new branch called `hotfix` from `master`
#make file changes
git commit              #commit the `hotfix`
git checkout master     #switch back to `master`
git merge hotfix        #pull in the hotfix changes
git checkout develop    #switch to `develop`
git merge hotfix        #pull in the hotfix changes
git push publish        #push everything to my remote.

Resulting in a diagram that looks like this:

    D--     hotfix
   /   \
A-B---- E   master
   \    |
    C---F   *develop

Fixing the Mistake

Turns out the solution wasn’t really that hard, but git can be really scary if you’re not sure what you’re doing. The develop branch is already in the right spot, so we just need to:

git checkout master         #make sure we're on the `master` branch
git reset --hard sha-of-B   #move `master` back to revision `B`, deleting all other changes in the working directory.
git push publish --force    #because we've reverted some changes, we need to force the remote to accept the reversion.

That reverts the master branch back before the merge. To then pull in the changes made in the hotfix:

git cherry-pick sha-of-D    #pull in only the changes made in revision D.
git push publish

And we’re done!

Thanks to Simon Boudrias for his help on this one. See the StackOverflow question here.

Rethinking the `static` keyword in Object-Oriented Programming (OOP)

30 Dec 2012

abstract static

A friend lamented to me last week about the absence of abstract static members from class definitions in Java:


god damn why can’t you have abstract static methods in java. #sometimesstupidlanguage

– Samuel Killin (@SamuelKillin) December 13, 2012

@samuelkillin When would you need to do that?

– Fabian Tamp (@capnfabs) December 13, 2012

@capnfabs eg: superclass Car with abstract method getName(). Shouldn’t have to instantiate a Porsche to call Porsche.getName()… any soln?

– Samuel Killin (@SamuelKillin) December 13, 2012

@samuelkillin Why do you want to call Porsche.getName(), if you don’t have an actual Porsche?

– Fabian Tamp (@capnfabs) December 13, 2012

@capnfabs All Porsche’s have the name “Porsche” - it’s a property of the type, not a particular instance.

– Samuel Killin (@SamuelKillin) December 13, 2012


Turns out you can’t do it in C# either. Common understanding is that the absence of such a feature from these languages is an limitation in the language implementation (Java, C#). I’ve come to the realisation that there might be a very good reason as to why you can’t have abstract static members in these languages, and I think it’s due to a problem with the way we understand the static keyword.

I think we might be thinking about the static keyword wrongly. The static keyword is used for instance-independent functions and data. Instance-independence, however, doesn’t really make sense in an object-oriented context.I’ll explain this in a second, but fundamental to understanding that is an understanding of the way that programmers view class definitions.

What do class definitions really represent?

The tweet presented at the start of this article perfectly represents the way that many programmers think about class definitions. There are two main components here:

  1. Class definitions represent a type of object, and
  2. A class definition defines a set of properties common to all objects of that type.

With such an understanding, it’s easy to see where the need for an abstract static member comes from. Like in the Porsche example earlier, sometimes, each subclass of a class will share a common property, and this property should be implemented to be common across all instances of the subclass.

The difficulty in this understanding is that it’s very nearly accurate. What I think a lot of programmers get wrong when it comes to OOP is that class definitions do not represent a type of object, but represent a contract of characteristics that each instance is guaranteed to fulfil.

In the same way that classes implement interfaces, instances (objects) implement class definitions. In their purest form, class definitions specify specific data and functions that class instances will hold - no more, no less. They make no guarantee of type or commonality between instances of the same class.

This is wholly consistent with the notion of classes as objects - our superclass Car simply requires all instances to fulfil the contract of having a Make and Model, and cares not for the implementation details, including whether there are subsets of Cars with common Makes or Models. Asking the superclass to understand this by marking its members with abstract static requires a tighter coupling than should be used in such scenarios.

Implications for the static keyword

If a class definition is simply a contract of characteristics, or an interface that instances are expected to fulfil, then the notion that static members represent common properties of the type is wrong.

What are static members actually for, then?

I’d argue that static members are simply a convenience to the programmer, somewhat divergent from true object-oriented design. In my own experience, I’ve only ever used static members when I’ve somehow needed to manage or coordinate multiple instances of a class. Take a look at the following class definition, defining a member contract for an animal on a farm (example in C#):

class Animal {
    String _uniqueID;
    public String UniqueID {get { return _uniqueID; }}

    public Animal() { 
        _uniqueID = getUniqueID();
    }

    public static HashSet<string> _uniqueIDs;
    public static Animal() {
        _uniqueIDs = new HashSet<string>();
    }
    public static String getUniqueID() {
        //code to generate ID and check it's not already in use,
        // i.e. in _uniqueIDs
    }
}

Our Animal class is split into two parts - the non-static members define the actual data pertaining to the Animal contract, and the static members simply manage the integration of the Animals within their broader context.

You could just as easily express the same functionality like this:

class Animal {
    String _uniqueID;
    public String UniqueID {get { return _uniqueID; }}

    public Animal(String UniqueID) { 
        _uniqueID = UniqueID;
    }
}

class Farm {
    public static HashSet<string> _uniqueIDs;
    public static Farm() {
        _uniqueIDs = new HashSet<string>();
    }
    public static String getUniqueID() {
        //code to generate ID and check it's not already in use,
        // i.e. in _uniqueIDs
    }

    public Animal MakeAnimal() {
        return new Animal(getUniqueID());
    }
}

Using this architecture, Animals are still guaranteed to have unique IDs within their broader context - Farm objects - without having coordination logic embedded within the Animal class.

If you’re not expressing your class in this format, you’re probably violating the Single-Responsibility Principle - you’ve simultaneously got a class that is used for SomethingOrOther-ing and the static aspects of that class, that coordinate SomethingOrOthers.

Here’s a challenge for you - try re-writing the static keyword out of some of your old code. It may take a little getting used to, and it’s certainly not always necessary, but it will be helpful for understanding that static is a convenience keyword only, and not an integral part of Object-Oriented design.

A final note on Porsches

As for our opening example - “all Porsches have the name ‘Porsche’” - I disagree; you’re thinking about classes wrong. “Porsche” is the make of the individual car, and the fact that it is a value common to a subset of Cars should merely be a coincidence to the Car superclass. I’ve got no problem with thinking about this specific issue without the use of the static keyword, with:

class Porsche : Car {
    public override string GetMake() {
        return "Porsche";
    }
}