Repository navigation
232, 260, 307: registration request #844
Description
Credit name. Francisco Couzo (franciscouzo/square-packing), for the refinements only. None of these three packings is my construction. Each starts from a packing another author published on Kaggle, and several of the improving steps ran other authors' code. Both are listed under Lineage and credit.
Claims. Each is the certificate's exact rational side, rounded up at 12 places. Global optimality is not claimed.
| n | claim | exact side | register's reported bound | improvement |
|---|---|---|---|---|
| 232 | s(232) ≤ 15.761661759482 | 7617348902520572307222120733/483283363059000000000000000 |
15.764174317487 (Daniil Ostashev, #528) | 2.51·10⁻³ |
| 260 | s(260) ≤ 16.637029558871 | 104381051573626493618357957479/6274019722347000000000000000 |
16.645753250520 (Evan Daniel's certificate, started from my packing) | 8.72·10⁻³ |
| 307 | s(307) ≤ 17.979251283689 | 2707897969116659515550794271467451840032974544063449693/150612387934832692306604131393579915999000000000000000 |
17.980862784055 (#593, Mishapolk) | 1.61·10⁻³ |
Part of each improvement is the starting packing's author's, not mine:
| n | starting packing (published side) | my part |
|---|---|---|
| 232 | Alex Chilton, 15.763381419802 | 1.72·10⁻³ |
| 260 | ntumlnoob, 16.638533455862 | 1.50·10⁻³ |
| 307 | ntumlnoob, 17.979253973651 | 2.7·10⁻⁶ |
Certificates. franciscouzo/square-packing@712c6a6 (full id 712c6a6e9ef58a9521784e6b7e236af813422de7):
| file | SHA-256 |
|---|---|
certificates/best/n232.cert |
23b035c34a5a93a3bf23eccaddc49e8d6e5e4003ec5e97c036153b2ca5ddbe54 |
certificates/n260.cert (same bytes as certificates/best/n260.cert) |
abd3b4e3bc4411de8b32e400f424645ad66f376dcba52ea8ba748ecdf83a0b11 |
n260.txt (the float packing) |
acab77d3986f0cc497b716a2eb9c9c5b7a4652dd5418e1bfbe80854ae4347d2d |
certificates/n307.cert (same bytes as certificates/best/n307.cert) |
1fd01ff42e7679f1e5b2c8eb8af59e51d3cca0392772b81bb4d78d67a26214e9 |
n307.txt (the float packing) |
7629bb297f4aabcf43111b28959c0578cdf35384758c507b608e4a0651c39843 |
Format: a header line n S, then one line x y t per square (centre, and t = tan(θ/2)), all exact rationals. Credits and lineage are in certificates/best/manifest.json for all three, and in certificates/n260.json and certificates/n307.json.
Checking. Both of the repository's exact checkers accept all three certificates, in exact rational arithmetic:
| checker | command | 232 | 260 | 307 |
|---|---|---|---|---|
verify_bound_certificate.py (separating axes, projection test) |
python3 verify_bound_certificate.py CERT |
valid and strictly valid; 3,108 candidate pairs, 554 near pairs; 0.2 s | valid and strictly valid; 3,354 candidate pairs, 618 near pairs; 0.1 s | valid and strictly valid; 4,359 candidate pairs, 699 near pairs; 0.2 s |
exact_finish.py (exact corner replay) |
python3 -c "from pathlib import Path; from exact_finish import exact_replay; print(exact_replay(Path('CERT')))" |
valid; 3,108 pairs; 0.4 s | valid; 3,354 pairs; 0.5 s | valid; 4,359 pairs; 0.6 s |
"Strictly valid" means positive wall and pair margins. All coordinates lie in [0, S]; no square is placed at large offsets.
What the checkers share. Both are this repository's code and read the same certificate format; their geometry tests differ.
Not done. No exact KKT solve, rigidity or local-optimality analysis. Only the upper bounds are claimed.
Lineage and credit.
Starting packings. Each starting side below is measured from the notebook's published decimal coordinates at 60 digits.
- 232: Alex Chilton's Kaggle notebook Fault-line DP + Basin Hopping - LB 22.2990 (run 362691257), side 15.763381419802. It reached my search through my Kaggle working set.
- 260 and 307: ntumlnoob (李秉叡)'s Kaggle notebook First 22.268681355 Public Code With Explanation (version 3, run 362957087), sides 16.638533455862 and 17.979253973651.
- The notebook labels both counts
cpu_refine_fq_only, its own refinement of a parent that is not published. - Its
SOURCE_NOTICES.mdcredits Alex Chilton's starter kit and dataset, David Ellsworth's records, Evan Daniel's catalogue and FQ/FTMC work, and public Kaggle portfolios (Nilanjan Saha, Malyshev Danil, Kirill T, lightningv08, kmmmvs, aqibrazadev, Chris Deotte and others).
- The notebook labels both counts
I could not trace any of the three further back.
What I ran, and whose code it is. All runs were on my computers, 27–28 October UTC.
- 232 (from 15.763381419802):
- GPU basin hopping, 3 improvements, 13:37–13:39, worth 5.1·10⁻⁴. The basin hopping is mine, but it relaxes with the overlap-energy kernel of Vladislav Lavrentev (lightningv08)'s Kaggle notebook "CUDA Packing Search" (Apache-2.0) and imports two helper modules from it.
- Native basin hopping and SLP, 2 improvements, 14:06 and 15:06, worth 1.21·10⁻³. The first of these was a candidate polished by Evan Daniel's fq.
- 260 (from 16.638533455862), in the web app:
- One structural move, 05:37, worth 2.9·10⁻⁴. It comes from an Ellsworth-style cycle modelled on David Ellsworth's tools (grid-snapping tolerances and strip shifts).
- 199 SLP steps, worth 1.21·10⁻³. The SLP is my own code; its LPs are solved with HiGHS (MIT).
- 5 fq steps, worth 9.4·10⁻⁷.
- Two native steps worth 3·10⁻¹² in total. The first only removed the clearance of my exact certification of the notebook packing.
- 307 (from 17.979253973651), in the web app:
- 4 fq steps, worth 2.69·10⁻⁶.
- 9 SLP steps, worth 5·10⁻¹².
- One native SLP step before them, which only removed the clearance of my exact certification of the notebook packing.
The web app's fq is a browser adaptation of Evan Daniel's fq optimizer (evand/square-packing 77f3c0ab47, search/packer/src/fq.rs, MIT).
Match against the starting packings (optimal assignment on centres, best of the eight square symmetries):
| 232 | 260 | 307 | |
|---|---|---|---|
| largest move | 0.404 | 1.095 | 0.145 |
| squares moving more than 0.1 | 8 | 134 | 1 |
| squares moving more than 0.01 | 80 | 220 | 14 |
| median move | 5.2·10⁻³ | 0.108 | 2.7·10⁻⁶ |
| tilted squares (this certificate / starting packing) | 84 / 132 | 107 / 111 | 108 / 107 |
Whether 232 and 260 count as new packings or refinements under your convention is your call; 307 is a refinement. Please also mention the code used: lightningv08's CUDA Packing Search and Evan Daniel's fq for 232; David Ellsworth's tools and Evan Daniel's fq for 260; Evan Daniel's fq for 307.
For information. Kaggle's staff per-puzzle leaderboard (run 363037199; coordinates not public) shows lower sides at all three counts for the team Cats and boxes:
| n | board side | submitted (UTC) | below this certificate by |
|---|---|---|---|
| 232 | 15.758852775326 | 27 October 09:33 | 2.81·10⁻³ |
| 260 | 16.635570520546 | 27 October 09:33 | 1.46·10⁻³ |
| 307 | 17.979230960422 | 27 October 00:05 | 2.03·10⁻⁵ |
Earlier runs show Amin at 232 (15.759131050186) and Chris Deotte at 260 and 307 (16.635570864625 and 17.979243728838), also below these certificates. Without coordinates I cannot certify or check them.
AI assistance. Yes. The searches ran on my computers under my direction. The certification, the comparison with the register and this report were done by Claude (Anthropic), working in Claude Code at my direction.
Activity
records: map the five stage 4 reviews of #852; T-260 split from T-259
jlevy commentedon Oct 31, 2026
@franciscouzo, thank you; this is the report-order evaluation of every open report at the counts #844 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.
franciscouzo/square-packing@a5a5d76franciscouzo/square-packing@a5a5d76Your a5a5d76 of 28 October, which no issue reports, publishes certificates at 260 and 307 first, so the ledger records them from that commit; this issue's three are each below everything before them and are recorded after them. At 260 Evan Daniel's #845, the next morning, is lower again. Measured here, this issue's 260 is a new arrangement found from ntumlnoob's packing through your a5a5d76 one, and its 307 your a5a5d76 packing mirrored and refined.
The registrations are in the records pull request #852, and a follow-up with the result ids and rungs will come once it is on main.
Generated by Claude Code
jlevy commentedon Oct 31, 2026
@franciscouzo, thank you for #844 and for the certificates of
franciscouzo/square-packing@a5a5d76. All five are imported and reviewed. The report-order verdict is in the comment above; this is where the record onmainstands.sqpack.verifyanddevtools.check_rational_witness_independent, throughdevtools.upper_bound_reports. The stage 4 review (review-2026-10-31-couzo-844-232-260-307.md) is an independent implementation:check_certs.py, a clean-room checker that uses two methods. Your own code was not re-run.n260.jsonstarts from the a5a5d76 certificate, and one Ellsworth-style move plus about 200 SLP steps take 170 squares beyond 0.1 of it. The record therefore calls it a new arrangement found from ntumlnoob's packing.Evidence entries.
E-couzo-844-certificate-report, this issue's three certificates as reported, is reviewed.E-couzo-844-exact-feasibility, the maintained routes' replay, andE-couzo-844-review-exact-feasibility, the review's checker, are confirmed.On
mainand the site.packing/frontier/RESULTS.mdn-232.md,n-260.md,n-307.mdThe review left three questions. An answer to any of them is welcome, but none holds this issue open:
Nothing you asked for is queued, so this issue is closed with this comment.
Generated by Claude Code
requests(#860, review A): T-259 names no finished owner; the confirme…
records(L63): the senior review's fixes to T-275 to T-279's records (…
jlevy commentedon Nov 9, 2026
@franciscouzo, a short follow-up to our closing reply of 31 October, which gave T-256 as current: the house best packing at 232 and 307.
Correction. T-256, your #844 certificates, s(232) ≤ 15.761661759482 and s(307) ≤ 17.979251283689 (with s(260) ≤ 16.637029558871), still stands as a verified bound, V3/C3, confirmed. It is no longer the best known at any count: on the frontier it now reads superseded.
What superseded it. Doğa Özden improved both packings, on #927 and #931:
Each pairs one to one with your packing under the identity. Both were confirmed at V3/C3 when #932 merged, and the cases at 232 and 307 adopted them as their houses on 9 November. T-256 is kept at both counts as history. You stay credited as an improver at both, with Özden after you: the case records name Alex Chilton as the finder at 232 and ntumlnoob at 307. At 260, as that reply said, your certificate was already not the house. #927 and #931 have their own replies.
On
mainand the site.packing/frontier/n-232.mdpacking/frontier/n-307.mdThe issue stays closed; this reply only brings what the record says up to date.
Generated by Claude Code
Merge pull request #933 from jlevy/claude/bold-ritchie-xo28us-l68