mirror of
https://github.com/ajisaacs/OpenNest.git
synced 2026-10-27 11:31:07 -04:00
ajandClaude Opus 5.5
4e0699de7a
ZeroClampMixedShapeLayoutIsBitIdenticalToBaseline has failed on Windows since it was added inde9a087while passing on Linux CI (bisect pointing atc374e02was an artifact: the assumed-good start commit fails too). No commit changed the layout; the two platforms always chose differently. In that fixture two candidate sheets (ContactPoint/Global and BestShortSide/Ordered) both place all 30 parts at the same cost, so Choose falls to its "more material placed" tie-break. SheetPacker summed material area in placement order, and the disc's area differs in the last bit between the Windows CRT and glibc math libraries. On Linux the two orders rounded to ...253 vs ...257, so the later candidate won on rounding noise; on Windows both rounded to ...257 and the tie fell to enumeration order as Choose documents. Sum a plan's area per type in type order instead (the same form as the engine's demand area), so plans placing the same parts get bit-identical areas and exact ties keep enumeration order everywhere. No tolerance is loosened. The Windows layout is unchanged; Linux now matches it, so the frozen hash moves to the Windows value, verified identical on both. Verified: full Engine.Tests pass on Windows and Linux (1105 passed, 2 skipped); Rectangles and Default benchmark results on the six synthetic nests are identical before and after (validity, placed parts, cost, utilization, plates). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>