不四舍五入的计算器：挑战传统计算逻辑

背景

在传统的浮点数计算中，由于 IEEE 754 双精度标准的限制，计算机无法精确表示所有实数，这导致了著名的“舍入误差”问题。例如，在标准计算器中，exp(100) + 42 - exp(100) 的结果往往不是 42，而是 0，因为 exp(100) 的值过大，导致加上的 42 在精度表示中“丢失”了。

尽管在 20 世纪 80 年代和 90 年代，Hans Boehm 就构建了用于构造性实数算术（Constructive Real Arithmetic）的 Java 库，并且该引擎长期作为 Android 系统内置计算器的核心动力，但 iOS 平台上一直缺乏类似的等效应用。直到 2026 年，一位开发者利用最新的 AI 辅助开发工具，将这一经典算法移植到了 iPhone 上，推出了名为 Constructive Calculator 的应用。

核心内容

Constructive Calculator 是一款专为 iPhone 设计的计算器应用，其核心特性是完全不进行舍入。它基于构造性实数（Constructive Reals，也称可计算实数）进行运算，确保每一个结果都是精确的。用户可以无限滚动查看答案，获取任意多位数的正确数字。

1. 核心原理：构造性实数算术

与传统存储固定宽度近似值的浮点数不同，构造性实数存储的是一个函数。这个函数可以根据用户请求的任意精度生成近似值。在计算过程中，每个子表达式都会被评估到最终答案所需的精度，从而避免了中间步骤的精度损失。

2. 直观案例演示

• 拉马努金常数（Ramanujan's Constant）： 计算 exp(π√163) 时，结果看起来像整数 262,537,412,640,768,744。如果向下滚动小数点，你会发现前面有十二个 9，之后才会出现偏差。传统计算器可能直接显示该整数或截断显示，而此应用能揭示其真实的无限精度结构。
• 精度抵消问题： 计算 exp(100) + 42 - exp(100)：
  • 在 IEEE 754 双精度中，exp(100) ≈ 2.7×10^43，加上 42 对如此巨大的数没有影响（42 在表示底部丢失），因此减法结果为 0。
  • 在构造性引擎中，exp(100) 会被计算到足够多的位数，执行两次，减法操作后精确剩下 42。
  • 注意：该计算器不会预先简化表达式，而是严格按照指令执行“加法”然后“减法”的操作。

3. 技术实现与 AI 辅助开发

开发者在 2026 年并未手动移植代码，而是采用了 AI 辅助工作流：

• 代码移植：指导 Opus 4.8 模型逐行将 Hans Boehm 的 Java 库翻译为 Swift。
• 核心组件：
  • 移植了 Boehm 的 com.hp.creals 库（包括超越函数、用于计算 π 的高斯-勒让德 AGM 算法）。
  • 引入了 AOSP（Android Open Source Project）ExactCalculator 中的 UnifiedReal / BoundedRational 层，使得在可能的情况下（如 cos(π/3) 返回精确的 1/2 而非近似值）保持符号精确，并使有理数情况的比较成为可判定问题。
  • 构建了表达式求值器和带有“滚动查看更多位数”功能的 SwiftUI 前端。
• 架构适配：
  • Java 的 synchronized、检查型异常和 AsyncTask 在 Swift 中没有直接对应物。开发者将异常转换为 Swift 的 throws，将精度溢出和发散转换为类型化错误，并将 Java 基于中断的取消机制转换为 Swift Concurrency 的 Task.checkCancellation()。
  • 由于开发用的 2013 款 Mac 无法运行新版 Xcode，签名和 TestFlight 上传均在 GitHub Actions 上完成。

4. AI 辅助测试与 Bug 修复

开发者使用另一个模型 Fable 5 进行“干净室”审查（Fresh Context，即不带有任何关于代码构建过程的记忆，仅基于代码库进行审查），发现了多个在单元测试中无法暴露的严重 Bug：

• 并发 Bug：@MainActor 被错误地附加到错误的类型上，导致视图模型未在主线程隔离，后台任务在非主线程修改了 @Published 状态。
• 竞态条件：Boehm 的 Java 代码中 get_appr（记忆化近似例程）是同步的。移植版本移除了锁并依赖 Actor 序列化访问，但两条路径绕过了 Actor，导致两个线程可能竞争同一个构造性实数的缓存。对于 π 等共享单例，这不仅是数字错误，更是内存安全漏洞。修复方案是重新加回可重入锁。
• 主线程冻结：大阶乘的同步求值导致 UI 挂起且无法取消。修复后改为后台运行、可取消，并设置了合理的上限。
• 合规性缺失：补充了隐私清单、出口合规标志和辅助功能标签。

5. 已知局限性

构造性实数算术存在一个硬性的数学边界：相等性是不可判定的。

• 你无法通过任何有限计算来一般性地证明两个构造性实数相等。
• 因此，虽然 exp(100)+42-exp(100) 正确输出 42，但应用无法证明该计算会“终止”。它会打印 42.000... 并显示“更多位数”箭头，且后续数字将永远为零。
• 应用仅在值保持在“结构化有理数乘以已知常数”的形式时（如 cos(π/3)=1/2），才会标记结果为“精确”。对于 exp(100)+42 这类情况，则不会标记为精确。这与 Android 内置计算器的行为一致。

6. 最新更新

2026 年 6 月 15 日更新增加了标准正态累积分布函数（pnorm）及其逆函数（qnorm，即键盘上的 Φ 和 Φ⁻¹），计算精度任意。由于 Boehm 库未包含误差函数，这是首个非移植函数，直接实现为无抵消的构造性级数。

关键要点

• 零舍入误差：应用基于构造性实数算术，结果精确，支持无限滚动查看任意多位正确数字。
• 解决经典浮点缺陷：能够正确处理 exp(100) + 42 - exp(100) 等导致传统浮点数计算失效的表达式，返回精确的 42 而非 0。
• AI 驱动的开发流程：利用 Opus 4.8 进行 Java 到 Swift 的代码移植，利用 Fable 5 进行独立代码审查，有效发现了并发、内存安全和 UI 冻结等深层 Bug。
• 跨平台技术融合：结合了 Hans Boehm 的 Java 构造性实数库和 AOSP 的符号精确层，实现了 iOS 平台上的高精度计算。
• 数学本质限制：由于构造性实数的相等性是不可判定的，应用无法自动证明某些表达式的终止性，会以无限零的形式输出结果，仅在特定结构化形式下标记为“精确”。
• 开源与反馈：目前处于 iPhone 专属的 TestFlight 早期测试阶段，欢迎用户反馈边缘案例。

意义与影响

Constructive Calculator 的出现不仅是 iOS 平台工具链的一次技术补完，更是 AI 辅助软件工程（AI-Assisted Software Engineering）成熟度的一个典型案例。

1. **技术传承