Repository navigation
s(176) ≤ 13.795872318437, s(211) ≤ 14.993694186584, s(241) ≤ 15.987134249051, s(304) ≤ 17.929427758076: registration request #575
Description
Credit name. Daniil Ostashev (https://github.com/dostashev, write-up: https://ostashev.ai/square-packing/).
Claim. Four feasible upper bounds (no optimality is claimed):
| n | new bound (certified, rounded up) | best public value we located (2026-10-13) | improvement |
|---|---|---|---|
| 176 | s(176) ≤ 13.79587231843640726331185405391207744387 | 13.807637226802, Francisco Couzo (franciscouzo/square-packing 93570ef, #561; seeded from our earlier 176). The case's house is 13.8128562532770564 (T-151). |
1.176e-2 |
| 211 | s(211) ≤ 14.99369418658324657063591818176125142354 | 14.99633672133631569465…, our own T-149 packing. Best by others: 14.997960704967, Evan Daniel's exact optimum of Joost de Winter's packing. | 2.643e-3 |
| 241 | s(241) ≤ 15.98713424905084041461665739745571396866 | 15.988132439524990848590591447359, Evan Daniel's exact optimum of Francisco Couzo's packing (the case's house) | 9.982e-4 |
| 304 | s(304) ≤ 17.92942775807517496566632613898911486244 | 17.929565946848500974381965343574, Nate Chaoweeraprasit's SQUISH packing as improved by Francisco Couzo (T-152, the case's house) | 1.382e-4 |
All four are new arrangements. 211 updates our T-149 entry with a different packing.
Certificate. dostashev/square-packing at commit b909e1b74cda50906e12b4373e010ddee39e47e4, directory records/:
nNNNN.sqpk: the packing, 60 significant digits. Its rows arecx cy theta_deg(centre, rotation in degrees), inside [0, s]².nNNNN.sqcert: an exact rational certificate. Its rows arex y twith 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 thesline.
SHA-256:
2b79553855e03f613130b6e88ccf788e1df5d0dbaed70e441f77fde3b5facadc records/n0176.sqpk
f70f484dfeb7057fd23c57859eac8d77bc4554e3d6aa6df1425ae5cdd2e9ef39 records/n0176.sqcert
0fac3226cd3e2ebbe1465c1fba2d9761e3e70b34dc174775cc0dfd856e0e0628 records/n0211.sqpk
7d35edaac371fd7b2a32517bd52dd0fd8b58d9ae9642008112496f80b58bf310 records/n0211.sqcert
bf99eee479060a868b8e7d063265a20ccc51bebc7e12cf7af0c6987a869ed950 records/n0241.sqpk
8d67da52a9445c38f28f5cea24169bcd3a421c39db581a5a5bf779c0d4cdf962 records/n0241.sqcert
534e5679d6253254bfe109db698ff997623272c644946455f5bb631c46de67cc records/n0304.sqpk
b87d0c9df7336872a2e0c26b761a1d7030b8850c2cf385bec43126f62c270c71 records/n0304.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.
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 four at δ = 1e-60.
- Minimum pairwise separation in the packing files: 5e-21 for 211 and 241, 4.995e-21 for 176 and 304.
sqverify --check-cert(GMP, exact, no dilation and no tolerance) on the shipped.sqcertfiles: all four certified.tools/crosscheck_mpmath.py(Python, mpmath at 80 digits, brute-force separating axes over the 8 vertex projections): all valid; minimum separations as above.
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, reached by two routes that agree. 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. 176, 211 and 241 come from one move: take a packing whose tilted squares form two separate bands, and re-harden it on the GPU (soft-to-rigid, after Yohei Nakajima's idea) with every square soft and the box held at its side. In each case the two bands merged into one V-shaped band. A second round was seeded from that V, followed by a converged polish and the exact optimum of the contact topology.
- 176: the seed was our earlier composition for 176 (s = 13.808663234387). It had s(175) ≤ 13.764174317487, s(232) ≤ 15.764174317487, s(264) ≤ 16.774735132388: registration request #528's 38-square (h + 2) × h piece and s(129) ≤ 11.870013850405, s(204) ≤ 14.808663234387, s(303) ≤ 17.909958291070: registration request #562's 44-square (h + 3) × h piece in opposite corners, plus aligned squares. The two pieces' half-bands merged through the junction into one V of 63 tilted squares. Francisco Couzo's 13.8076372 also started from that composition.
- 211: the seed was Evan Daniel's exact optimum of Joost de Winter's packing (bands of 48 and 25 tilted squares). They merged into a V of 76. This is a different V from our T-149 211 (14.99633672, from explicit V-band construction), which it replaces.
- 241: the seed was the case's house, Evan Daniel's exact optimum of Francisco Couzo's packing (bands of 47 and 32). They merged into a V of 85.
- 304 (added 2026-10-13): the same all-soft re-hardening, applied to a composition rather than a two-band packing. The seed was our composer's layout: a 55-square (h + 8) × h piece and a 68-square (h + 7) × h piece in opposite corners plus 181 aligned squares, at s = 17.939518. Its aligned blocks relaxed; the two tilted bands (53 and 42) stay separate, and no V forms. A second round followed, then a converged polish and the exact optimum of the contact topology.
Please credit Daniil Ostashev, and acknowledge the seeds' authors (Francisco Couzo, Evan Daniel, Joost de Winter) and the composition pieces' sources as you see fit.
AI assistance. Yes, the same setup as #528 and #562: an AI-assisted research loop that I drive with my own ideas. Re-optimising the junction so that the two bands merge into a V was my idea. AI agents wrote and ran the search and verification code; an agent extended the move from our compositions to published two-band packings.
Activity
[-]s(176) ≤ 13.795872318437, s(211) ≤ 14.993694186584, s(241) ≤ 15.987134249051: registration request[/-][+]s(176) ≤ 13.795872318437, s(211) ≤ 14.993694186584, s(241) ≤ 15.987134249051, s(304) ≤ 17.929427758076: registration request[/+]dostashev commentedon Oct 13, 2026
Update (2026-10-13): added s(304) ≤ 17.929427758076 to this request (table, SHA-256 and lineage above). The certificate commit is now
b909e1b74cda50906e12b4373e010ddee39e47e4; in it the 176, 211 and 241 files are unchanged (same SHA-256 as atb572f10).jlevy commentedon Oct 14, 2026
@dostashev, thank you. We have the four certificates at dostashev/square-packing b909e1b (records/n0176, n0211, n0241 and n0304), and all eight SHA-256 values match the files there. We retain the commit. Each certificate replayed and passed both of this project's maintained exact checkers, and both refused every control. At 176 and 304, your side is the smallest we know of. At 211 and 241 it is below the current register entry, but Francisco Couzo's #586 is smaller, by 1.35e-4 at 211 and 1.72e-5 at 241. Registration comes next.
Generated by Claude Code
intake: retain and replay Ostashev's #562 and #575 and Evan Daniel's #…
requests: record the 14 October replies and entries; read evand to 62…
jlevy commentedon Oct 14, 2026
@dostashev, thank you; this is the report-order evaluation of every open report at the counts #575 claims.
At each count, a report is recorded when its side is decidably below every side reported before it (and below the record on main); a tie stays with the earlier report. Sides are rounded up at 12 places.
Where this differs from our earlier reply, this evaluation replaces it: at 176, PR #574 reached this repository first with a side below this one, so 176 is not recorded here; at 211 and 241 this report came before #583 and #586, so it is recorded at both.
The registrations are in the records pull request #602, and a follow-up with the result ids and rungs will come once it is on main.
Generated by Claude Code
intake: retain and replay Ostashev's #562 and #575 and Evan Daniel's #…
jlevy commentedon Oct 14, 2026
@dostashev, thank you. With #602 merged, three of this issue's four packings are registered on
main:mainlists 176 for the owner, since your certificate was committed before PR research: submit 148 square-packing certificate refinements with exact endpoints #574 reached us.Evidence:
E-ostashev-575-certificate-report(your report, recorded). Onmain: RESULTS.md, the packet.Generated by Claude Code
requests: record #602's post-merge follow-ups and the 14 October verd…
intake: retain and replay Francisco Couzo's jlevy#561 certificates at…
intake: retain and replay Ostashev's jlevy#562 and jlevy#575 and Evan…
merge: the Ostashev and evand intake lane of 14 October (jlevy#562, j…
records: restate T-188 to T-190 against #614's houses, with their lin…
jlevy commentedon Oct 16, 2026
@dostashev, thank you. Where this request stands in the record on
main.Corrections to earlier replies.
What is registered.
On the case pages. Our reply of 14 October said adoption would follow the review. On 15 October 2026 T-175 became the house at 304, 1.38e-4 below the packing it replaces (Nate Chaoweeraprasit's, improved by Francisco Couzo, T-152), which stays retained as history. At 211 and 241 the house is Francisco Couzo's #586 continuation of your packings (T-182); T-175 stays verified there and is not selected.
Two later certificates are recorded at V0/C0 and not adopted: since #627 merged, Francisco Couzo's
487b058certificate at 211 (T-188), a further refinement of your arrangement, 9.29e-6 below T-182 and credited Couzo after Ostashev, Daniel, Levy, with your construction credit kept as his README and metadata give it; and, since 15 October, at 304, Mykhailo Polkovskyi's certificate of 14 October (T-186), 1.79e-19 below yours.Edited: an earlier version of this comment dated T-186 to #627; it was registered on 15 October.
Not registered.
On
main.packing/frontier/RESULTS.md,docs/project/reviews/review-2026-10-14-upper-bound-imports-561-593.md,packing/frontier/n-211.md,packing/frontier/n-241.md,packing/frontier/n-304.md.Nothing else you asked for is queued, so this issue is closed with this comment.
Generated by Claude Code
records: address review A of #637 (the #596 reply, corrected superses…