Skip to content

v0.11.0 — Exact curve inversion and Cartesian trim resolution

Latest

Choose a tag to compare

@GeneralPawz GeneralPawz released this 05 Sep 16:19
· 14 commits to main since this release

Exact curve inversion, so a trim stated as a point resolves.

Added

  • axiolid_evaluate::curve::invert2 / invert3, re-exported as axiolid_reference::curve::{invert2, invert3}. The exact point-to-parameter map for lines, circles and ellipses. Curves already had evaluate, derivative and jet; inversion was the missing direction.

Fixed

  • CurveRelation::Trimmed with TrimmingPreference::Cartesian now resolves. Point selectors were validated and stored but never read, so every point-trimmed curve passed graph validation and then failed to compile with trimmed directrix start needs a finite parameter selector. Formats that can only state a trim as its endpoints -- a three-point arc knows its endpoints, not their parameters -- were representable but not usable.

Exactness policy

Families with no closed-form inversion are refused by name rather than iterated. Newton in trim resolution would put a tolerance and a convergence failure mode into every consumer of a point trim, and would collapse the three-valued verdict certified inversion produces (unique / ambiguous / off-surface) into a bare Scalar, discarding the evidence that makes it trustworthy. axiolid-nurbs stays out of the compile path; certified iteration remains available to callers that can carry its certificate.

A point off the curve is refused with its residual rather than projected onto the nearest parameter. The conic path needs this specifically: the arctangent yields a plausible angle at any radius, so only re-evaluating and measuring catches a point at the right bearing and the wrong distance.

A basis that is itself a curve relation has no analytic curve to invert against. A parameter selector still resolves there; a point selector is refused by a message that says why.