Skip to content

fix: straighten segments left slightly off-axis by imprecise pin input - #722

Open
DPS0340 wants to merge 1 commit into
tscircuit:mainfrom
DPS0340:fix/near-orthogonal-segments
Open

fix: straighten segments left slightly off-axis by imprecise pin input#722
DPS0340 wants to merge 1 commit into
tscircuit:mainfrom
DPS0340:fix/near-orthogonal-segments

Conversation

@DPS0340

@DPS0340 DPS0340 commented Jul 25, 2026

Copy link
Copy Markdown

The defect

Two boards render a visibly skewed trace. Measured across every imported bug report:

bug-report-20260717T022934Z  diagonalSegs=1
bug-report-20260716T144856Z  diagonalSegs=1

Schematic traces are orthogonal by construction, so any non-axis-aligned segment is a bug. The offenders:

SJ2.1-R3.2: (5.3999,1.9500) -> (5.4000,1.5000)   dx=6.22e-5  dy=-4.50e-1
JP2.1-R5.1: (5.4999,-8.4500) -> (5.5000,-9.2000) dx=6.22e-5  dy=-7.50e-1

Identical dx on both, which pointed at the input rather than the routing. It is:

SJ2.1  x = 5.3999378      <- off by 6.22e-5
R3.2   x = 5.4

A pin coordinate arrives a fraction of a mil off its neighbour. Tracing it through the pipeline, the skew is present from schematicTraceLinesSolver onward and no stage corrects it — the solvers assume orthogonality rather than enforcing it, so nothing notices.

Fix

A TraceCleanupSolver pass that snaps segments within 1e-3 of an axis onto it exactly, collapsing the smaller deviation and moving the later point so the trace's starting pin stays where the input put it.

On the threshold: 1e-3 is two orders of magnitude below LABEL_SEARCH_STEP (0.1), the smallest deliberate jog any solver makes. A genuine diagonal is never flattened — the guard requires one axis to be within tolerance while the other is not.

I put it in TraceCleanupSolver rather than in cloneAndCorrectInputProblem deliberately. Snapping pins at input time would move the pins themselves, which affects chip bounds and every downstream placement decision; snapping the rendered segment fixes the symptom without perturbing the problem the solvers were given.

Result

diagonal segments:  2 -> 0

And confirming nothing else moved:

labels inside chips:  8 -> 8
label-label overlaps: 7 -> 7
trace crossings:     40 -> 40

Verification

  • Full suite 148 pass / 0 fail / 4 skip, tsc --noEmit clean, biome clean.
  • 4 snapshots regenerated. I checked the diff rather than accepting it: the change is exactly the intended one —
    - data-points="5.3999378,1.9499… 5.4,1.5000…"
    + data-points="5.3999378,1.9499… 5.3999378,1.5000…"
    
    the x now matches and the segment is vertical. No other geometry changed.
  • Note biome check --write reformats 9 unrelated files in this directory; I reverted those so the diff stays reviewable.

Diff: 1 new file, 1 source file touched, plus the 4 snapshots. Independent of my other open PRs.

@vercel

vercel Bot commented Jul 25, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
schematic-trace-solver Ready Ready Preview, Comment Jul 26, 2026 4:37am

Request Review

Two boards render a visibly skewed trace because a pin coordinate in the
input is off by a fraction of a mil from its neighbour (5.3999378 against
5.4). Schematic traces are orthogonal by construction, so the solvers never
correct it and the skew survives to the output.

Adds a TraceCleanupSolver pass that snaps segments within 1e-3 of an axis
onto it exactly. The threshold sits two orders of magnitude below the
smallest deliberate jog in the solvers (LABEL_SEARCH_STEP, 0.1), so a real
diagonal is never flattened.

Diagonal segments across the imported bug reports: 2 -> 0. Label placement
and trace crossing counts are unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant