An Almost-Optimal Upper Bound on the Push Number of the Torus Puzzle

TL;DR

This work advances the understanding of the push number for the Torus Puzzle by presenting an algorithm that sorts sortable $m \times n$ matrices using $O(mn \log \max\{m,n\})$ unit rotations in a restricted model, thereby narrowing the previously wide gap between known upper and lower bounds. The approach decomposes the sorting process into four phases that progressively organize the matrix: ensuring near-full columns, converting to body-full, sorting column bodies with a parallel RadixSort-inspired technique, and finally fixing the first row via permutation decomposition into involutions using SwapPairs. The result achieves a nearly optimal upper bound up to polylog factors, and the paper discusses implementation details, extensions to direction-specified variants, and open problems about tight bounds and optimization complexity. Overall, the method provides a concrete, scalable framework for improving push-number bounds in permutation-based torus puzzles with potential implications for related rotation puzzles and Cayley-graph diameter problems.

Abstract

We study the Torus Puzzle, a solitaire game in which the elements of an input $m \times n$ matrix need to be rearranged into a target configuration via a sequence of unit rotations (i.e., circular shifts) of rows and/or columns. Amano et al.\ proposed a more permissive variant of the above puzzle, where each row and column rotation can shift the involved elements by any amount of positions. The number of rotations needed to solve the puzzle in the original and in the permissive variants of the puzzle are respectively known as the \emph{push number} and the \emph{drag number}, where the latter is always smaller than or equal to the former and admits an existential lower bound of $Ω(mn)$. While this lower bound is matched by an $O(mn)$ upper bound, the push number is not so well understood. Indeed, to the best of our knowledge, only an $O(mn \cdot \max\{ m, n \})$ upper bound is currently known. In this paper, we provide an algorithm that solves the Torus Puzzle using $O(mn \cdot \log \max \{m, n\})$ unit rotations in a model that is more restricted than that of the original puzzle. This implies a corresponding upper bound on the push number and reduces the gap between the known upper and lower bounds from $Θ(\max\{m,n\})$ to $Θ(\log \max\{m, n\})$.

Figures (8)

• Figure 1: A sortable input instance of the Torus Puzzle (left); the configuration obtained from the input configuration by performing a unit rightward rotation of the first row, followed by two unit downward rotations of the first column (middle); and the target configuration, i.e., the one in which the matrix is sorted (right). Elements belonging to different columns in the target configuration have different hues, while elements belonging to different rows have different lightnesses.
• Figure 2: Left: A screenshot of the RotSquare application for Max OS X by Takeshi Ogihara. Right: a physical puzzle in which eight colored sections of a Torus can rotate in 90-degree increments along the shorter dimension, while the two halves of the torus delimited by a horizontal plane passing through the center can rotate along the long dimension. The puzzle resembles a $4 \times 8$ instance of the Torus Puzzle in which some elements are indistinguishable and two pairs of adjacent rows rotate together. The photo was posted in 1995 to MIT's CubeLovers mailing list kinsman_cubelovers and is reproduced here with the author's permission.
• Figure 3: An input instance $A = A_0$ of the Torus Puzzle (left), and the matrices $A_9$ and $A_{17}$ corresponding the arrangement of the elements in $A$ at end of the ninth and of the last iteration of the outer while loop of FillColumns (middle and right, respectively). Elements are colored according to their target columns. A bold segment on each column $C_j$ indicates the number of rotations of $C_j$ performed by FillColumns until the shown configuration. A small gap has been added under row $R$ for improved visual clarity. Notice how all columns in $A_{17}$ are near-full.
• Figure 4: A possible input to FloatMinimums, which corresponds to the output of FillColumns in Figure \ref{['fig:fillcolumns']} (left), and the resulting output (right). Elements belonging to different columns in the sorted configuration have different hues, and elements $x$ with $\mathop{\mathrm{t-row}}\nolimits(x)=1$ are lighter. Notice how all columns of the output are body-full.
• Figure 5: A possible input matrix for an execution RadixSortBodies sorting $C_1$ and $C_2$ (top left) which coincides to that output by FloatMinimums in Figure \ref{['fig:floatminimums']}, along with the configurations resulting after the first, second, and third sub-phases of the first phase of RadixSortBodies (top middle, top right, and bottom left, respectively). The remaining two configurations are those at the end of the second phase of the algorithm (bottom middle), and at the end of multiple calls to RadixSortBodies which sort all column bodies. The elements $x$ that belong to the bodies of $C_1$ and $C_2$ in the input configuration are shown in red and yellow, respectively, while their lightnesses represents whether the relevant bit of $\mathop{\mathrm{t-row}}\nolimits(x)-2$ is set (a brighter color corresponds to a set bit). The configuration on the bottom right colors elements according to their target position.

Theorems & Definitions (14)

• Remark 1
• Lemma 2
• Lemma 3
• Lemma 4
• Corollary 5
• Lemma 6
• Lemma 7
• Lemma 8
• Lemma 9
• Lemma 10