Introduction
ASQAS34 is a perfect rectangle packing problem solved by Braam, Moes, Suilen, Van den Berg and Bhulai in 2016 and earlier (unpublished) by Giovanni Resta. I'm still working on this page, but our paper is here. I (Daan van den Berg) welcome all feedback you might have. Look me up in the UvAdirectory, on LinkedIn or FaceBook.
Q&A
1. What is ASQAS34 ?
ASQAS34 is a Perfect Rectangle Packing Problem. In general, rectangle packing problems involve putting a set of rectangles inside a rectangular frame (often called a "container"). Those problems requires that you find the smallest container possible, hence it is an constrained optimization problem. In perfect rectangle packing problems, the frame has exactly the same area of all the rectangles summed up. This means that if it fits, it fits perfectly, without free space or overlap in the rectangles, and a smaller container does not exist. Therefore, perfect rectangle packing problems such as ASQAS34, are constraint satisfaction problems (or equivalently: a decision problem).
There are five ASQAS problems in total, and they all consist of a serie of rectangles from 1x2, 2x3, 3x4 to NxN+1 which need to be fitted into an almostsquare frame. Four ASQAS problems had already been solved (ASQAS1, ASQAS3, ASQAS8 and ASQAS20). In our paper, we show that ASQAS34 is the last instance, and that it can be solved also. This is somewhat different from consecutive squaresinsquares, which has only two instances (1 and 24), the first one being completely trivial and the second one being unsolvable.

This is Asqas34: consecutive almostsquare tiles to be fit in an almostsquare frame. There are 5 instances of ASQAS, and ASQAS34 was the only unsolved instance yet.

2. Is it a hard problem?
That's a very difficult question. I don't know. First, we employed every trick we imagined, then wrote the best program we could and STILL it took us 80 fulltime calculation days on 1,000 computers. But then there's [Giovanni Resta], an Italian guy who solved the exact same problem on his desktop computer. So is Resta brilliant, or just lucky? Probably a little bit of both. Or maybe the problem isn't so hard after all. But if it wasn't hard, why did it take us so long? I just don't know, to be honest.
In general, it's very hard to say whether a problem is hard or not. For some problems (or problem instances, to be precise), we have a few hallmarks that make them easy: small statespace, highly constrained, high solution density, availability of clues or good heuristics. But the absence of these easehallmarks still doesn't mean a problem is hard; it means we don't know.
This problem has none of these hallmarks, or better: we haven't identified any. But since Resta's results and ours are so contradictory, we have absolutely no idea whether this problem is hard or easy. Maybe it depends on how lucky your are, or on where you look.

Left: solution found on the server of Cees van Leeuwen's [ lab for perceptual dynamics] in Leuven. Thanks to Marco Maas for helping out too. Right: solution found on the astronomical supercomputer ASTRON in Dwingeloo, The Netherlands

3. So how did you solve it?
First thing we did is take a look at the state space, which is the ensemble of all possible consecutions of the 34 rectangles in both horizontal and vertical positions. Even for this relatively small puzzel, the number of states is 10^48. In the worst case scenario, we would have to check all of them to find a solution. A very fast computer program can generate and check about a million of states per second, but even with a million of these computers, it would take about a billion times a billion times the lifespan of the universe to find a solution. That's too much. That's way too much.
So we needed some tricks to tip the odds in our favour. Such are called "heuristics" if they involve a(n educated) guess and "optimizations" if they just speed up the computation process. We pryed a valuable heuristic out of a smaller instance, the ASQAS20. This instance had 54,992 solutions (which maybe isn't that many) and most of these had borders consisting mostly of large tiles. We figured that this might be true for ASQAS34 instance too, so we decided to make all borders of 12 tiles.

Most of ASQAS20 solutions have large border tiles. In fact, tiles 14x15, 17x18, 18x19, 19x20 are in the border of nearly all 54,992 solutions.

3. Then what?
Then this and that and something else.
And then this and that and something else.

A distributed approach: All 12tiles borders were constructed first, then put in files, and then distributedly solved by 'supercomputers' around the country. It took 80 days on 1,000 computers to find all 15 solutions with 12tile borders.

4. You call yourselves an "VUUvA consortium". Why is that?
Because we are a true VUUvA collaboration. Mark, Florian and Emiel were VUstudents when we started this work. They're all professionals now, and Emiel does some occasional work in proofreading Heuristicsreports at the UvA. That's where I work, in the "minor programming" (www.mprog.nl) where we teach the course of Heuristics. That course was originally built up at the VU back when I worked there so there's another link. Our colleagues teaching Heuristics at VU are Guszti Eiben and Bushra Malik. Sandjai, our senior author, also works at the VU as a Full Professor Business Analytics. He works on statespace reductions which is exactly the trick we deployed to solve ASQAS34.

Lefttoright: Mark Moes, Emiel Suilen & Florian Braam who did most of the ground work. Bottom right is me (Daan van den Berg), I did coordination and wrote the paper's first draft. Top right is Sandjai Bhulai who also did some writing and took care of the entire publication process. A good team.
