# TDD rectangles

Jason and I had a rather interesting pair programming session last week where we tackled a problem that I found on Topcoder. It is in fact a slight twist (easier) on the actual topcoder problem as I didn’t have it to hand when we were pairing.

## The Problem:

Given a composite rectangle (composed of unit rectangles) of arbitrary dimensions, calculate the number of sub rectangles that can be composed from the unit rectangles. Remember squares are rectangles…

If that’s not clear enough, this diagram should help articulate what the problem is.

Here we can see that you can create 9 rectangles from the initial 2x2 rectangle.

## The Design:

Tackling this in a TDD-way we first had to decide on rough roadmap of test cases. The simplest test case seemed to be a invalid rectangle, 0 rectangles high or wide, or both.

Test cases:
-----------
1. Do not accept geometrically impossible rectangle


We’d then go on to a 1x1 rectangle, 1x2, 2x1, 3x1, 1x3, 2x2 and 3x2. Jason stressed that we were just sketching out a path we might take, it may not have been neccessary to use all the test cases, or maybe we’d need more; the list seemed like it would probably be sufficient for a full implementation.

The next step was to figure out how many subrectangles there were in each composite rectangle, this involved a bit of drawing and tallying. In the end I think I only miscounted one test case which we noticed fairly quickly when coding.

Test cases:
-----------
1. Do not accept geometrically impossible rectangle
2. 1x1 has 1 subrectangle
3. 2x1 has 3 subrectangles
4. 1x2 has 3 subrectangles
5. 3x1 has 6 subrectangles
6. 1x3 has 6 subrectangles
7. 2x2 has 9 subrectangles
8. 3x2 has 18 subrectangles


Having written our roadmap it was now time to start tackling this problem. We used Java, and JUnit with Eclipse.

The implementation up to 3x1 was fairly simple, however it started to get a little more tricky after that stage, it wasn’t immediately obvious what formula we should have been using, $$xy + (x-1)y + (y-1)x$$ seemed like a promising start, passing all the previous tests up until that point, addition of another term sounded like it might hold the solution, however it was difficult to think of what it could be, we didn’t come up with anything in the end.

Our design up until this point had been heading towards a solution in the form of return some_algebraic_formula, we changed tack and started looking at it in terms of combinations as we thought it might be a more successful avenue of attack. Jason suggested it might be as simple as a factorial, given that there are $$^n C_r$$ ways of ordering $$r$$ items from a sample of size $$n$$ and… $^n C_r = \frac{n!}{r!(n-r)!}$ Maybe not as simple as a single factorial, but we were definitely dealing with sequences and/or combinations. The problem with combinations is that they calculate all possible combinations including non-contiguous options (think first and last subrectangle of a 3x1). We didn’t discuss this at the time because a simpler solution presented itself.

Being Test Driven in design, we looked at our current test case, a 3x1 rectangle (I’ve illustrated a 1x3, imagine it’s just rotated!), after a bit of drawing and colouring it was evident that the number of subrectangles present in a column decreased by 1 for each unit increase in subrectangle length (refer to diagram). In the general case you have $$n + (n-1) + (n-2) + \ldots + 1$$ subrectangles per column where $$n$$ is the length of the column. We could iterate over each column and add either the general result of this formula ($$\Sigma_0^nr$$), or generate it on the fly with another loop. Initially it was simplest to just loop over columns and rows separately, instead of trying to take the larger step and implement the actual solution.

Our implementation now took the form:

The next test case: 2x2, introduced a new class of rectangles, 2D, the others had all been 1D in either the $$x$$ or $$y$$ axis. The previous implementation yields 5 subrectangles instead of 9. We looked at which ones it was counting, just the first row and first column – time to loop over the whole thing. Enclosing each loop with an outer loop iterating over either column or row depending on the inner loop and removing duplicates was a possibility, a very messy one, probably unlikely to succeed in being the general solution either. The algorithm needed to loop over both columns and rows (a nested loop?) and then calculate the number of possibilities, hopefully without counting duplicates.

After a bit of trial and error we managed to reach the general solution:

I like this, it’s rather clever. It’s easiest to understand given an example, let’s use the 2x2 rectangle we were trying to solve. The first column has 3 subrectangles, here’s what the code excecutes:

i = 1:
j = 1:
numberOfSubrectangles += 1;
// numberOfSubrectangles = 1;
j = 2:
numberOfSubrectangles += 2;
// numberOfSubrectangles = 3;


Looping over the first column we get 3 subrectangles, so good so far.

i = 2:
j = 1:
numberOfSubrectangles += 2
// numberOfSubrectangles = 5
j = 2:
numberOfSubrectangles += 4
// numberOfSubrectangles = 9

return 9


Through the second column, the subrectangles found in i = 1 are found again in this next column, however, we also need to take into account the rectangles that are formed along the rows, which there are 3 of, giving us a total of 6 additional subrectangles.

## Algebraic solution:

We had a solution! I like maths so I’ve found the algebraic solution from the code. Reasoning about loops of loops in mathematics is particularly aesthetically pleasing to me.

I’ll be using $$z$$ as the numberOfSubrectangles, it makes writing the maths easier. \begin{aligned} z &= \sum_{i=1}^x (\sum_{j=1}^y(ij)) \\ z &= \sum_{i=1}^x i(\sum_{j=1}^y(j)) \\ z &= \sum_{i=1}^xi(\frac{1}{2}y(y+1)) \\ z &= \frac{1}{2}x(x+1)\frac{1}{2}y(y+1) \\ z &= \frac{1}{4}xy(x+1)(y+1) \end{aligned}

You can literally change the Java code to return $$z$$, how pleasing :)

After tackling the problem with Jason, I had a go solving it mathematically a few days after and by then I’d forgotten the solution; I didn’t have much success at all. In this case I think developing in this way helped us to reach the insight that we should add i*j inside our nested loops. I don’t have the problem solving skills to incrementally build a solution mathematically, although I’m starting to aquire them in the domain of programming (very slowly), perhaps if I try and apply a TDD approach to maths I may get further with hard mathematical problems?