AI 入门与核查AI 应用

AI代码把0.1+0.2直接比较0.3?用三个样本检查浮点数与误差容限

让AI把“相等判断”改成“差值小于EPSILON”,可能修好一个小数例子,却把计数、编号或大数运算改成另一种错误。先写清你在比较精确对象还是允许误差的测量值,再决定什么结果可以接受。下面的答案是编辑建立的JavaScript核查参考,不是某个模型的实测回答。

屏幕上的二进制数字近景,作为有限精度表示的配图
配图:Alexander Sinn · Unsplash License

先明确任务与结果

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结果需要解释的差别
Afalse小数二进制表示与严格相等
Bfalse固定的EPSILON没有适配数量级
C0加法阶段就已丢失单位增量

容差应该由任务给出,不由一句提示词猜出

如果本练习明确约定“这批近似数的绝对误差最多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解释正确就说明所有代码都安全了吗?

不说明。这里只核对三个具体边界;实际函数仍要按输入范围、数据类型、异常和后续使用检查。

参考资料与延伸阅读

这个主题的后续文章

沿着同一主题,继续阅读引用了本文的新文章。

继续阅读