With no loss of generality, we may assume that the containers are numbered from ~1~ to ~N~. The following algorithm can be used to solve the problem for small inputs.

Algorithm GenerateAndTestDepot

Generate all permutations of numbers. For each permutation, generate the placement of containers in the depot using the method used by the worker and compare the placement with the input placement. Output all permutations, for which the generated placement is the same as the input placement.

Lemma 1. GenerateAndTestDepot solves the Depot problem.

Proof. Not a very interesting one…

However, GenerateAndTestDepot only works with fairly small numbers of ~N~. The rest of our solutions are based on the following idea. Make successive removals, recovering the state of the depot as if the removed item had been the last inserted item. Recovering the depot might involve pulling up items from rows below (as opposed to pushing them down when inserting items).

Algorithm BacktrackingDepot

For all items on the top row, call RecursiveDelete(inputdepot, item, solution) with empty solution.

• Procedure RecursiveDelete(depot, item, solution)

  If the item is the last item left in the depot, add it to the solution and output solution.

  If the item is not the last item left in the depot, then for all items on the first row, delete the item from the depot, add it to the solution, and call RecursivePullUp(depot, item, 1, solution)

• Procedure RecursivePullUp(depot, item, solution)

  If we are on the last row, then we just find all the items based on their values, which can replace the item on the previous row. For each such item found, remove that item and call RecursiveDelete(depot, newitem, solution) for all newitem values on the first row. (This is equal to finishing pulling up and continuing recursion.)

  If we are not on the last row, then we similarly find all the items based on their values, which can replace the item on the previous row. For each such item found, call RecursivePullUp(depot, newitem, solution) recursively.

Lemma 2. BactrackingDepot solves the Depot problem.

Proof. BacktrackingDepot tries out every possible way to delete all containers from the depot. That's it.

An unfortunate thing with BactrackingDepot is that it may be highly inefficient. In fact, it favours inputs where there are lots of short rows (optimally ~N~ rows with ~1~ item). However, with an input file with just one row of ~N~ items, the solution is no more efficient than GenerateAndTestDepot (as a matter of fact, due to implementational overhead, it is likely to be even slower than GenerateAndTestDepot). One obvious optimisation is readily available: As soon as there is only one row left, we can form the rest of the solution in linear time, as the items must have been inserted in the order where they are, as otherwise some item would have pushed some other item down. Already this in practice speeds the process up considerably.

Even with this optimisation, it is clear that the solution is inefficient. However, RecursivePullUp seems to be doing much extra work to what is really needed. A little investigation reveals the following lemma.

Lemma 3. Assume ~d~ is a depot with ~N-1~ items in it. Consider pushing down a value ~y~ from row ~r~ to row ~r+1~ with the insertion of value ~x~ to row ~r~ while computing a depot with ~N~ items. Then, clearly, ~x < y~ and for the value ~y'~ previous to ~y~ on row ~r~ before pushing, it holds that ~y' < x~.

Proof. Obvious from the way insertions are done.

From Lemma 3 we get the following lemma.

Lemma 4. Assume ~d~ is a depot with ~N~ items in it. Consider pulling up values from row ~r+1~ to row ~r~, while computing a depot with ~N-1~ items. Then, each value on row ~r+1~ can only be considered when finding the replacement for exactly one of the items on the row above.

Proof. Follows from Lemma 3.

With Lemma 4 we can slim down the search considerably. If we keep indexing for the depot showing which items can be pulled up from the row below for each item on each row, and only study those, then we speed up the search considerably. However, with smallish values of ~N~ (under ~15~) the optimisation does not really pay off, since the rows are so short. The same applies for using some asymptotically more efficient data structure for arranging the rows. Another algorithm is available using the following lemma.

Lemma 5. The last item to be positioned when an item is inserted is going to end up at the end of a row, and the row above it must not be shorter than the row below.

Proof. Should be quite straightforward to see.

Lemma 6. Any one of the items at the end of a row, where the row above is not equally long, may have been added last.

Proof. Follows quite easily using Lemma 5.

This suggests a similar search to the one we have proposed before, but starting from the bottom. The advantage is that we only start from such items that they can be moved up reversing an insertion, as opposed to the other method starting from the top, where we might start with an item which can not be the last item inserted.

Background

This problem was motivated by the theory of tableaux and permutations. The depot represents a Young tableau. A reader interested in the subject is encouraged to study the area from Knuth's book [1]. However, Knuth does not treat the problem of computing the permutations, which yield a given Young tableau. In his book a classical result is given, where it is said that there exist ~n^2~ different forms for a tableau with ~n~ items. From Lemma 6 and this it follows that there are only ~n^2~ possible numbers of solutions. Gyula Horvath [2] has studied these numbers empirically further than the authors, and suggested a variation of the task, where we only ask for the containers that could have arrived first.

We thank Isto Aho for helpful discussions, and Tero Karras, Janne Kujala, and Samuli Laine for test solving the task, and helping the authors to see some of the properties of the problem.

References

[1] Donald E. Knuth, The Art of Computer Programming, Vol. 3, Addison-Wesley, 1973.

[2] Gyula Horvath, private communication, 2001.