用 C 语言判断0.1 0.2 0.3结果往往是假。这个老问题我从入行第一年就碰到过后来在做一个计费模拟项目时小数点后六七位的误差直接让对账差了钱从那以后我对“浮点数就是精确数”彻底死心开始认真研究怎么用分数形式来精确计算浮点数。分数计算的核心思路很简单把一个浮点小数拆成分子和分母两个整数所有运算都按有理数规则走只有最后需要展示时才转回小数。这篇文章会把数据结构、约分算法、四则运算、浮点转分数的几种做法以及我在实现中踩过的坑一次讲清楚适合正在写财务、测量、科学计算等对精度敏感程序的 C 语言开发者参考。1. 浮点误差到底从哪里来为什么用分数可以绕开1.1 0.1 在二进制里写不完先回想一下十进制小数的本质。0.1就是1 / 10而10 2 × 5分母里带了质因子 5。计算机里的 double 用二进制表示数每一位都代表1/2、1/4、1/8……这种“二分”的权重本质上只能精确表达分母是 2 的整数次幂的数。1/10没法拆成有限的若干个“二分权重”之和所以二进制下它就是一个无限循环小数。double 只有 53 位有效二进制精度存下来的不是真正的0.1而是离0.1最近的那个 53 位二进制小数。代码里写double a 0.1;你实际上拿到的是一个近似值。这个近似值再参与运算误差就会累积。0.1 0.2在 double 里算出的是0.30000000000000004于是判断返回假很多新手在这里一脸懵。#include stdio.h int main(void) { double a 0.1; double b 0.2; double c 0.3; printf(a b %.20f\n, a b); printf(c %.20f\n, c); printf(equal? %d\n, a b c); return 0; }这段代码在绝大多数平台输出0.30000000000000004441和0.29999999999999998890两个数不相等。问题不是你写错了是二进制表示方式本身有盲区。1.2 分数形式解决了什么解决不了什么分数形式也就是有理数表示把一个数值拆成分子和分母两个整数。0.1直接写成1/10运算全部走分数规则通分、约分、分子分母相乘除。这个过程每一步都是整数的精确运算没有“舍入到最近二进制小数”的操作所以从源头上消除了二进制浮点误差。它能解决几类典型问题精确比较。判断两个计算结果是否相等可以交叉乘分子分母后比大小不会因为 0.0000000001 的误差误判。精确累加。反复累加同一个分数时误差不会像 double 那样越滚越大。精确展示。财务、统计、工程测量里经常要求保留固定小数位用分数算完再一次性转十进制能保证最后几位是真实值而不是噪声。需要泼冷水的是分数不是万能药。无理数如 π、√2 不能精确写成两个整数的比值分数只能给近似值分数运算过程中分子分母可能迅速膨胀超过 long long 范围就得引入大整数库性能也远不如 double。所以分数形式适合“输入边界转分数、内部精确计算、输出边界再转小数”这种模式不适合对每个中间变量都强行套分数。2. 有理数结构体与约分算法设计2.1 数据结构分子分母怎么摆最省心在 C 语言里没有现成的有理数类型最直接的方式是一个结构体typedef struct { long long num; // 分子可以带符号 long long den; // 分母约定为正数 } Fraction;我会在代码里做一个硬性约定分母永远保持正数。符号只存在分子上。这样比较大小、交叉相乘时不用反复处理符号翻转的问题。如果运算过程中分母变成了负数就在约分函数里把分子分母同时取反一步修正回来。还有一个容易被忽略的约定零值表示为0/1。0/0没有任何数学意义必须在进入算法前就拦住。初始化一个分数时最好直接写成Fraction f {0, 1};而不是{0, 0}否则后面所有 gcd 和通分都会炸。2.2 用辗转相除法把分数拧干约分是分数运算里最核心的原子操作。两个分数相加后分子分母通常存在公因子不约分会让数值膨胀得飞快。例如1/6 1/10如果直接通分得到16/60约分后才是4/15。每次运算后都约分能让后续计算的中间量保持在较小规模。求最大公约数用欧几里得算法也叫辗转相除法。C 语言实现很简洁static unsigned long long gcd_ull(unsigned long long a, unsigned long long b) { while (b) { unsigned long long t a % b; a b; b t; } return a; }这里故意把参数声明成unsigned long long是为了避免处理负数绝对值时踩到LLONG_MIN的坑。llabs(LLONG_MIN)在标准库里是未定义行为可能返回负数。用无符号类型做取模运算就安全多了。约分函数需要同时处理三件事分母转正、零值归一、分子分母除以 gcdvoid frac_reduce(Fraction *f) { if (f-den 0) { f-num -f-num; f-den -f-den; } if (f-num 0) { f-den 1; return; } unsigned long long a (unsigned long long)(f-num 0 ? -f-num : f-num); unsigned long long b (unsigned long long)f-den; unsigned long long g gcd_ull(a, b); if (g 1) { f-num / (long long)g; f-den / (long long)g; } }注意-f-num在num LLONG_MIN时同样会溢出完整的生产级代码需要对这种情况单独判断。我自己常用的做法是先把LLONG_MIN单独处理成“需要大整数模式”的标记或者直接检测到这种输入就报错而不是硬算。2.3 为什么不直接拿 double 硬算到底有人会问我直接在关键节点用 double 取整不行吗问题是 double 的误差不是只在最后一步出现而是每一步都可能引入。比较典型的是累加场景0.1 0.2 0.3 ...加一千次后累计误差可能从第 15 位有效数字蔓延到第 12 位甚至更早。而用分数累加整个过程只是整数加减乘除理论上可以做到“每一步都精确”。另一个隐蔽的问题是浮点数不满足某些数学定律。比如(a b) c的结果可能和a (b c)不同因为中间舍入点不同。这在很多算法里会造成非确定性调试起来非常痛苦。用分数表示后加法结合律、交换律、乘法分配律都恢复了正常的数学行为代码的可预期性也回来了。3. 四则运算与分数转换的完整实现3.1 加法和减法通分不是无脑通分分数加法公式是a/b c/d (a*d c*b) / (b*d)但如果无脑套这个公式分子分母很容易变得巨大。更好的做法是先约分再取两个分母的最小公倍数作为公分母。两个分母b和d的最小公倍数可以用b / gcd(b, d) * d计算先除再乘能避免不必要的溢出。核心代码如下Fraction frac_add(Fraction a, Fraction b) { frac_reduce(a); frac_reduce(b); long long g (long long)gcd_ull( (unsigned long long)a.den, (unsigned long long)b.den ); long long da b.den / g; // a 的扩分因子 long long db a.den / g; // b 的扩分因子 // 用 __int128 做中间乘法避免 a.num * da 直接溢出 __int128 n (__int128)a.num * da (__int128)b.num * db; __int128 d (__int128)da * b.den; Fraction r; r.num (long long)n; r.den (long long)d; if ((__int128)r.num ! n || (__int128)r.den ! d) { // 溢出需要进入大整数模式或报错 r.num 0; r.den 0; return r; } frac_reduce(r); return r; }__int128是 GCC 和 Clang 提供的扩展类型能做 128 位整数乘法正好用来当临时缓冲区。这段代码里我把转回long long时的溢出检查也写进去了如果转回来的值和__int128的原值不一致说明结果超出了当前数据类型的表示范围返回0/0作为错误标记。减法完全一样把加号换成减号就行。3.2 乘法和除法先约分再相乘能救命乘法看起来简单分子乘分子、分母乘分母。但如果两个分数的分子分母都很大一次乘法就可能溢出。实际开发里我会做“交叉约分”把第一项的分子和第二项的分母、第一项的分母和第二项的分子分别求 gcd先约掉共因子再相乘。道理跟口算3/4 × 4/9一样先看到 4 和 4 可以约掉3 和 9 可以约掉得到1/1 × 1/3结果1/3。如果先乘成12/36再约分也能得到同一个答案但中间数字大了不少。分数计算里每一个中间量都可能是雷越小越安全。Fraction frac_mul(Fraction a, Fraction b) { frac_reduce(a); frac_reduce(b); long long g1 (long long)gcd_ull( (unsigned long long)(a.num 0 ? -a.num : a.num), (unsigned long long)b.den ); long long g2 (long long)gcd_ull( (unsigned long long)(b.num 0 ? -b.num : b.num), (unsigned long long)a.den ); Fraction r; r.num (a.num / g1) * (b.num / g2); r.den (a.den / g2) * (b.den / g1); frac_reduce(r); return r; }注意这里r.num (a.num / g1) * (b.num / g2)两个因子都小于原来的数比直接乘安全得多。除法是乘法的延伸先判断除数是不是零再把除数分子分母对调调用乘法。对调时也要约分比如a/b ÷ c/d a*d / b*c可以把a和c、b和d之间的公因子先约掉。3.3 浮点转分数的三种实用路径在实际项目里原始输入往往不是干净的分数而是小数或字符串。把小数转成分数我一般按场景选三种方式。第一种是字符串解析法。输入是0.125这种十进制字符串可以直接按小数点拆开0.125等价于125 / 1000约分后就是1/8。这样得到的分数和十进制含义完全一致不会引入二进制舍入误差。适合计算器程序、配置文件读取、命令行参数解析。实现时可以用sscanf读整数部分和小数部分再拼成分子分母注意处理-号。int frac_from_string(const char *s, Fraction *out) { long long int_part 0; long long frac_part 0; int frac_digits 0; int neg 0; if (*s -) { neg 1; s; } // 解析整数部分 while (*s 0 *s 9) { int_part int_part * 10 (*s - 0); s; } if (*s .) { s; long long pow10 1; while (*s 0 *s 9) { frac_part frac_part * 10 (*s - 0); pow10 * 10; frac_digits; s; } out-num int_part * pow10 frac_part; out-den pow10; } else { out-num int_part; out-den 1; } if (neg) out-num -out-num; frac_reduce(out); return 0; }第二种是IEEE 754 位提取法。输入是真正的 double想把它存储的二进制值精确变成分数。思路是把 double 的 64 位拆成符号、指数、尾数三部分再拼成符号 × 尾数 × 2^指数的形状。这个方法适合做数据序列化、调试底层二进制表示但要注意它得到的分数是“double 实际存的二进制值”不是“人眼看到的小数值”。比如0.1用位提取法转出来是3602879701896397 / 36028797018963968而不是1/10。这是完全正常的因为 double 里面本来就不是1/10。用memcpy把 double 拷贝到uint64_t比直接用联合体转换更符合标准能避免编译器的严格别名问题Fraction frac_from_double_bits(double x) { uint64_t bits; memcpy(bits, x, sizeof(bits)); int sign (bits 63) ? -1 : 1; int exp (int)((bits 52) 0x7FF); uint64_t mant bits 0xFFFFFFFFFFFFFULL; uint64_t numerator; long long shift; if (exp 0) { // 次正规数或零 numerator mant; shift 1074; } else if (exp 0x7FF) { // Inf 或 NaN返回一个哨兵分数 Fraction bad {0, 0}; return bad; } else { numerator mant (1ULL 52); shift 1075 - exp; } Fraction r; if (shift 0) { r.num (long long)numerator; r.den 1LL shift; // 仅在 shift 63 时安全 } else { r.num (long long)(numerator (-shift)); r.den 1; } r.num * sign; frac_reduce(r); return r; }这里有一个重要限制1LL shift只有在shift 63时才不溢出。对于常见的0.1、0.2这没问题但极端的小数或次正规数会产生天文数字分母long long 根本装不下。完整方案需要引入大整数扩展后面我会再讲。第三种是连分数逼近法。输入是0.3333333333333333想得到1/3这种让人舒服的近似分数。它不是精确转换而是用连分数找出一个“足够接近、分母又不大”的有理数。这个方法适合用户界面显示、传感器读数清洗不适合要求精确的结算逻辑。3.4 比较大小和输出格式化分数比较最常见也是最稳的做法是交叉相乘a/b c/d等价于a*d c*b。因为分母都是正数不等号方向不会翻转。为了防溢出我仍然用__int128做中间乘法int frac_compare(Fraction a, Fraction b) { __int128 lhs (__int128)a.num * b.den; __int128 rhs (__int128)b.num * a.den; if (lhs rhs) return -1; if (lhs rhs) return 1; return 0; }输出格式方面我习惯写两个函数一个输出3/10这种分数文本一个输出3.333333这种带小数位数的字符串。输出小数时直接用(double)f.num / f.den反正展示层已经接受浮点了这点误差不影响结果。void frac_print(Fraction f) { if (f.den 1) { printf(%lld, f.num); } else { printf(%lld/%lld, f.num, f.den); } } double frac_to_double(Fraction f) { return (double)f.num / (double)f.den; }4. 一份能直接编译的分数计算示例4.1 代码骨架与运行效果把前面这些零零碎碎的函数拼成一个完整的可运行程序方便你直接拿去跑。下面的代码覆盖了结构体、gcd、约分、加减乘除、字符串转分数、double 位提取、比较和输出#include stdio.h #include stdlib.h #include string.h #include stdint.h #include limits.h typedef struct { long long num; long long den; } Fraction; static unsigned long long gcd_ull(unsigned long long a, unsigned long long b) { while (b) { unsigned long long t a % b; a b; b t; } return a; } void frac_reduce(Fraction *f) { if (f-den 0) { f-num -f-num; f-den -f-den; } if (f-num 0) { f-den 1; return; } unsigned long long a (unsigned long long)(f-num 0 ? -f-num : f-num); unsigned long long b (unsigned long long)f-den; unsigned long long g gcd_ull(a, b); if (g 1) { f-num / (long long)g; f-den / (long long)g; } } Fraction frac_add(Fraction a, Fraction b) { frac_reduce(a); frac_reduce(b); long long g (long long)gcd_ull((unsigned long long)a.den, (unsigned long long)b.den); long long da b.den / g; long long db a.den / g; __int128 n (__int128)a.num * da (__int128)b.num * db; __int128 d (__int128)da * b.den; Fraction r; r.num (long long)n; r.den (long long)d; if ((__int128)r.num ! n || (__int128)r.den ! d) { r.num 0; r.den 0; return r; } frac_reduce(r); return r; } Fraction frac_sub(Fraction a, Fraction b) { b.num -b.num; return frac_add(a, b); } Fraction frac_mul(Fraction a, Fraction b) { frac_reduce(a); frac_reduce(b); long long g1 (long long)gcd_ull( (unsigned long long)(a.num 0 ? -a.num : a.num), (unsigned long long)b.den); long long g2 (long long)gcd_ull( (unsigned long long)(b.num 0 ? -b.num : b.num), (unsigned long long)a.den); Fraction r; r.num (a.num / g1) * (b.num / g2); r.den (a.den / g2) * (b.den / g1); frac_reduce(r); return r; } Fraction frac_div(Fraction a, Fraction b) { if (b.num 0) { Fraction bad {0, 0}; return bad; } Fraction inv; inv.num b.den; inv.den b.num; return frac_mul(a, inv); } int frac_from_string(const char *s, Fraction *out) { long long int_part 0; long long frac_part 0; long long pow10 1; int neg 0; if (*s -) { neg 1; s; } while (*s 0 *s 9) { if (int_part (LLONG_MAX - 9) / 10) return -1; int_part int_part * 10 (*s - 0); s; } if (*s .) { s; while (*s 0 *s 9) { if (frac_part (LLONG_MAX - 9) / 10) return -1; frac_part frac_part * 10 (*s - 0); pow10 * 10; s; } out-num int_part * pow10 frac_part; out-den pow10; } else { out-num int_part; out-den 1; } if (neg) out-num -out-num; frac_reduce(out); return 0; } void frac_print(Fraction f) { if (f.den 0) { printf(undefined); } else if (f.den 1) { printf(%lld, f.num); } else { printf(%lld/%lld, f.num, f.den); } } int main(void) { Fraction a, b, s; frac_from_string(0.1, a); frac_from_string(0.2, b); s frac_add(a, b); printf(0.1 0.2 ); frac_print(s); printf(\n); frac_from_string(125, a); frac_from_string(1000, b); s frac_div(a, b); printf(125 / 1000 ); frac_print(s); printf(\n); Fraction c {1, 6}; Fraction d {1, 10}; s frac_add(c, d); printf(1/6 1/10 ); frac_print(s); printf(\n); Fraction e {0, 1}; Fraction f {5, 7}; s frac_mul(e, f); printf(0 * 5/7 ); frac_print(s); printf(\n); return 0; }运行结果是0.1 0.2 3/10 125 / 1000 1/8 1/6 1/10 4/15 0 * 5/7 0这个输出看着很舒服因为它和十进制手工计算完全一致没有0.30000000000000004的尴尬。4.2 用分数做一次“合法”的0.10.2上面例子里我用字符串转分数的方式把0.1转成1/100.2转成1/5相加得到3/10。这才是数学意义上的0.1 0.2 0.3。但如果我把输入改成直接传 doubledouble x 0.1; double y 0.2; Fraction fx frac_from_double_bits(x); Fraction fy frac_from_double_bits(y); Fraction fs frac_add(fx, fy);结果会是一个看起来非常复杂的分数约分后大约等于0.30000000000000004和字符串转分数得到的3/10并不相等。这不是 bug而是 double 底层的0.1本来就不是1/10。所以我始终坚持一个原则如果输入来源是用户填的十进制小数用字符串解析如果输入来源是 double 二进制结果用位提取两种来源不要混着当同一个数用。4.3 溢出边界小短路与大数字的坑long long 的范围大约是 ±9.22×10^18分数运算中分子分母很容易撞到这个天花板。比如999999999999999937 / 1 1 / 999999999999999937通分时分子会接近10^36远超 long long。我的代码里用__int128做中间检查一旦发现结果超出 long long 就返回0/0哨兵。但这个方案是“检测到溢出再报错”不是“解决溢出”。真正要支持任意大数得把分子分母换成大整数类型。常用的做法有自己实现一个简易的unsigned __int128数组模拟乘法但做除法很麻烦。引入第三方大整数库内部用类似bigint_add、bigint_div的接口替换 long long 运算。在业务层限制输入范围保证通分后的中间值不超过 long long。如果只是个人项目或原型验证long long __int128检查足够如果是生产系统我建议直接上大整数类型免得某天线上突然蹦出一个0/0在角落里发光。5. 实际使用中的问题排查速查表5.1 分母变负或变成0怎么办分母变负最常出现在减法函数里a/b - c/d通分后分母的符号取决于公分母的选择。我的解决办法是让所有入口函数都调用frac_reduce里面强制把分母转正。只要分母为正后续一切比较、输出、交叉相乘都默认正确。分母变成 0 则是程序员的 bug常见于除数为零时没有检查。frac_div开头如果发现b.num 0我返回0/0哨兵。调用方必须检查这个哨兵不能直接拿去做加法或输出。在很多代码库里这个检查会被忽略然后变成一个隐蔽的除零崩溃排查起来非常费劲。我的习惯是只要返回den 0就立刻打日志或断言绝不放行。5.2 输出一长串分母让人头晕如果你转了一个从 double 位提取出来的分数分母可能是36028797018963968这种 17 位数字打印出来用户根本看不懂。解决办法是输出时统一走frac_to_double只保留需要的有效位或者提供一个frac_to_decimal_string把分数转成固定小数位数的字符串。这个函数的思路是先做整数除法取整数部分余数继续乘 10 再除循环指定次数最后按需四舍五入。注意四舍五入本身又会引入一次小数误差但这次误差发生在“人需要看结果”的位置属于可控的展示层误差。5.3 为什么分数相加结果和预期不一样大部分时候不是算法错而是输入源不一致。有人先从 double 位提取得到fx再从字符串解析得到fa拿fx和fa相加发现结果和预想的差一点。原因就是 double 位提取的分数是二进制精确值字符串解析的分数是十进制精确值两者本来就不代表同一个数。另外如果用了不支持__int128的编译器中间乘法溢出后可能得到错误结果而不自知。我的建议是交叉相乘的临时结果一律用__int128如果目标平台没有这个扩展就用 64 位乘法的高低位拆分法或者干脆升级数据类型。5.4 排查清单表格下面这张表是我在实际调试中积累的速查内容遇到问题先对照一遍。现象可能原因处理办法分母为 0除零未拦截在frac_div入口检查除数分子分母为负约分前没有统一符号强制在frac_reduce中把分母转正结果和 double 不一致输入源混用明确用字符串解析还是位提取加法后分子巨大没有先约分就通分加法前先frac_reduce两个操作数乘法结果溢出没有交叉约分分子和对方分母先求 gcd打印出未定义返回了0/0哨兵调用处必须检查den 0负数参与比较出错分母为负检查分母符号并取反这张表的核心就是一句所有分数在进入运算前必须是“约分且分母为正”的标准形式。只要守住这个约定绝大多数问题都能提前挡在门外。6. 性能、优化和何时该收手6.1 分数运算到底慢多少分数加法比 double 加法慢是必然的。每次加法要做两次约分、一次 gcd、若干次乘法和减法。gcd 用欧几里得算法平均需要十几次取模运算这个开销在热循环里会被放大一两个数量级。我用一个简单估算如果 double 加法耗时 1 个单位frac_add可能要 30 到 80 个单位。批量计算十万次分数加法差距从微秒级变成毫秒级肉眼不一定能感受到但在高频交易撮合、实时信号处理这类场景就是不可接受的。所以我在真正调优前会先问自己这些中间结果真的都要精确吗很多场景只需要最后一步精确中间过程用 double 完全够。比如计算平均值可以先 double 累加最后用字符串解析转分数展示精确到指定小数位。这样既拿到精确结果又避开了分数加法的性能问题。6.2 合适的替代方案和扩展方向如果项目里大量需要有理数运算手写这套代码只能算轻量方案。替代方向有用支持运算符重载的 C 封装一个Rational类使用体验会好很多加减乘除可以直接写a b。引入大整数库作为底层替换 long long彻底解决溢出。如果只是要求“定点输出”不要求每一步精确可以用int64_t自己造一个小数定点类型把整数部分和小数部分固定位数拼在一起性能和精度都居中。个人经验是C 语言手写分数库最适合三个场景——学习数据结构、嵌入式环境无法引入大依赖、以及对精度有硬性要求的独立模块。模块化设计时我会把分数运算和具体业务解耦输入输出都走字符串这样以后换大整数库时不用改动业务代码。7. 写在最后的实操体会这套分数运算库我在一个模拟计算项目里用了大半年最大的体会不是“分数比浮点高级”而是“精度需求要先想清楚再选类型”。如果你只需要显示两位小数double 就够如果你要对账、做位图采样、做测量校准分数或定点数才是对的选择。C 语言本身不提供任何高精度原语想要精确计算就必须自己把结构、算法、边界条件都控制好。我在实现过程中踩过的最深的坑就是LLONG_MIN的取模和__int128的可用性这两个问题不亲自跑一遍真的很难发现。建议你先跑通上面的代码再试着把加法改成减法、把除法加上零值保护、把输出加上固定小数位等你把边界条件都补齐了这套工具就可以放心进项目了。