Every cutting optimizer calls itself “optimal”. We publish the numbers: three sets of test instances, an independent oracle for the small ones, provable lower bounds for the shop-floor ones, and the raw JSON with every parameter of the run. Last run: 2026-09-17, engine 6edd4c42bb6b.
▶ Open the calculatorNot one formula but a multi-strategy search over the same job: the fast heuristics (FFD, BFD, FFI, quantity ordering), pattern-based dynamic programming, shuffled FFD and GRASP with a fixed seed, look-ahead, and two bounded exact searches — one for few distinct lengths, one for short lists. Every candidate goes through local improvement (emptying bars and swaps), then the solution with the least material wins, fewest bars second. Budgets are counted in operations, not seconds — the result is identical on a fast or a slow server. We display it as the “best solution found”; we say “proven optimal” only when it meets the mathematical lower bound for the job.
Three sets of synthetic instances with a fixed seed (20260917), generated by tests/benchmark_optimal.py. (A) Exact-verifiable: 200 small instances (2–4 stock bars 60–130, 2–7 parts 10–65, kerf 0/1/3) with an independent oracle — full enumeration of every assignment. (B) Steel shop: 300 cut lists — 6000 mm stock (90 of them with a 6000 + 12000 mix), 8–30 distinct lengths 250–5800 mm at 1–20 pieces each, kerf 3 mm, min remnant 300 mm; 204 parts per job on average (from 55 to 393). (C) Scaling: 50, 200, 500, 1000, 2000 parts × 3 jobs. All modes run in a single process on one machine; time is time.perf_counter around the engine call itself.
On the small instances the oracle knows the true optimum. “Full match” also requires the same distribution of remnants across bars; “material + bars” is what you actually pay for; “min. bars” — whether the smallest possible number of bars was reached.
| Algorithm | Full match with oracle | Optimal material + bars | Min. bars | Median time (s) |
|---|---|---|---|---|
| Optimal | 100% | 100% | 100% | <0.01 |
| FFD | 42.5% | 74.5% | 84% | <0.01 |
| BFD | 42.5% | 74.5% | 84% | <0.01 |
| FFI | 32.5% | 62.5% | 76.5% | <0.01 |
| LOOK | 63% | 80.5% | 88.5% | <0.01 |
| GRASP | 64% | 79.5% | 88% | <0.01 |
| SFFD | 65.5% | 80.5% | 88.5% | <0.01 |
| Seq | 31% | 59.5% | 59.5% | <0.01 |
Here the true optimum is unknown — we compare against a lower bound: L1 = ⌈Σ(length + kerf) / (6000 + kerf)⌉ and the stronger Martello–Toth L2, which counts the parts above 3000 mm that cannot share a bar. “Proven optimal” = the solution meets the bound. With the mixed 6000 + 12000 stock we count in 6 m equivalents (a 12 m bar = 2) and only L1 applies, so the bound is looser there. “Optimal” is strictly better than FFD on 38.3% of the jobs, equal on 61.7% and worse on 0%; versus BFD it is better on 39.3%. Bars saved over FFD across the whole set: 973. Single-stock jobs only (210 of them): proven optimal 31.4%, average gap to the bound 1.67 bars, maximum 8.
| Algorithm | Avg bars (6 m eq.) | Avg waste | Proven optimal | Avg gap (bars) | Max gap | Median time (s) | 95th pct (s) |
|---|---|---|---|---|---|---|---|
| Optimal | 110.7 | 7.7% | 26.3% | 1.79 | 12 | 3.85 | 11.34 |
| FFD | 114.0 | 10.4% | 21.3% | 5.04 | 47 | 0.03 | 0.08 |
| BFD | 114.0 | 10.5% | 21.3% | 5.05 | 47 | 0.03 | 0.08 |
| FFI | 114.3 | 10.7% | 20.7% | 5.35 | 47 | 0.04 | 0.11 |
| GRASP | 114.0 | 10.4% | 21.3% | 5.02 | 47 | 0.23 | 0.66 |
| SFFD | 114.0 | 10.4% | 20.7% | 5.06 | 47 | 0.15 | 0.47 |
| Seq | 120.3 | 15.2% | 6.3% | 11.35 | 49 | 0.01 | 0.02 |
Median time in seconds over 3 jobs per size (single 6000 stock, same parameters as in B). The engine has built-in gates: look-ahead runs up to 240 parts, the exact searches up to 600, which is why time does not grow linearly with size. Sizes where “Optimal” exceeds 10 s: —.
| Parts | Optimal | FFD | BFD | FFI | LOOK | GRASP | SFFD | Seq |
|---|---|---|---|---|---|---|---|---|
| 50 | 0.21 | <0.01 | <0.01 | <0.01 | 0.10 | 0.02 | 0.01 | <0.01 |
| 200 | 6.74 | 0.01 | 0.03 | 0.02 | 2.90 | 0.26 | 0.16 | 0.01 |
| 500 | 4.02 | 0.24 | 0.25 | 0.25 | 0.17 | 1.49 | 0.94 | 0.03 |
| 1000 | 5.86 | 0.28 | 0.24 | 0.30 | 0.31 | 1.52 | 1.42 | 0.08 |
| 2000 | 7.61 | 0.31 | 0.68 | 0.31 | 0.38 | 4.17 | 3.69 | 0.44 |
The instances are random and synthetic. Uniformly distributed lengths of 250–5800 mm are harsher than a typical cut list — most parts above 3 m cannot share a bar, so waste is high for every algorithm; what matters is the difference between them, not the absolute value. A gap to the lower bound is not proven sub-optimality — the true optimum lies somewhere between the bound and the solution found. Timings come from one machine (Python 3.14.0); the server may be faster or slower. Real jobs differ — the surest test is your own cut list.
The script tests/benchmark_optimal.py (standard library + the engine only) is part of the application code, which is not public — we run the test ourselves. What is public is the raw result: benchmark-results.json (backend/benchmark_results.json in the code); the page reads its numbers from that file at start-up — nothing is typed in by hand. It records seed 20260917, the instance-generator parameters, the limits and the engine SHA-256 6edd4c42bb6b7ba0b5f9ee2f6d1b5f11e054c90d2c972b9a961082d945c91f4c. The full run (py -3 tests/benchmark_optimal.py) takes about 30 minutes. The “Optimal” algorithm is available on the Hobby and Pro plans; the free plan uses FFD and BFD from the same tables.
Because the lower bound is not the optimum itself. On a job with many parts above 3 m the bound underestimates the bars needed, so a solution can be optimal without us being able to prove it. On set A, where the optimum is known exactly, agreement is 100%.
With random lengths most bars fill up in an obvious way and any reasonable heuristic finds them. The difference comes on “tight” jobs with 2–3-part combinations that single-pass algorithms never see — that is where “Optimal” wins a bar or two, and per ton of steel that is real money.
No — the script and the engine are part of the application code and are not publicly available. What is public is the raw JSON at /benchmark-results.json with the seed, the generator parameters and the per-instance results; every number in the tables comes from it. The surest check is your own cut list: compare “Optimal” (Hobby/Pro) with FFD/BFD in the calculator.