s(129) ≤ 11.870013850405, s(204) ≤ 14.808663234387, s(303) ≤ 17.909958291070: registration request #562

Credit name. Daniil Ostashev (https://github.com/dostashev, write-up: https://ostashev.ai/square-packing/).

Claim. Three feasible upper bounds (no optimality is claimed):

204 and 303 are new arrangements. 129 keeps the aligned-block layout of Ryan Xu's packing, but its tilted squares sit in a different band (see Lineage), so it is a different local optimum, not a refinement of Xu's.

Certificate. dostashev/square-packing at commit fe43a64ecf2581cdbd11830e8a5be0989746c5d3, directory records/:

• nNNNN.sqpk: the packing, 60 significant digits. Its rows are cx cy theta_deg (centre, rotation in degrees), inside [0, s]².
• nNNNN.sqcert: an exact rational certificate. Its rows are x y t with t = tan(θ/2), so cos θ = (1−t²)/(1+t²) and sin θ = 2t/(1+t²), and every square is exactly a unit square. Centres and side are scaled by 1 + δ with δ = 1e-60. The side is the s line.

SHA-256:

fd79773bd5168dbb72846510b76522dc0e177f38f5e030353116b73608a999c4  records/n0129.sqpk
6ee26567f49a700822840807ea97947647bcdbf110e656041c0e2fe970624e72  records/n0129.sqcert
64f804cd98f3cfcf113582b14dce0a00d162c527097c4ff89b8ca790f9a60b01  records/n0204.sqpk
9d6261e7bbd83ddb8aee29e6f713c403e07d07e3e436f51ec09037b3c241ffa0  records/n0204.sqcert
9df683c6a24db53b91fa4ecf9f5bab1bf529a9aba99278574bbaa370dfd8ef59  records/n0303.sqpk
f8c22f3c00cf40bab8e6edd33ccd58f99f4837d5ccad717bbb1ef964986c3f58  records/n0303.sqcert

Checking. ./verify_all.sh in that repository reruns all of the checks below on every file in records/. It needs CMake, a C++20 compiler, GMP, MPFR, and Python with mpmath. It takes a few seconds after the build.

1. sqverify --precise --certify (C++, MPFR): containment and non-overlap by separating axes, then the exact certificate, built and checked in GMP rationals with no tolerance.
   • Accepted all three at δ = 1e-60.
   • Minimum pairwise separation in the packing files: 5e-21.
   • About 10–20 ms per file.
2. sqverify --check-cert (GMP, exact, no dilation and no tolerance) on the shipped .sqcert files: all three certified.
3. tools/crosscheck_mpmath.py (Python, mpmath at 80 digits, brute-force separating axes over the 8 vertex projections): valid, minimum separation 5.0e-21.

What the checkers share. All three were written by the same author, with AI assistance. Checks 1 and 2 share the C++ parser and the geometry code. Check 3 is a separate Python implementation, written independently, and shares only the file format.

Not done.

• No global optimality claim and no formalization.
• Each packing is the exact first-order optimum of its contact topology: nonnegative KKT multipliers at a 60-digit solution. The stored file is that optimum with the load-bearing squares scaled by 1 + 1e-20. No second-order or global check was made.

Lineage and credit. All three come from the library of best known packings of n unit squares in (h + d) × h rectangles described in #528.

• 204 and 303 are compositions: two copies of a new rectangle packing in opposite corners, with aligned squares filling the rest. We found both rectangles with the same GPU soft-to-rigid search as in s(175) ≤ 13.764174317487, s(232) ≤ 15.764174317487, s(264) ≤ 16.774735132388: registration request #528 (after Yohei Nakajima's soft-to-rigid idea), this time started from corner staircases (aligned corner blocks plus a tilted lattice) instead of random positions.
  • 204: two copies of 44 unit squares in an (h + 3) × h rectangle, h = 5.80866323438695656632… (the best we had before was 5.8387), plus 116 aligned squares.
  • 303: two copies of 62 unit squares in an (h + 6) × h rectangle, h = 5.90995829106990798142… (the best cut-out we had was 5.9306), plus 179 aligned squares.
• 129 is a cut-out. The library's 163-square (h + 3) × h entry was cut from the s(302) house (Nate Chaoweeraprasit's packing, Evan Daniel's regularization), then re-optimised as a rectangle, reaching h = 11.8700138504…. Dropping its three rightmost unit columns leaves 129 squares in an h × h square. Its aligned blocks are laid out like Ryan Xu's s(129), but its 29 tilted squares sit at 38.98–39.09° (17 of them, 9 at 39.09°), about 46.0° (2) and 50.7–51.8° (10). Xu's 27 sit at 39.41°, 43.99° and 50.59°.
  • Its side is 2.6e-12 below s(153) − 1 for PingYou's s(153) ≤ 12.870013850408: registration request #504 (12.870013850407044), whose band is at the same 39.09°. That packing holds at most 128 squares in any axis-aligned square of side s(153) − 1, so it does not imply this bound. No record or alternative file we collected (register, side packets, contributors' repositories) holds 129 squares in a corner square this small.

Each packing was then taken to the exact optimum of its contact topology. Please credit Daniil Ostashev, and acknowledge the pieces' sources as you see fit.

Not requested: 176. Our repository also has s(176) ≤ 13.808663234387: #528's 38-square block, the 44-square block above, and 94 aligned squares. Francisco Couzo has since improved it to 13.807637227056, starting from our packing (franciscouzo/square-packing e9eb44b), so we do not ask for 176.

AI assistance. Yes, the same setup as #528: an AI-assisted research loop that I drive with my own ideas. The rectangle library and composition was my idea. AI agents wrote and ran the search, composition and verification code, and an agent's check of the library against the register found 129.