← Constructive Calculator

No Rounding

June 11, 2026

Constructive Calculator is an iPhone calculator that doesn’t round at all. It computes with constructive real numbers: every result is exact, and you can scroll any answer for as many correct digits as you want. What that gives you:

• exp(π√163), Ramanujan’s constant, looks like the integer 262,537,412,640,768,744. Scroll past the decimal point and you find twelve 9s before it finally diverges.
• exp(100) + 42 − exp(100) returns exactly 42. In IEEE 754 double, exp(100) ≈ 2.7×1043, and adding 42 changes nothing (42 falls off the bottom of the representation), so the subtraction gives 0. The constructive engine evaluates exp(100) to as many digits as is needed, twice, and the subtraction leaves only 42. The calculator does not simplify the expression first; it does indeed perform both operations as instructed: addition and then subtraction.

It’s made possible by constructive (or computable) real arithmetic: instead of storing a number as a fixed-width approximation, store a function that produces an approximation to any requested precision, and evaluate each subexpression to whatever precision the final answer needs. Hans Boehm built a Java library for this in the 1980s and 90s, and it has been the engine behind Android’s built-in Calculator, a fact that periodically delights Hacker News.

But there was no equivalent on iPhone that I could find, so I built one, by porting Boehm’s engine.

It’s 2026, so I didn’t hand-write the port. I directed Opus 4.8 to translate the source line by line into Swift, and steered the process (architecture, UI, on-device testing, the App Store machinery) over a long back-and-forth.

What got ported:

• com.hp.creals, Boehm’s constructive-reals library (CR, the transcendental functions, the Gauss-Legendre AGM for π), into a Swift package.
• UnifiedReal / BoundedRational from AOSP’s ExactCalculator, the layer that keeps results symbolically exact when it can (so cos(π/3) comes back as exactly ½, not a constructive approximation of it) and makes comparisons decidable for the rational cases.
• The expression evaluator and a SwiftUI front end with the scroll-for-more-digits display.

The interesting work was what didn’t translate directly. Java’s synchronized, checked exceptions, and AsyncTask have no Swift equivalents, so the port re-expressed them: exceptions became Swift throws, precision-overflow and divergence became typed errors, and Java’s interrupt-based cancellation became Swift Concurrency’s Task.checkCancellation(). The 2013 Mac I develop on can’t run a current Xcode, so signing and TestFlight uploads run on GitHub Actions; the local machine never touches the submission.

Then I had a different model, Fable 5, do a clean-room review: fresh context, no memory of how the code was built, just the repository. It earned its keep:

• A concurrency bug: @MainActor was attached to the wrong type, so the view model wasn’t main-actor isolated and a background task was mutating @Published state off the main thread.
• A subtler one: Boehm’s Java get_appr (the memoized approximation routine) is synchronized; the port had dropped the lock and leaned on an actor to serialize access, but two paths slipped around the actor, so two threads could race the same constructive real’s cache. For shared singletons like π that is a memory-safety bug, not just a wrong digit. The fix was the faithful one: put the lock back (reentrant, since the square-root routine re-enters itself).
• A main-thread freeze: a large factorial was evaluated synchronously, hanging the UI with no way to cancel. It now runs off the main thread, cancellable, with a sane cap.
• And the boring-but-mandatory App Store gaps: a missing privacy manifest, the export-compliance flag, accessibility labels.

As a data point on AI-assisted development, I found this quite useful: the port itself was faithful (Fable 5 checked the algorithms against Boehm’s Java and found no transcription errors), but the adaptation to a different concurrency model is where the bugs lived, and a second model with no stake in the first one’s choices caught them. None would have shown up in the unit tests.

Known Limitations

Exact real arithmetic has a hard wall: equality is undecidable. You cannot, in general, prove two constructive reals are equal by any finite computation. So exp(100)+42−exp(100) is correctly 42, but the app can’t prove it terminates; it prints 42.000… with a “more digits” arrow and will emit zeros forever. It always gives you the right number to as many digits as you want; it only labels a result “exact” when the value stays inside the structured rational-times-known-constant form. cos(π/3)=½ does; exp(100)+42 doesn’t. Android’s calculator has the same property, for the same reason.

Try it

Early TestFlight beta, iPhone, iOS 16+: join here. Caveat: iPhone-only for now. Feedback very welcome, especially edge cases: support@dimview.org.

Update, June 15, 2026: added the standard normal CDF and its inverse, pnorm and qnorm (Φ and Φ⁻¹ on the keypad), computed to arbitrary precision. This one needed new math. The error function isn’t in Boehm’s library, so it’s the first function here that isn’t a port: it’s implemented directly, as a cancellation-free constructive series. Now in the TestFlight beta.