IEEE 754
IEEE制定的二进制浮点数算术标准，定义了浮点数的表示方式、精度（fp32约7位十进制有效数字，fp64约15位）及舍入规则，是现代计算机浮点运算的基础规范
时间轴 (近 90 天)
IEEE 754 双精度浮点数（TypeScript 的 number 类型）无法精确表示许多十进制小数，因此不适合金融计算。
IEEE 754 双精度浮点数（float64）只能精确表示分母为 2 的幂的分数，0.1、0.2 这类十进制小数在二进制下是无限循环小数，存储时必然被截断。
IEEE 754 浮点数无法精确表示大多数十进制小数，反复运算会产生舍入误差，例如在 JavaScript 中 0.1 + 0.2 === 0.30000000000000004。
将无符号整数 n 转换为 float 后，规格化结果的指数字段等于 floor(log2(n)) + 127
单精度浮点数用 8 位存储指数，采用偏置编码 bias = 127
浮点指数提取方法中零值输入会产生 -∞（指数全零），需要额外处理
对于超过 2²⁴ 的 32 位整数，单精度浮点的尾数精度不足以精确表示，导致指数字段偏低
浮点加法不满足结合律，(a+b)+c 和 a+(b+c) 在最后一位上可能有差异
浮点加法和乘法在IEEE 754标准下不具备结合律，GEMM和GEMV内部求和顺序不同导致同一输入的激活值产生极微小差异
JavaScript原生number类型为IEEE 754双精度浮点，其53位尾数在表示纳秒级时间戳（约1.7×10¹⁸量级）时会损失精度，这是建议改用BigInt的根本原因
还有 7 条时间轴事件
全部知识事实 (18)
Python的浮点数遵循IEEE 754双精度浮点数标准，使用64位二进制来表示一个小数
60%待验证IEEE 754 双精度浮点数（TypeScript 的 number 类型）无法精确表示许多十进制小数，因此不适合金融计算。
50%待验证IEEE 754 双精度浮点数（float64）只能精确表示分母为 2 的幂的分数，0.1、0.2 这类十进制小数在二进制下是无限循环小数，存储时必然被截断。
50%待验证IEEE 754 浮点数无法精确表示大多数十进制小数，反复运算会产生舍入误差，例如在 JavaScript 中 0.1 + 0.2 === 0.30000000000000004。
50%待验证对于超过 2²⁴ 的 32 位整数，单精度浮点的尾数精度不足以精确表示，导致指数字段偏低
50%待验证浮点指数提取方法中零值输入会产生 -∞（指数全零），需要额外处理
50%待验证单精度浮点数用 8 位存储指数，采用偏置编码 bias = 127
50%待验证将无符号整数 n 转换为 float 后，规格化结果的指数字段等于 floor(log2(n)) + 127
50%待验证浮点加法不满足结合律，(a+b)+c 和 a+(b+c) 在最后一位上可能有差异
50%待验证浮点加法和乘法在IEEE 754标准下不具备结合律，GEMM和GEMV内部求和顺序不同导致同一输入的激活值产生极微小差异
50%待验证JavaScript原生number类型为IEEE 754双精度浮点，其53位尾数在表示纳秒级时间戳（约1.7×10¹⁸量级）时会损失精度，这是建议改用BigInt的根本原因
50%待验证JavaScript原生Date对象本质是一个IEEE 754双精度浮点数，表示自Unix纪元以来的毫秒数，直接依赖底层操作系统时钟
50%待验证SSE2指令集于2001年随Pentium 4引入，带来符合IEEE 754标准的32/64位浮点运算
50%待验证FP32使用32位表示浮点数，其中1位符号位、8位指数位、23位尾数位
50%待验证根据IEEE 754的round-to-nearest-even舍入规则，向1.0加上小于半个ULP（约0.00000006）的数，结果仍为1.0，加法无效
50%待验证Hexel Editor提供光标位置字节的即时解码功能，能展示数据在不同数据类型（8/16/32/64位整数、IEEE 754浮点数、ASCII/UTF-8字符编码等）下的解读
50%待验证0.1 + 0.2的浮点运算实际结果为0.30000000000000004而非精确的0.3
50%待验证由于IEEE 754浮点数精度限制，直接使用EXPECT_EQ进行浮点比较几乎必然导致虚假失败，应使用EXPECT_NEAR指定容差
50%