Skip to content

Failing test: exponent notation is split into a value plus a phantom E extrusion (#368) - #369

Open
remcoder wants to merge 1 commit into
developfrom
failing-test/exponent-notation
Open

Failing test: exponent notation is split into a value plus a phantom E extrusion (#368)#369
remcoder wants to merge 1 commit into
developfrom
failing-test/exponent-notation

Conversation

@remcoder

Copy link
Copy Markdown
Member

Adds a failing test for #368. CI will be red on this branch by design — do not merge as is.

The point is to pin the bug down as executable spec rather than prose, so whoever fixes the tokenizer has a target that goes green.

The failure

AssertionError: expected { x: 12, e: 5, y: 5 } to deeply equal { x: 1200000, y: 5 }

G1 X12e5 Y5 — the tokenizer splits a word at every letter, so the e of the exponent is read as a separate E parameter.

Why the fabricated e is the damaging part

This isn't just a lossy coordinate. Interpreter derives the path type from e:

const pathType = e ? PathType.Extrusion : PathType.Travel;

So the line is interpreted as a move to X12 that extrudes 5mm of filament:

  • a travel move renders as extruded filament, drawing a solid line where the print has none
  • extrusionDistance is inflated by 5
  • the segment lands in an extrusion path, so it also stretches the bounding box

All silent — no parse error, no warning.

About the expectation

The test asserts option 3 from #368 (recognize exponent notation in the tokenizer), i.e. x: 1200000 and no e. If the team prefers option 2 (reject a word whose value is followed by a valueless letter), change the expectation to x being absent. Either resolution has to remove the fabricated e, which is what the test really guards.

Option 1 in #368 is "leave it, document it" — if that wins, close this PR and land a characterization test asserting the current {x: 12, e: 5, y: 5} instead.

Likelihood

Low: G-code has no exponent notation, and no slicer emits it. The realistic route is a generator doing naive float-to-string on an extreme coordinate, since String() reaches exponent form by itself — String(1e21) is '1e+21', String(1e-7) is '1e-7'.

Relationship to #367

Independent and pre-existing; this branch is off develop, not the #367 stack. #367 does not change this behavior. The characterization test for it was deliberately kept out of #367 so the current behavior isn't locked in before this is decided.

This test fails on purpose. It documents the bug as executable spec rather
than prose: `G1 X12e5 Y5` parses to {x: 12, e: 5, y: 5} because the tokenizer
splits a word at every letter, so the `e` of the exponent becomes an E param.

That fabricated `e` is the damaging part. Interpreter derives the path type
from it (`e ? Extrusion : Travel`), so a travel move renders as extruded
filament, inflates extrusionDistance, and stretches the bounding box.

CI will be red on this branch until the parser is fixed. Do not merge as is.
@github-actions

Copy link
Copy Markdown

Visit the preview URL for this PR (updated for commit 7ec2e7f):

https://gcode-preview--pr369-failing-test-exponen-57rcjimx.web.app

(expires Mon, 21 Sep 2026 16:40:03 GMT)

🔥 via Firebase Hosting GitHub Action 🌎

Sign: 59bd114ae4847b32c2bba0b68620b9069a3e3531

@remcoder remcoder added the bug Something isn't working label Aug 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant