I should also say that, due to the information retained in the richer
type permitting inexpensive dispatch to specialized algorithms, fused
ops, and the use of retained numeric facts elsewhere throughout the
stack, hyperreal is one of the faster infinite precision math
libraries available.  It has a large benchmark corpus comparing a wide
variety of inputs to GMP and numerica@128bits - the fastest non-rust
and pure rust numeric crates I've tested so far, and hyperreal wins in
most.  It's still a fairly young stack of crates, so I'm always
looking for higher bars to benchmark against and new algorithms to
learn from.

Jordan,

I did not take it as a potshot. It is the central question, and your
follow-up identifies an important distinction that I did not make
clearly enough.

HyperReal can return Unknown for arbitrary scalar equality, but the
geometry stack does not reduce every question of geometric identity
to:

x1 == x2 && y1 == y2 && z1 == z2

There are at least three different questions that conventional
floating-point geometry often conflates:

Are these two references to the same topological vertex?
Are these two coordinate triples provably equal as mathematical values?
Are these two coordinate triples close enough to be treated as equal
for a particular display, manufacturing process, or user-selected
tolerance?

Grid snapping uses the third question as a substitute for the first
two. That can repair a false not-equal, but it can also manufacture a
false equal, exactly as you describe.

The Hyper stack keeps those questions separate.

For topological identity, hypermesh retains stable vertex identity and
construction provenance through transformations, triangulation,
splitting, and Boolean operations. If two faces refer to the same
constructed vertex, the system does not need to rediscover that fact
by comparing three coordinates. The shared identity is preserved.

For mathematical coordinate equality, most CAD work stays in an
especially favorable part of the number system. User-entered integers
and decimal dimensions are exact rationals. Finite IEEE-754 inputs can
be imported as exact dyadic rationals. Affine transforms,
interpolation at rational parameters, determinant calculations, and
most mesh processing continue to produce exact rational values.
Equality of those values is decidable.

When irrational constructions do appear, HyperReal retains the
construction rather than immediately rounding it. The comparison
cascade can then use, in order:

shared identity and construction provenance;
retained sign, zero, magnitude, and exact-set facts;
exact rational and dyadic reduction;
recognizable symbolic identities;
exact or indirect geometric predicates;
certified interval and error-bound tests;
increasingly precise computable-real refinement.

Quite a few apparently difficult comparisons are proved equal or
unequal before any approximation is required.

If two values are independently constructed, mathematically equal, and
not related by any available reducer or certificate, then yes: general
computable-real equality may remain Unknown indefinitely. No numeric
library or full CAS can provide a correct bounded-time answer for
every such expression. HyperReal does not claim otherwise.

But Unknown is not the same thing as "the geometry system has no
useful response." It means:

This particular mathematical equality has not been proved by the
available information and configured refinement policy.

The higher-level algorithm then has an explicit choice. Depending on
the operation, it can:

preserve the two vertices separately;
retain the unresolved relation and defer the decision;
request additional refinement;
use a topology-specific or indirect predicate;
apply an explicit application or machine-resolution tolerance;
or use a deterministic tie-breaking rule such as Simulation of
Simplicity without falsely claiming that the coordinates are equal.

The important difference is that any approximate or policy-based
decision remains visible as such. It is not silently converted into
mathematical equality.

So I would not claim that HyperReal has solved the undecidable
equality problem. The practical claim is narrower:

It preserves enough exact structure, identity, provenance, and
certificates that ordinary geometry almost never needs a universal
arbitrary-expression equality oracle.

This is also why I built the layers above Hyperreal. hyperlattice
retains object-level structure for points, vectors, matrices,
transforms, and determinant schedules. hyperlimit applies a cascade of
progressively more informative tests to geometric questions. hypermesh
preserves and validates topology rather than repeatedly reconstructing
it from rounded coordinates. The higher-level curve and mesh
algorithms otherwise look fairly conventional.

The practical evidence is that the stack is already performing full
CSG and mesh operations, and hypercurve performs union, difference,
intersection, XOR, offsets, trims, fillets, and related operations
over combinations of lines, arcs, conics, quadratic and cubic Beziers,
B-splines, and NURBS. SynapsCAD exercises OpenSCAD-style modeling on
top of the same system.

There will certainly be cases that expose missing reducers or require
better policy. Those are useful bug reports. But the current system is
not relying on Unknown as its normal answer. It is relying on
preserved structure so that equality and topology questions can
usually be answered by something cheaper and more informative than
arbitrary computable-real equality.

Put another way: the answer is not to invent a perfect equality
oracle. It is to stop throwing away the identity and mathematical
evidence that made most of the equality questions easy in the first
place.

Jordan,

You are right that preserving existing topology helps when multiple faces or
operations descend from the same constructed vertex, but it does not
by itself solve the harder case you describe: two independently
constructed shapes whose coordinates happen to denote the same
mathematical points.

That seam between independently constructed shapes is exactly where
the numeric representation has to recover coincidence rather than
merely preserve it.

There are three importantly different numeric cases here:

1. Exact rational and dyadic coordinates.

   Equality is completely decidable.

2. Algebraic irrational coordinates.

   Equality is also decidable in principle, using representations such
   as a defining polynomial plus an isolating interval, even when the
   values were produced by different constructions.

3. General computable-real expressions.

   Equality is undecidable in general. No implementation can always
   terminate and always return the correct boolean for every pair of
   such expressions.

Your particular example belongs to the second category, not the third.

If -45 degrees is converted exactly to -pi/4, then HyperReal knows:

sin(pi/4) = sqrt(2)/2
cos(pi/4) = sqrt(2)/2

and its radical reducers can simplify products such as:

sqrt(2) * sqrt(2)/2 = 1

So the literal transformation of [0,sqrt(2)] can reduce exactly to
[1,1]. The relevant scalar tests already pass. I am now adding the
end-to-end test that runs this through the OpenSCAD evaluator,
transformation machinery, and Boolean operation, because that complete
path is what actually matters.

Your parenthetical challenge is nevertheless correct:

make the example more complicated until it cannot recognize the
equality

Eventually one can construct two equal computable expressions for
which the available symbolic and algebraic machinery cannot prove
equality. At that point HyperReal returns Unknown.

The difference from f64 is not simply that HyperReal gets the wrong
answer less often.

An f64 comparison always returns a boolean, even when rounding has
destroyed the evidence required to justify it. It may report false
equal or false unequal. Grid snapping replaces mathematical equality
with a tolerance-defined equivalence, which can repair one class of
error while manufacturing the other.

HyperReal distinguishes:

CertifiedEqual
CertifiedDistinct
Unknown

That distinction is useful only if the geometry algorithms are written
to preserve it, which is what HyperLimit and HyperMesh are intended to
do.

For the touching-cubes case, matching four pairs of vertices through
four independent fuzzy comparisons would indeed be unsafe. Exact
welding should construct equivalence classes only from certified
equalities. Certified equality is transitive; epsilon closeness is not.
If one or more vertices remain Unknown, exact mode must not half-weld
the face and pretend the topology is valid.

A caller that requires a total answer then has an explicit choice:

• request additional certified refinement;
• use an algebraic or indirect geometric predicate;
• retain the unresolved coincidence until more context is available;
• apply a declared tolerance or symbolic-perturbation policy;
• or reject the operation rather than return corrupt topology.

A tolerance-based mode can still be useful, but it should be identified
as a policy decision rather than mislabeled as mathematical equality.
It should also perform global clustering or regularization rather than
independent pairwise epsilon comparisons, so that it cannot match two
corners of a face and fail to match the other two inconsistently.

You are also right that this has to apply to OpenSCAD expressions
generally, not merely to calculations that happen inside the geometry
kernel. That is why SynapsCAD has been converted so that mathematical
built-ins, user expressions, transforms, and generated polygon and
polyhedron coordinates remain HyperReal values rather than being
demoted to floats before they reach the kernel.

I audited the current regression coverage after reading your example.
The existing tests already cover:

• two independently constructed cubes touching on a complete face;
• separately indexed solids with the same surface geometry;
• exact merging of duplicate coordinate rows;
• refusal to weld distinct points separated by exactly 10^-15;
• equality of independently represented algebraic roots;
• overlap and Boolean operations involving irrational algebraic
  parameters;
• exact symbolic reduction of the sqrt(2) and pi/4 identities needed
  by your literal example.

All of those relevant tests pass.

The audit also found real gaps:

• the exact rotated-sqrt(2) example is not yet tested end to end through
  the complete OpenSCAD-to-Boolean path;
• the touching-cubes test does not yet explicitly inspect the output
  for residual triangles on the eliminated internal face;
• there is not yet a full closed polyhedron test in which every patch
  seam is supplied through independently duplicated coordinate rows.

Those are good tests, and I am adding them now. Passing SynapsCAD
tests include exact decimal and scientific literals reaching geometry
as rationals, rational arithmetic reaching mesh coordinates without
float demotion, symbolic constants and trigonometry surviving through
transforms, equality using HyperReal certification, exact rotation
cases, and symbolic rotated geometry retaining exact facts.

That gives good evidence that the OpenSCAD-facing arithmetic path
is actually using the exact-aware system, rather than merely
exercising the scalar library in isolation.

This is closely related to Chee-Keng Yap's "Towards Exact Geometric
Computation." Yap's framework emphasizes exact algebraic computation
and redesigning the numeric machinery around the actual needs of
geometric algorithms. Hyper extends the representation beyond
algebraic numbers to general computable reals based on Boehm's
"Towards an API for the Real Numbers", but that broader domain
necessarily makes equality partial.  Boehm did excellent work delineating
the decidable cases.

The practical design goal is therefore not to invent an impossible
universal equality oracle. It is to:

• keep topology-changing work in exact rational or algebraic domains
  whenever possible;
• preserve enough structure to prove equivalence across independently
  constructed expressions;
• use indirect geometric predicates instead of unnecessarily
  materializing coordinates;
• and clearly expose the rare cases where no bounded-time proof is
  available.

So the most precise version of my claim is: Hyper distinguishes proof
from policy.

It returns an exact answer when the retained mathematical structure can
certify one. When that is mathematically impossible in bounded time, it
does not silently turn a numerical approximation into topology.

Whether that covers practical geometry well enough is an empirical
question, and examples like yours are exactly the right way to test it.

Please keep them coming.

--
Timothy Schmidt

Jordan,

I think your final summary is basically right, with two important
qualifications.

For arbitrary computable-real expressions, no system can always decide
equality correctly and terminate in bounded time. HyperReal does not
eliminate that mathematical limitation.

In strict exact mode, it replaces:

sometimes return the wrong boolean

with:

sometimes decline to return a boolean

If an application absolutely requires a total answer, then somewhere it
must introduce a policy. That policy can still be wrong mathematically,
or the operation can fail. There is no third option that solves an
undecidable problem.

I do not want to obscure that.

The first qualification is that the undecidable domain is much larger
than the domain occupied by most CAD calculations. Rational and dyadic
equality are decidable. Algebraic-number equality is also decidable in
principle. Many constructions involving roots, polynomial
intersections, and recognizable trigonometric values remain in those
domains.

General user expressions involving arbitrary transcendental
constructions eventually exceed that boundary, especially in a
language such as OpenSCAD where users can perform essentially arbitrary
math before constructing geometry.

The second qualification is more important to the welding problem:
geometry should not construct topology by independently asking whether
pairs of vertices are equal.

In fact, even certified coordinate equality is not sufficient to imply
topological identity. Two different sheets, shells, or solids may
legitimately contain vertices at exactly the same point while remaining
topologically distinct. Whether they should be joined depends on the
operation and the surrounding cells, not just on the coordinate triples.

I think your face-welding observation points toward the right stronger
formulation:

identify and regularize the highest-dimensional coincident features
available, then induce the lower-dimensional equivalences from that
result.

For two cubes touching on a face, the kernel should not make four
independent vertex-welding decisions. It should determine whether the
two planar face regions are coincident with compatible boundaries and
opposite orientations. If that face equivalence is certified, the
corresponding edge and vertex equivalences follow from it.

For a polyhedron assembled from patches, the available feature may be
an edge rather than a face. The kernel should certify that the complete
edge or curve is shared, then induce the endpoint equivalence.

For eight cubes meeting around a central point, this cannot safely be
done face by face in an arbitrary sequence. The kernel needs to build
one global coincidence or arrangement structure, compute the complete
equivalence classes across all participating faces, edges, and
vertices, validate their incidence, and apply the quotient atomically.

That prevents the dangerous state you describe:

one face welded;
the adjacent face only partly welded;
one shared vertex now meaning two incompatible things.

Partial overlaps require splitting the cells first, after which the
resulting subfaces and subedges can be classified and regularized
globally.

This is closer to arrangement construction and cell-complex
regularization than to conventional "merge nearby vertices" processing.
Parts of HyperMesh already behave this way, but your examples suggest
stronger invariants and regression tests that should be made explicit:

• no equivalence class is committed partially;
• the result is independent of welding or traversal order;
• all induced edge and vertex identifications are incidence-consistent;
• no internal coincident sheet survives a regularized union;
• an unresolved class remains unresolved as a whole rather than
  becoming a half-welded topology.

Unknown therefore does not have to mean presenting the end user with a
modal dialog asking whether two incomprehensible expressions are equal.

It means the application owns an explicit policy.

For example, an OpenSCAD-facing application might use:

1. preserved construction identity;
2. exact rational, dyadic, and algebraic equivalence;
3. symbolic reduction;
4. indirect geometric predicates;
5. certified computable-real refinement;
6. global feature-level regularization;
7. only then, if a total answer is still required, a declared
   OpenSCAD-compatible tolerance or symbolic-perturbation policy.

The final policy can be selected once as an application mode rather
than delegated interactively to every user:

strict exact mode;
production/manufacturing tolerance mode;
preview mode;
compatibility mode.

The important difference is that the tolerance is the last explicit
policy layer. It is not silently treated as mathematical equality, and
it operates on complete candidate equivalence classes rather than on
unrelated pairwise vertex comparisons.

That does not make the fallback infallible. It makes it coherent,
deterministic, localizable, testable, and visible.

Chee-Keng Yap's paper "Towards Exact Geometric Computation" is very
relevant here:

https://www.sciencedirect.com/science/article/pii/0925772195000402

The general direction is to redesign geometric algorithms around exact
computation rather than attempt to repair an approximate algorithm
afterward.

On performance, I had exactly the same concern, and performance has
been a primary requirement from the beginning.

The common execution path is not a general symbolic algebra pass. Most
CAD values remain exact rationals or exact dyadics, and most geometric
decisions are certified by retained sign and magnitude facts or by an
integer numerator sign after rational reduction. The general
Computable machinery is semantic backing and an uncommon refinement
path, not the routine execution engine.

The results are not uniformly favorable, and I think the unfavorable
results are worth stating rather than hiding:

• Across the 53 workloads currently shared with the native-kernel
  harnesses, csgrs won 46 of 53 comparisons against CGAL EPECK, with a
  median competitor-time / csgrs-time ratio of 4.25x. It won all 53
  comparisons against the tested tight OpenCascade configuration, with a
  median ratio of 144.93x.
• The Boolean subset is a more useful comparison than the aggregate
  because some of CGAL's wins are in large-mesh import, graphics-buffer
  extraction, connectivity, and simple transforms, where the carrier and
  caching designs differ substantially. Across nine Boolean workloads,
  csgrs won six against CGAL, with a median ratio of 1.19x, and all nine
  against OpenCascade, with a median ratio of 73.31x. CGAL remains
  faster on a few trivial or heavily cached Boolean cases.
• HyperCurve has improved substantially and is no longer uniformly far
  behind the specialized curve libraries. On the 64-vertex star
  intersection it was 1.19x slower than Cavalier Contours. At 256
  vertices it was 1.66x faster, and at 1,024 vertices it was 2.55x
  faster than the fastest alternative. Small rectangle operations remain
  weak at about 5.4x slower.
• Some important HyperCurve operations still carry large premiums.
  Certified Bezier offsetting is currently much slower than Curvo's
  heuristic offset, and NURBS evaluation is about 29x slower than
  Curvo's f64 evaluator. Those comparisons have materially different
  correctness contracts, but the gaps are real and identify the next
  optimization targets.
• HyperLimit is presently about 12.6x to 12.9x slower than the Rust
  robust-predicate implementation on a 512-case finite-input orient2d
  batch. HyperLimit accepts general exact and symbolic Real inputs and
  retains certainty and evidence, while robust is a highly specialized
  adaptive-f64 implementation, but that does not make the performance
  difference disappear.

These are current engineering benchmarks rather than final
publication-quality measurements. The workloads are intended to be
equivalent, but the representations and correctness contracts are not
always identical. OpenCascade, for example, uses analytic
double-precision B-reps and includes tessellation in many rows, while
csgrs and CGAL are operating on exact-aware polygon meshes.

So exact-aware computation is not free, and I am not claiming that
every layer is faster than every specialized alternative. What the
end-to-end mesh and CSG results demonstrate is that it is not
inherently several orders of magnitude slower than conventional
geometry. On the current corpus, it is competitive with CGAL EPECK and
substantially faster than the tested OpenCascade path.

In that portion of the stack, exact rational and dyadic fast paths,
retained scalar and object facts, specialized dispatch, exact
topology, and avoided repair work collectively repay more than the
scalar representation costs. The remaining performance premiums are
concentrated in identifiable predicate and curve operations rather
than appearing as a uniform tax across the system.

I think your conclusion is therefore essentially right, but I would
phrase it this way:

The mathematical impossibility cannot be eliminated.

What can be eliminated is the habit of forcing an unjustified
yes-or-no answer and then silently constructing topology from it.

The region in which equality can be proved can be enlarged
dramatically. When proof runs out, the remaining ambiguity can be
handled globally, atomically, and under an explicit policy rather
than being allowed to masquerade as a proved topological fact.

And I think your observation about welding complete features rather
than independently welding vertices sharpens the implementation
considerably. The right operation is probably to construct a global
coincidence arrangement, determine complete face, edge, and vertex
equivalence classes, validate their incidence, and commit the
resulting quotient atomically. A kernel should never be left in a
state where one face has been welded, an adjacent face has been only
partly welded, and their shared vertices now carry inconsistent
meanings.

Thanks for discussing it.

--tim

An important consideration is how tolerant the geometry engine is of
"invalid" geometry - degenerate triangles, micro-gaps, non-manifold, et
cetera.  I don't know the details, but Manifold seems to be much more
tolerant than CGAL.  I also don't know how Manifold gains its tolerance;
it might be through the fuzzy matching that you are trying to avoid.

You talk about performance comparisons with CGAL.  In OpenSCAD's usage,
Manifold is far faster than CGAL; even beating CGAL by several times
would not put you in the same ballpark as Manifold. I haven't looked at
any benchmarks, but my guestimate is that one order of magnitude is too
low, and that two orders of magnitude might well be in the right range.

Changing subjects, you talk about doing operations on curves.

That's an area that interests me (though as a user, not as a
theoretician).  OpenSCAD currently always reduces curves to line
segments, and then operates on the resulting polygons and polyhedra. 
Using true curves seems appealing since it could radically reduce the
complexity of the model - but doing geometric operations on curves is
harder than the already-hard operations on polyhedra.  Do you allow
operations on true curves, or do you reduce them to line segments?

Those are both good questions.

On Manifold: you are right that CGAL is not the most important
performance comparison for OpenSCAD's current use case. Manifold is.

I have not yet integrated Manifold into the cross-kernel benchmark
harness, so I do not currently know how csgrs compares with it. I do
not want to infer an answer from the CGAL results. I intend to add
Manifold as a native competitor, ideally in both its serial and
TBB-parallel configurations, and separate import/conversion cost from
Boolean and result-extraction cost.

My reading of Manifold's design is that its robustness does not come
from simple fuzzy vertex matching. It separates exact topology from
inexact floating-point geometry, uses symbolic perturbation to resolve
ties, tracks an accumulated precision bound, defines epsilon-valid
geometry, and performs substantial degenerate removal and topological
cleanup.

Its core manifoldness guarantee still assumes manifold input. It can
attempt to merge slightly non-manifold imported meshes by matching open
edges within a precision, and it handles marginal geometry very well,
but it does not advertise arbitrary open or non-manifold triangle soup
as the normal guaranteed Boolean input.

That is a useful distinction:

input acceptance;
repair or regularization policy;
Boolean correctness;
and output manifoldness

are four separate questions.

An early version of HyperMesh explored the same general
Smith/Manifold-style Boolean family. It did not translate particularly
well to the exact-number and evidence model, so I discarded that path.
The current HyperMesh Boolean is based on an adapted EMBER-style
pipeline: adaptive subdivision, local exact arrangements, BSP
splitting, winding propagation, and certified output closure.

The strict HyperMesh core validates its input contract rather than
silently fuzzy-repairing arbitrary geometry. The broader csgrs/Hyper
stack can regularize some non-manifold constructions, including certain
open-sheet cases where the surrounding operation defines a closed
region, and certify the resulting manifold output. I would not claim
that every arbitrary invalid polygon soup can or should be accepted.

Degenerate triangles, micro-gaps, open sheets, inconsistent winding,
self-overlap, and non-manifold incidence are also different problems.
My preference is to diagnose them separately and make any repair policy
explicit. For example, in strict mode a mathematically nonzero
micro-gap remains a gap. A manufacturing or compatibility mode may
close it under a declared tolerance, but that is then a visible policy
decision rather than exact equality.

On performance, Manifold may indeed currently be much faster than the
CGAL backend used by OpenSCAD. I will not dispute an unmeasured result,
and I will not claim that beating CGAL means beating Manifold.

The project is also still quite young. I started csgrs a little over
two years ago. Roughly a year of investigation went into deciding that
the numeric layer needed to be replaced, and the Hyper stack itself is
only about six months old. End-to-end performance optimization of the
stack has only recently begun.

The implementation has already progressed through many orders of
magnitude in some paths. I still occasionally find easy wins in
Hyperreal, even though it is the lowest and most heavily optimized
layer. Hypercurve alone gained roughly two orders of magnitude across
several workloads over the last two days.

So Manifold does not strike me as an impossible target, but it is a
serious one, and the only useful answer will come from an equivalent,
reproducible benchmark.

Changing subjects: yes, Hypercurve performs operations on true curves.

It does not ordinarily reduce them to line segments before
intersection, trimming, offsetting, or Boolean operations.

The current native curve families are:

line segments;
circular arcs;
quadratic Beziers;
cubic Beziers;
rational quadratics and conics;
arbitrary-degree rational Beziers;
polynomial B-splines;
and NURBS, including periodic spline forms.

Closed CurveRegion2 boundaries may contain mixtures of those families.
Hypercurve performs native curve/curve intersection, overlap
classification, splitting, trimming, point classification, and
regularized union, intersection, difference, and XOR over the currently
supported topology.

The exact source curves, parameter intervals, split ranges, orientation,
operand ownership, and provenance are retained through the result.
Algebraic intersection parameters can remain algebraic carriers rather
than being rounded into finite coordinates.

There are still explicitly unsupported cases. In particular, some
independently parameterized shared curves require an implicit
multi-valued branch correspondence that the current implementation
cannot yet certify. Some free-form offset self-intersection trimming is
also incomplete. Those cases return typed blockers or uncertainty
rather than silently replacing the curves with sampled polylines.

Segmentation exists, but it is an explicit lowering operation. It is
used when a finite representation is actually required by a renderer,
triangle mesh, legacy file format, or physical machine. The segmented
result carries subdivision and chord-error evidence. It is not the
authoritative representation used by the curve Boolean.

SVG is an interesting case because ordinary SVG only has native path
commands for lines, elliptical arcs, quadratic Beziers, and cubic
Beziers. Hypercurve exports those commands normally where possible.

For the additional curve families, it emits a normal finite SVG path
for ordinary renderers plus a bounded, versioned
data-hypercurve-path metadata attribute. Hypercurve understands that
attribute and can therefore round-trip all eight native curve families,
their exact coordinates, and their properties without replacing them
with sampled line segments. Other SVG renderers simply ignore the
metadata and display the standard SVG projection.

Hypercurve is currently strictly two-dimensional. Spatial curves,
trimmed surfaces, and three-dimensional curve/surface relationships
belong in HyperBREP which is less than finished at the moment.

So the short answer is: Hypercurve keeps curves as curves while doing
the operation, and only converts them to line segments at an explicit
finite-output boundary.  That's one of the principal reasons I built
it.  I intend to carry the curves from design through toolpathing and
into motion control.  So retaining them for compound operations like
offsetting or booleans is also required.  Occasionally a trimmed or
offset curve is promoted or demoted to another curve type as a result
of the math.

You can experiment with the current exact mixed-family curve Booleans,
offsets, editing, and segmentation here:

https://timschmidt.github.io/hypercurve/

--tim