先明确任务与结果
JavaScript的Number是有限精度表示。严格相等、任务定义的近似比较和精确整数处理是三条不同路线。Number.EPSILON表示1附近相邻数的间隔,不能作为所有数量级与所有任务的通用容差,更不能补回运算之前已经丢失的信息。
先问“相等”要保留哪种含义
MDN的Number.EPSILON说明解释了1附近的精度及数值数量级的影响。它不是图片像素、长度、计数或业务规则自动共享的一项精度设置。你必须先说明数据类型、单位和允许误差。
这组练习只使用普通JavaScript Number。原始材料是下面三条表达式与数学参考;没有调用AI产品、比较模型或处理实际业务数据。让模型给理由时,必须把运行结果与数学意义分别写出来。
A: (0.1 + 0.2) === 0.3
B: Math.abs((1000.1 + 1000.2) - 2000.3) < Number.EPSILON
C: (1e16 + 1) - 1e16
Task: predict JavaScript Number results, explain the difference from exact arithmetic,
and state what comparison policy would be appropriate before proposing a code change.三个样本暴露的不是同一个问题
A的严格相等结果是false;运行中的和为0.30000000000000004,而非精确十进制意义的0.3。B的差约为2.2737367544323206e-13,大于Number.EPSILON,因此也是false。把A的技巧直接复制到较大数量级,会漏掉误差尺度的变化。
C返回0,而精确整数算术应给1:在这个Number表达式中,1e16+1已经无法保留那个增加量。最后再比较误差或格式化小数位,都不能从已丢失的中间结果恢复1。
| 样本 | Number结果 | 需要解释的差别 |
|---|---|---|
| A | false | 小数二进制表示与严格相等 |
| B | false | 固定的EPSILON没有适配数量级 |
| C | 0 | 加法阶段就已丢失单位增量 |
容差应该由任务给出,不由一句提示词猜出
如果本练习明确约定“这批近似数的绝对误差最多1e-12”,A的两边与B的两边都可以在该约定下判为足够接近。这是编辑为练习设置的容差,不是通用测量精度或任何产品保证;换单位、数量级或输入精度时,必须重新判断。
对计数与标识符,则不能用“差不多”合并对象。需要精确整数时,应在计算前选择适合的表示,例如从保留的整数字符串构造BigInt,而不是先让超出安全整数范围的Number丢失信息后再转换。实际输入类型和后续序列化也要一起处理。
把三种契约分开
精确身份或计数
先保证表示不丢失必要信息,再按精确规则比较。
允许误差的数值
由单位、输入精度与使用要求确定绝对或相对容差,写出接受条件。
仅用于展示
小数位格式决定显示方式,不自动修复底层运算。
给AI的修复任务要同时带上反例
下面的提示词要求模型先分类再写代码,避免把全部===替换成一个通用近似函数。错误稿与修改方向由编辑构造,不能记成某模型犯错的证据。
运行参考样本后再检查建议:它是否改变了输入契约,是否说明容差单位,是否承认大整数在进入计算前就要处理?如果答案只是“加一个EPSILON”,追问B和C为什么仍然失败。
Review A, B and C above under JavaScript Number semantics.
Separate exact identity/counts, approximate values with a stated tolerance, and display formatting.
For the illustrative approximate-value task only, use absolute tolerance 1e-12.
Give expected results and explain the point where C loses information.
Do not replace every strict equality in a project. If an exact integer is required,
start from an original integer string and explain a suitable representation before arithmetic.
Label any unexecuted code as a proposal, not a tested result.表面修好A,仍然改变了题目
把所有相等判断改成差值小于Number.EPSILON,并把C的0格式化成一位小数。
按契约分别处理;近似练习写明1e-12,精确整数在运算前保留原值,展示另行格式化。
把代码结果和数据交接一起检查
原始数字在文件交接时也可能被改成另一种类型,参见JSON转Excel时保留长编号与数字原文。输入已经变化,后面的等号检查无法证明原始对象正确。
展示位数与中间计算是另一层问题,可阅读中途舍入与最终显示值。保留这三个层次:原始表示、计算规则、显示形式;不要用格式化后的同一串文字掩盖不同数值。
可以接受一份AI修复建议的条件
- 输入契约与单位已经写明。
- A、B、C分别有运行结果和解释。
- 近似比较有任务约定的容差,不冒充通用规则。
- 精确整数在运算前没有经过失真转换。
- 未执行建议与实际验证结果清楚区分。
常见问题
把小数转成固定小数位字符串再比可以吗?
只有任务本身比较的是明确的显示字符串时才按该规则处理。它会舍入并改变类型,不能普遍替代数值相等或精确身份比较。
把1e16+1的结果转BigInt能恢复1吗?
不能。示例在Number加法时已丢失增量。需要精确整数,应从原始整数字符串或精确整数表示开始,而不是事后转换丢失后的结果。
AI解释正确就说明所有代码都安全了吗?
不说明。这里只核对三个具体边界;实际函数仍要按输入范围、数据类型、异常和后续使用检查。


