Adaptive plans differ across platforms on the same commit (likely libm last-place rounding)

Open
  • Is something wrong?
#1,010 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
performance, testing

Research direction

Start by reading the adaptive bore test app pocket3d_hsm::the_users_bore_roughs_adaptive_level_by_level_and_verifies_clean and the planner and geometry call sites for sin, cos, atan2, hypot, exp, and powf. Run the test on a second platform and compare which calls diverge. Done means confirming the cause, then either making outputs platform-identical and re-measuring the adaptive fixtures or recording the decision not to.

Written by the indexing model from the issue text.

Description

area:2d area:3d bug effort:max P2 source:agent

Found while working #984.

What happens: the same commit plans the same part differently on two platforms. app pocket3d_hsm::the_users_bore_roughs_adaptive_level_by_level_and_verifies_clean (release) on ecb54b7f:

platform rings levels moves / planar / arcs
Windows (the #850 measure, PR #865) Z 20.000 5530 / 5497 / 600
macOS, Apple silicon (Homebrew rustc 1.99.1) Z 20.000 (crossing at -2.33, -2.78) 5786 / 5753 / 651

macOS is deterministic run to run, so it is not hash-map order. Rust does not contract a*b+c into FMA unless asked, so the most likely cause is the platform libm: f64::sin, cos, atan2, hypot, exp, powf call the system math library (MSVC CRT, glibc, Apple libm), which are not correctly rounded and differ in the last place. The STEP tessellation and the adaptive planner both use them, and the planner's crossing and acceptance tests are knife edges a 16 nm change flips (#882, #982). Not yet confirmed which call sites diverge, and not run on Linux.

Why it matters: a toolpath (and so the posted G-code) for the same part, tool and parameters depends on the OS the user runs. Every output is still verified and a crossing plan is refused by name, so this is not a gouge; but golden counts and exact plan pins cannot hold across platforms, and a user can see a different path from the same project file on two machines.

Possible directions (open): route the geometry and planner transcendental calls through a pure-Rust deterministic libm (the libm crate is already in Cargo.lock) so every platform rounds the same; or make the planner's decisions robust to sub-micron perturbation (#882, #982). Either changes toolpaths and needs every adaptive fixture re-measured.

Done means: the cause is confirmed on a second platform (Windows or Linux run of the bore test, plus which calls diverge), and either the output is made platform-identical with goldens re-measured, or the decision not to is recorded.

Refs #984, #882, #982.

Dominant language
Rust
Stars
8
Forks
11
Avg merge
5h 22m
Merged PRs (30d)
409

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NeoTech/Camcraft

All issues in NeoTech/Camcraft

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.