53 Tests Against CGAL: Can Holo Engine Handle Geometry, 3D and Crypto?

The Question

Computational geometry and elliptic curve cryptography seem like distant cousins. One deals with circumcenters, orthocenters, and collinearity. The other with scalar multiplication, ECDSA signatures, and point orders on secp256k1. In practice, they share a common foundation: exact algebraic computation over structured fields.

Holo Engine's geometry_solve API handles both in a single DSL. You write LET O = CIRCUMCENTER(A, B, C) the same way you write LET P = EC_MUL(12345, G). The engine parses, computes, verifies, and emits an exact-arithmetic accuracy certificate — all in one call.

This raises a natural question: how does a unified DSL-based engine compare to specialized libraries that have been optimized for years?

We ran 68 stress tests across six libraries. No cherry-picking. Here's what happened.

Methodology

Libraries

• Holo Engine — DSL-based geometry + EC solver via POST /api/geometry_solve. Rust backend, exact rational arithmetic (Ⅎ), exact-arithmetic accuracy certificate per result.
• SymPy — Python symbolic mathematics. sympy.geometry module for 2D and 3D constructions. Pure Python, widely used in education and research.
• NumPy — Vectorized numerical linear algebra. Used as the floating-point coordinate oracle for the 3D construction benchmarks.
• trimesh — Specialized triangle-mesh kernel for 3D geometry. Computes cross-sections of watertight meshes — the industrial baseline for mesh plane-sections.
• ecdsa — Pure Python elliptic curve library. The de facto standard for EC operations in Python. Used in Bitcoin Core test suite.
• pycryptodome — Self-contained Python cryptographic library. Supports secp256k1, NIST curves, ECDSA, ECDH.

Test Suite

68 tests across five categories, designed to push each library to its limits:

The DSL

Holo Engine accepts a single DSL string that defines points, constructions, constraints, and goals. The engine computes all derived points, checks all constraints, and returns coordinates + an exact-arithmetic accuracy certificate:

One API call. The engine returns computed coordinates, constraint satisfaction results, and an accuracy certificate with exact residuals reporting whether every constraint verified exactly. No other library in this benchmark produces a comparable verifiable certificate.

Environment

All experiments ran on the same machine (macOS, Python 3.11+). Holo Engine ran as a local HTTP server on port 8080. SymPy, NumPy, trimesh, ecdsa, and pycryptodome ran in isolated Python subprocesses with per-backend timeouts, so a single hang or failure never stalls the suite. Timing includes all overhead (HTTP, JSON parsing, DSL parsing). For Holo Engine's pure compute time, see the MCP Direct section.

Part 1: Geometry — 8 Classical Theorems

We start with 8 classical geometry theorems — the kind of problems that appear in CAD systems, architectural software, and robotics. Each test involves constructing derived points (circumcenters, orthocenters, centroids) and verifying a geometric invariant.

Stewart's Theorem is the only test where SymPy is faster — the computation is trivial (one distance() call), and Holo's HTTP overhead (~5ms) exceeds the actual compute time. For everything else, Holo is 2.5× to 16.7× faster.

Part 2: Verification — Exact Symbolic Checks

Verification tests are harder: instead of computing a single construction, the engine must verify that a geometric invariant holds exactly. This means symbolic algebra — the bread and butter of SymPy.

SymPy takes 858ms on triangle inequality — a problem that requires checking three distance inequalities simultaneously. Holo solves it in 29ms, including HTTP overhead. The gap widens with problem complexity: Stewart's theorem verification is 40.7× faster.

Part 3: Elliptic Curves — Rust vs Pure Python

Elliptic curve operations are the backbone of modern cryptography: Bitcoin, Ethereum, TLS, and SSH all rely on EC point arithmetic over finite fields. We tested 5 core operations on secp256k1 (the Bitcoin curve).

Holo Engine generates a key pair (scalar×G) faster than both ecdsa (27.9ms) and pycryptodome (131.9ms) — 22.2ms — even over HTTP. This is Holo's Rust backend handling modular arithmetic natively.

Part 4: Stress Tests — Pushing the Limits

The stress tests are where things get interesting. We pushed each library to its limits: 20+ construction chains, 15 simultaneous constraints, 10¹⁵ coordinates, near-degenerate triangles, 10¹⁸ EC scalars, and full ECDSA cycles.

Geometry Stress (15 tests)

SymPy fails two of these tests outright, both edge cases rather than performance issues: the equilateral triangle (where circumcenter, orthocenter, and centroid coincide, and SymPy's Line2D constructor rejects two identical points) and three levels of nested circumcenters. These aren't slowness — they're constructions SymPy's geometry module doesn't handle. Holo computes both exactly. This is the more meaningful result than any speed multiple: capability, not just throughput.

EC Stress (10 tests)

Pass rates: Holo 10/10, ecdsa 10/10, pycryptodome 8/10. pycryptodome could not complete the EC compress/decompress round-trip or the two-step ECDSA cycle in our setup. On raw speed, the pure-Python libraries dominate the trivial in-process operations (single adds, short chains) — that's expected, since those cost Holo more in DSL/proof/serialization overhead than in compute. But on the compute-heavy operations, Holo's Rust core wins even over HTTP: scalar mult 10¹⁸ (16ms vs 34ms), the full ECDSA cycle (9.8ms vs 14.4ms), point order (6.7ms vs 11ms), and the small-curve cycle (7.1ms vs 21.1ms). Those four are genuine algorithmic wins, not language artifacts.

Part 5: 3D Geometry — Beyond the Plane

Classical benchmark suites stop at the plane. Real CAD, BIM, and robotics work happens in 3D: planes through three points, lines in space, line-plane intersections, foot-of-perpendicular onto a plane, and tetrahedral centroids. Holo's DSL handles all of these with the same exact-arithmetic core. We built two 3D suites: deep dependent construction chains (vs SymPy and a NumPy floating-point oracle) and watertight mesh plane-sections (vs the trimesh mesh kernel).

Dependent 3D Construction Chains (9 tests)

Each task builds derived points on top of derived points — altitudes, oblique projections, three-plane section chains, and dependent chains up to 241 constructions deep. NumPy is the fast floating-point oracle; SymPy is the exact symbolic baseline; Holo is exact and certified. Coordinate agreement is checked against the NumPy oracle to 1e-8.

The pattern mirrors the 2D stress results: on shallow constructions the fixed per-call envelope (DSL parse, certificate, HTTP) dominates, but as dependency depth grows, Holo's exact core stays in the millisecond range while SymPy's symbolic engine collapses. On the 241-construction lattice Holo's pure compute is 11.4ms; SymPy cannot finish inside 10 seconds.

Mesh Plane-Sections vs trimesh (3 tests)

trimesh is the industrial baseline for triangle-mesh geometry. We build watertight tetrahedral meshes and cut them with the z=0 plane, then compare against Holo computing the equivalent edge-plane intersections analytically. Both produce the same cross-section — Holo does it with exact arithmetic and a certificate.

Part 6: Direct MCP — Without HTTP Overhead

The HTTP benchmark includes ~5ms of network overhead per call (TCP, JSON serialization, HTTP parsing). But Holo Engine can also be accessed directly via MCP (Model Context Protocol) — a stdio-based connection with zero network overhead. The elapsed_ms field in the JSON response reports the engine's pure Rust compute time.

The table below reports the elapsed_ms field (pure Rust compute) alongside the full HTTP wall time for the same operations. As expected, MCP direct is always faster than HTTP — the gap is the network + serialization overhead the HTTP path pays and the MCP path skips.

Why ecdsa and pycryptodome Win on Trivial EC Operations

On trivial operations (single point addition, short chains, subtraction), the in-process Python libraries are faster than Holo — even against Holo's MCP path. The reason is fixed per-call cost:

• Holo pays a fixed toll every call: DSL parsing, accuracy-certificate generation, and JSON serialization. For an operation whose actual compute is ~0.01ms, that fixed cost dominates — so a 0.1ms ecdsa call beats Holo's multi-millisecond envelope.
• ecdsa/pycryptodome have almost no envelope: a direct Python function call with no parsing, no certificate, no serialization.

But on compute-heavy operations, the fixed toll is amortized and Holo's Rust core wins even over HTTP — see the EC Stress table: scalar mult 10¹⁸ (16ms vs 34ms), full ECDSA cycle (9.8ms vs 14.4ms), point order (6.7ms vs 11ms), small curve (7.1ms vs 21.1ms). These are genuine algorithmic wins, not language artifacts.

Part 7: The Real Bar — CGAL (C++ EPECK)

Okay, you might say — comparing a Rust engine against pure Python libraries isn't exactly a fair fight. SymPy is wonderful for symbolic math, but it's not the performance bar for computational geometry. The real question is: what happens when we pit Holo Engine against CGAL?

CGAL is the gold standard. A C++ library with decades of research behind it, using the EPECK kernel for exact rational arithmetic. It's what serious computational geometry software builds on — CAD kernels, GIS systems, mesh processing pipelines. If Holo can hold its own against CGAL, that's a different conversation entirely.

So we ran 53 tests — the same DSL, the same geometry, the same elliptic curves — through both engines. CGAL via a C++ benchmark harness with a 30-second per-test timeout. Holo Engine via direct API calls, measuring internal elapsed_ms (median of 5 runs). No HTTP overhead, no MCP serialization, no Python wrappers. Pure Rust vs pure C++.

Category Summary

Where CGAL Breaks

Two tests cause CGAL's EPECK kernel to timeout at 30 seconds. Both are dependent 3D projection chains — constructions where each derived point depends on the previous one, causing exact rational numerators to grow exponentially with depth.

Holo's p-adic arithmetic doesn't suffer from numerator blow-up — the hyperbolic encoding keeps numbers bounded regardless of construction depth. This is an algorithmic advantage, not a language artifact: both engines use exact arithmetic, but Holo's representation scales where CGAL's doesn't.

Where It's Close — and Where Holo Wins Outright

On tests where both engines complete, here's the head-to-head. These are the same DSLs, run through both engines, measuring pure compute time:

CGAL is faster on exactly one test: the 3D projection lattice (241 constructions, 48 independent columns). This is a wide-but-shallow construction — 48 parallel chains of 5 operations each, no cross-dependencies. CGAL's EPECK kernel excels at batch rational arithmetic on independent computations. Holo's per-construction overhead accumulates across 241 operations. But make those same 241 operations dependent (each building on the last) and CGAL times out at 30 seconds while Holo finishes in 6ms. On every other head-to-head test, Holo is 2× to 14× faster.

Certificate Quality

CGAL uses exact rational arithmetic — its results are correct by construction. Holo Engine generates an explicit accuracy certificate for every result, reporting whether each constraint verified exactly (exact_rational) or was reconstructed (reconstructed with bounded residuals). Of the 53 tests:

• 39 tests — exact_rational certificate (unconditional proof over Ⅎ)
• 14 tests — reconstructed certificate (strong numeric evidence, heuristic rationalization, residuals < 10^-6)
• 47/53 — fully verified by the proof-by-reflection engine

CGAL does not emit a comparable verifiable certificate. Its correctness argument is "trust the kernel" — which is reasonable, but not the same as a per-result proof artifact.

EC_ORDER — Exact Group Order in Milliseconds

Computing the order of a point on secp256k1 is a fundamental operation in elliptic curve cryptography. Holo Engine computes it in ~7ms via HTTP by leveraging the curve's group order n directly. The reasoning is standard EC group theory: secp256k1 has cofactor 1 and a prime group order n, so its group of rational points is cyclic of prime order. In such a group, every non-identity point is a generator — therefore ord(P) = n for any point P other than the point at infinity (whose order is 1). When the DSL supplies n in EC_CURVE, the engine returns n directly instead of iterating.

Capability Comparison

Where Each Library Wins

Use Holo Engine when:

• You need 2D geometry, 3D geometry and EC in one system. Among the six libraries tested here, Holo is the only one that unifies them in a single DSL. (General-purpose CAS like SageMath, Mathematica, or Magma also span these domains — Holo's differentiator is the DSL + accuracy certificate, not exclusivity.)
• You need verifiable accuracy certificates. An exact-arithmetic certificate is generated automatically for every result — none of the tested libraries do this.
• You need exact rational arithmetic with proof-by-reflection (Curry-Howard).
• You're building CAD, BIM, or robotics software that needs certified geometric computations.
• You need blockchain EC arithmetic (secp256k1, ECDH, ECDSA) with verifiable correctness.

Use SymPy when:

• You need general symbolic mathematics (calculus, algebra, ODEs) — SymPy covers far more than geometry.
• You need LaTeX output of symbolic expressions.
• Your geometry problems are straightforward and don't require accuracy certificates.

Use ecdsa when:

• You need pure Python EC operations with zero dependencies.
• You're doing batch EC operations in-process — no HTTP overhead.
• You need RFC-compliant ECDSA sign/verify.

Use pycryptodome when:

• You need a full cryptographic suite (AES, RSA, hashing, not just EC).
• You're already using it in your stack and EC is a small part.

Use NumPy / trimesh when:

• You need fast floating-point 3D and don't require exact arithmetic or a certificate — NumPy is the numeric workhorse.
• You're working with triangle meshes (STL, OBJ) and need mesh-level operations — watertightness checks, boolean ops, cross-sections — where trimesh is purpose-built.

But the core message is already clear: a single DSL-based engine can handle 2D geometry, 3D geometry, and elliptic curve cryptography, beat specialized libraries on complex operations, and emit an exact-arithmetic accuracy certificate as a byproduct — all in one API call.