Category Archives: Project Euler

Revisting the Project Euler problem runner

I’m sure that you must have heard about Project Euler, which “is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve”. I have blogged about tackling the Project Euler problems before, and at the time, I developed a simple program to try to automate running the problems.

That was about 18 months ago, I’ve learned a lot since then and I think that it is high time to take a look back at the code and see if I can spot if there is any room for improvement.

The current project

The current structure of the project

Current structure

Let’s have a look at how I structured the project when I set it up. The first thing that you will notice, is that I messed up the package names. It should be “uk.co”, and not “co.uk”, according to the Java language specification. A minor point, and not really a big deal, we can easily sort it out.

Something else I did, was lump everything together into the same project and package – the runner program, the utils (e.g. helper classes that you write as you progress through problems), resources and the problems themselves.

I don’t think that this was necessarily a bad idea at the time, I don’t think that it is inherintly a bad idea now, it’s logical for everything to share the same package. Or should I say, it was logical for everything to share the same package.

I am going to put the code for the problem runner onto Github, but I don’t want to share the answers to the problems. To answer your question, I think that it goes against the point of Project Euler, that of having a set of problems that the inquisitive person can solve with some math and programming. I have also found that the problems also help in getting comfortable with the syntax of a new programming language – after all the solutions to the problems remain the same, however the implementation is subtley different depending on the language being used.

Re-Design

Examining the current code and design, we can immediately identify some changes which we are going to make  I’m going to seperate the uk.co.temporalcohesion.euler package into three packages, which are more distinct from each other, but still keep them all in the same project. Why? Well, it is obvious that there are three tasks which we have to manage:

  1. Running problems.
  2. Provide an API to run the problems.
  3. Store the problems somewhere

To shed some light on my thinking here, lets examine these in more detail. This will also identify areas of possible improvement in the design.

1. I want someway of consistenly running a problem (or group of problems) to test the solution(s) to (a) Project Euler problem(s). This is basically our console runner application, which doesn’t have to know exactly how this happens, it recieves input, and returns output – how that output is generated is irrelevant to it.

2. I want an easy to use API which I can leverage to easily implement the solution to a Project Euler problem, so that I don’t have to worry about re-writing all the input/output code over and over again. I also want to be able to share this API, without sharing the answers to the problems themselves.

3. I need to have somewhere I can put the answers to the problems, and associated helper classes (Prime number generators, etc) which I can easly backup, and easily run the problems from.

These are sounding a bit like user stories, and I suppose they are. They can be formalised as so:

As a Problem Solver, I want to run the solution, or group of solutions, to a Project Euler problem.

As a problem solver, I want to concentrate implementing the solution to a euler problem, not on implementing input/output for the problem.

As a problem solver, I want a place to develop and store the problems, from which I can run the problems to test the solution.

Fairly concise and simple requirements, which we will revisit later. We still have to examine the code in a little more detail so that we can identify exactly what it is we are going to refactor.

Code review

The main class to examine is Euler, in Euler.java.  The first to say without even looking at the code, is that the name is fairly awful. Then when we examine the code in more detail, we can see the name is even worse. The class has the main entry point for the program, as well as all the code to actually run the problems. This class is doing everything, there is definately no Seperation of Concerns. It is responsible for accepting user input, loading and running the problems and displaying the output. Wow.

The class is designed around the Command Pattern, and it has worked quite well. Looking at it now, a further two patterns could be used, namely Strategy and Template method.I’m still in two minds about refactoring the design pattern in use, but that discussion can be put off for the time being, as I have other things to concern me.

There are 144 SLoC, not a massive amount, but when you consider the above and what the class should be doing, then it is clearly a bit weighty. There are 7 functions in total, not counting the constructor, not a massive count, but as the SLoC count indicates, some of those functions are a bit long. The worst offender is the following method.

[java]

private void loadClasses() {
InputStream fis = null;

Properties p = new Properties();

try {
fis = ClassLoader
.getSystemResourceAsStream("co/uk/temporalcohesion/euler/resources/problems.properties");
p.load(fis);

Enumeration<?> e = p.propertyNames();
while (e.hasMoreElements()) {
String key = (String) e.nextElement();
String value = (String) p.getProperty(key);

Object o = Class.forName(value).newInstance();
if( ( o != null) && (o instanceof Problem)){
Problem problem = (Problem)o;
problems.put(Integer.parseInt(key), problem);
}
}
}

catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassCastException e) {

}
finally {
try {
fis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}

[/java]

Wow, that’s a lot of code for something which is relatively straightforward. It’s not exactly easy to read, and it violoates the Single Responsibility Principle: by loading in and enumerating over a properties file, instantiating new instances of problem classes, and handling all the exceptions which can be thrown. There will definately be some room for improvement there.

Getting back to the main Euler class as a whole, there is an even worse problem…

There are no unit tests!

This is a disastrous situation, because it means I cannot refactor the class with any confidence. The me of 18 months ago has a lot to answer for. I’ve got a bit of work to do. Check back next time to see how I’ve progressed things.

Building the Project Euler framework, part 3

In part 2, I showed you an improved, although still pretty basic problem runner framework for Project Euler. I did leave out some things though, and I’m going to try and explain them now.

Firstly, I haven’t really shown how I use the Problem interface. You can see it in part 1 of this series of posts. In Eclipse, you can create a new class in a package, which should bring up the “New Java Class” dialog. Give the class a name – for Project Euler problems I’ve chosen to name them “One”, “Two”, “Three” etc. You can then add an interface that the class is to implement, click ‘Add’, and type in Problem. You can also choose some methods to stub out, tick ‘public static void main(String[] args)’. Click Ok, and you should get something like this:

package co.uk.temporalcohesion.euler.problems;

import co.uk.temporalcohesion.euler.interfaces.Problem;

public class One implements Problem {

	public String answer() {
		// TODO Auto-generated method stub
		return null;
	}

	public int id() {
		// TODO Auto-generated method stub
		return 0;
	}

	public double time() {
		// TODO Auto-generated method stub
		return 0;
	}

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		// TODO Auto-generated method stub

	}

}

I can hear you asking why am I including then main(String[] args) function if we already have a class that is capable of running the problems (the main Euler class)? Well, what I do to create is to create a Euler object in the problems main method, and get it to run the problem, like this:

        /**
	 * @param args
	 */
	public static void main(String[] args) {
		new Euler().run(1, true);
	}

So the problem class is running itself using the Euler object, which knows how to find the problem, instantiate it and run it. I find doing things this way is easier when working on the problem, as you can simply run the problem as a java application, and it will output the result in a standard format we are expecting to to the console in Eclipse.

Thinking about it, you might be wondering – what’s the point of all this, it seems a little excessive for something that can be done fairly easily? Well – I’ve done it like this because the whole point of me doing the problems on Project Euler, is to practice problem solving and become more comfortable in my use of Java. So I think what I’ve done is pretty valid in that regard.

Building the Project Euler framework, part 2

In Part 1, I showed a basic problem runner framework for Project Euler, however there are a number of ways in which we can improve it. For example:

  • How can we run a specific problem?
  • How can we hide the answer, but still run the problem?
  • How can we avoid manually adding problems to the List of problems?
  • Not really to do with the framework, but how can we automate building everything?

I’ll demonstrate some ways that we can do all that, except for the 4th option, which is handled by Ant.

Improving the framework

The first thing that we can do is to add a utility function that handles showing the answers, this way we only have one place in the code that we need to update when we want to change how the answers are shown.

private void showAnswers(Problem problem){
		System.out.println("Problem: " + problem.id() + ". Answer: "
				+ problem.answer() + ". Time: " + problem.time() + "s");

}

To run a specific problem, we need to overload the run() function to access the problem we want, and show the answer.

public void run(int i) {
		try{
			Problem problem = (Problem) problems.get(i);/* problem list starts at 0 */

			if (problem != null) {
				showAnswers(problem);
			}
			else {
				System.out.println("There doesn't appear to be an answer for problem " + i);
			}

		} catch (IndexOutOfBoundsException e){
			System.err.println("There doesn't appear to be an answer for problem " + i);
		}

	}

As you can see, we get the specified problem out of the list, and use our new showAnswers() function to display the answer.  I’ve tried to include some good error checking – we might try to get a problem that doesn’t exist.

In order to prevent the answer from being shown, we can add a boolean parameter to the run() and showAnswers() functions.

private void showAnswers(Problem problem, boolean showAnswers){
		if(showAnswers){
			System.out.println("Problem: " + problem.id() + ". Answer: "
					+ problem.answer() + ". Time: " + problem.time() + "s");
			}
			else {
				problem.answer(); /* we still need to work out the answer */
				System.out.println("Problem: " + problem.id() + ". Time: " + problem.time() + "s");
			}
	}

public void run(boolean showAnswers) {
		for (Problem problem : problems) {
			if (problem != null) {
				showAnswers(problem, showAnswers);
			}
		}
	}

Dont’t forget to change the overloaded run(int i) to run(int i, boolean showAnswers). This way we can control exactly  whether to show the answers when we run all the problems, or to show the answer if we run a specific problem.

One thing remains to do, and that is to correctly parse the command line arguments to control whether the answers are shown or not. We want to handle something like this:

C:\development\euler>java -jar ProjectEuler.jar 42 -noanswer

Where 42 is problem 42, and -noanswer clearly specifies not to show the answer. We’ll also need to handle all combinations of this as well, such as:

C:\development\euler>java -jar ProjectEuler.jar 42

Which should show the answer. I’m not going to show my code for parsing the command line arguements, I’ll leave that as an exercise for the reader, as I believe that it is adequately covered elsewhere on the internet, and in any number of Java books.

The more astute among you will notice that I’ve not mentioned how we are going to avoid manually adding problems to the List of problems. I’ll cover that next time.

Building the Project Euler framework, part 1

As promised, here is the first part of the series of posts I hope to write demonstrating how I wrote my problem runner framework for Project Euler.

Firstly, before you continue reading, I suggest that you research the Command pattern, Google will also provide you with some good sources in your research.

Done? Ok then. It shouldn’t matter what IDE you use, I am using Eclipse (ganymede), any IDE should do. If you don’t know what an IDE is, then go and find out, and then come back.

Start Coding

In your IDE, and following the Java package naming conventions, create a package to hold the Project Euler code, for example: co.uk.temporalcohesion.euler.problems. Because we are going to need an interface, also create a package to hold those, as this can help keep things more organised, for example: co.uk.temporalcohesion.euler.interfaces

Let’s define that interface

public interface Problem {

	/**
	 * Answer method. Returns the answer for the problem
	 * @return - the integer answer to the problem
	 */
	String answer();

	/**
	 * The problem number.
	 * @return - The number of the problem
	 */
	int id();

	/**
	 * How long does it take to work out the answer?
	 * @return - The time in seconds it takes to work out the answer to the problem
	 */
	double time();
}

Before we move on an implement that interface in a problem, let’s write the basic problem runner itself. We’ll need a way to register an instance of a problem, and a way to run the problem and get the answer.

public class Euler {
	private List<Problem> problems = new ArrayList();

	public Euler() {
		problems.add(new One());
	}

	private void run() {
		for (Problem prob : problems) {
			System.out.println("Problem " + prob.id() + ": " + prob.answer());
		}
	}

	public static void main(String[] args) {
		new Euler().run();
	}
}

That’s pretty much all you need for a basic problem runner. You just register an instance of each problem you write into the problems List object in the constructor, and run the program, and it iterates through each Problem in the List, and outputs the answer.

I’m not going to give you the code to problem one, however it is pretty trivial if you know what the modulus operator is used for…

As you can see, the problem runner itself is fairly basic, and does present some immediate areas of improvement, such as running a specific problem.

I’ll cover that next time.

Project Euler problem runner framework in Java

Recently, I’ve been working on the problems on Project Euler, and I’ve done the first 16 problems (in Java), although I will freely admit that I had help on two of the most difficult ones. I do intend on continuing to do the problems, and I am currently working on problem 17, however I paused to write the problem runner framework I’m going to talk about in this post.

What I had started to do, was to write each solution in it’s own Class, and have the main(String[] args) method output the answer. This was fine for the first few problems, and I could have continued to do it like that for all of the problems – however I wanted to be able to run all the problems at once, or a specific problem, and get the answer(s), or not show the answers but still get the timings.

After chatting with one of the Senior Dev’s at my job, he pointed out that what I wanted to do was basically the Command pattern. He sent me some example code, although once he’d said “Command pattern” I knew exactly what it was that I needed to do.

Thus, my problem runner framework was born, and whilst fairly simple, it does employ some techniques that the beginning Java developer might not be aware of. So, what I am going to (try) to do over the next few weeks is write a series of posts that show how I wrote it, partly just to have some content on my blog (which I am really, really lazy at updating), secondly to see how good I am at explaining something like this, and thirdly – it might actually be useful to someone.

The output of the problem runner framework looks like this:

C:\development>java -jar euler.jar -noanswers
Project Euler : Problem Runner – http://projecteuler.net/

Problem: 1. Time: 0.0s
Problem: 2. Time: 0.0s
Problem: 3. Time: 0.347s
Problem: 4. Time: 0.307s
Problem: 5. Time: 63.803s
Problem: 6. Time: 0.0s
Problem: 7. Time: 0.335s
Problem: 8. Time: 0.0020s
Problem: 9. Time: 34.178s
Problem: 10. Time: 0.369s
Problem: 11. Time: 1.218275999017E9s
Problem: 12. Time: 0.021s
Problem: 13. Time: 0.0s
Problem: 14. Time: 21.717s
Problem: 15. Time: 0.0s
Problem: 16. Time: 0.0010s

As you can see, I have output a list of the problems, and the time taken to solve the problem, but I haven’t shown the answer.

Well, you didn’t think I was going to tell you the answers… Did you?

This also shows that I need to work on problem 5, 9 and 14 to try and optimise the solution to speed up performance, Project Euler says that problems “should” take under a minute to solve, however I’d still like to improve the code.