关于用整数对存储浮点数实现无限精度运算的技术疑问

是否存在相关实践？ #

当然有。这种用**整数对（有效整数值 + 指数值）**表示浮点数的方案，本质是将数值编码为 significand × base^exponent 的形式（base通常选2或10），属于精确有理数/小数的实现范畴，常见场景包括：

• 金融系统的精确金额计算：用整数存储最小货币单位（比如分）搭配固定指数，属于定点数的变体，本质也是整数对逻辑；
• 编程语言的高精度小数库：比如Python的decimal.Decimal、Java的BigDecimal，底层均采用整数存储有效数字，搭配整数指数来规避IEEE 754浮点数的精度误差；
• 对精度要求极高的科学计算场景，也会有自定义的整数对存储实现。

关于运算性能的纠正 #

你提到“运算性能表现更优”并不准确。硬件原生的IEEE 754浮点数是通过专用电路优化的，运算速度极快；而整数对的浮点运算完全依赖软件实现：加减法需要先对齐指数（通过整数乘/除调整有效数字），乘除法要处理有效数字运算和指数加减，这些操作的耗时远高于硬件浮点运算，尤其是涉及大整数时，性能差距会被进一步放大。

除内存消耗外的其他问题 #

• 运算复杂度陡增：
  • 加减法必须先对齐指数，比如计算 a×10^3 + b×10^5，需要将a放大100倍转为a×10^5后再与b的有效数字相加，涉及大整数乘法，效率远低于原生浮点；
  • 所谓“无限精度”有严格前提：只有当运算结果能被所选base有限表示时才能实现（比如1/2用base2可精确表示），若遇到无法有限表示的分数（比如1/3用base10），要么截断丢失精度，要么无限扩展有效数字导致内存和运算资源耗尽，无法真正实现“无限精度”；
• 类型互操作性差：这种自定义格式不属于标准数据类型，和原生浮点、整数的转换需要额外逻辑处理，容易引入转换错误；
• 标准化与兼容性不足：不同实现的存储规则（比如base选择、指数编码、符号位处理）可能不一致，跨系统或跨语言交互时需要额外的序列化/反序列化逻辑；
• 边界情况处理复杂：极大/极小数值的指数范围需要限制（否则有效数字会变得无比巨大，超出内存和运算能力），NaN、无穷大这类特殊值的定义与处理也需要额外设计，不像IEEE 754有统一标准可循；
• 排序与比较效率低：两个整数对数值的比较需要先对齐指数再对比有效数字，比原生浮点的直接比较慢很多，大量数据排序时性能影响会被放大。

内容的提问来源于stack exchange，提问作者Jason