浮点精度差异是二进制表示能力限制所致，非计算错误；float32有效十进制位6–7位，float64为15–16位；类型升格（如np.unique）会暴露原始近似值，内存与性能差异更关键。
浮点精度差异不是“计算错误”，而是二进制表示能力不同导致的必然结果
float32 和 float64 的有效十进制位数根本不同
float32 只能稳定表达约 6–7 位十进制数字，float64 是 15–16 位。这不是“误差大小”的问题，而是“能精确表示哪些数”的底层限制。
例如 0.1 在二进制中是无限循环小数，float32 存储的是它在 23 位尾数下的近似值，float64 则用 52 位尾数逼近得更细——但两者都仍是近似值。
-
np.float32(0.1)→ 实际存储为0.10000000149011612 -
np.float64(0.1)→ 实际存储为0.1000000000000000055511151231257827021181583404541015625
当你做加减乘除时，这些微小差异会累积；当参与 np.unique()、np.isin() 或比较操作（如 a == b）时，原本“应该相等”的 float32 值升格为 float64 后，反而暴露了原始近似值的不一致。
立即学习“Python免费学习笔记（深入）”；
np.unique() 默认升格到 float64 导致“看似未舍入”
这是最常被误读的场景：你对 float32 数组调用 round()，显示看起来都对（比如 [0.01, 0.01, 0.11]），但一进 np.unique() 就冒出 9.99999978e-03 这种数。
华为云 Python SDK 查询工具。自动发现已安装 SDK 的服务包、Client类、API 方法、入参详情、类信息（__init__ 参数、属性、类型、描述），支持关键字搜索，快速定位目标 API 使用方法。
原因很简单：np.unique() 内部统一按 float64 处理输入——它把 float32 的原始二进制形式直接扩展成 float64，不做重新舍入。所以你看到的不是“没 round”，而是 float32 里那个本就不精确的 0.01，在 float64 下被完整展开了。
- float32 中的
0.01实际是0.009999999776482582 - 升格为 float64 后仍是这个值，只是显示更多位：
9.999999776482582e-03 - 如果你希望输出“看起来干净”，得显式截断或重舍入，而不是依赖显示格式
内存与性能差异远比精度更实际
float32 占 4 字节，float64 占 8 字节——同尺寸数组，内存直接翻倍。这对 Pandas DataFrame、PyTorch 张量、图像数组影响极大。
- 加载 1000 张 1024×1024 RGB 图像，默认 float64 消耗约 24GB；改用 float32 后降到 ~12GB
- GPU 计算（如训练）中，float32 是默认且推荐类型；float64 在多数 GPU 上不加速，甚至不支持
- 压缩（如
pickle+gzip）和序列化体积也几乎减半，传输更快
但要注意：从 float64 转 float32 是有损的，尤其当数值本身已超出 float32 表达范围（如 >1e38）或需要高精度累加（如金融累计求和）时，不能无脑降精度。
什么时候必须用 float64，什么时候可以放心用 float32
选型不是看“哪个更准”，而是看任务对精度的容忍边界和资源约束。
- 可用 float32：图像像素值（0–255 归一化后）、模型推理/训练权重、传感器原始读数、大多数科学模拟中间变量
- 建议 float64：财务计算、高精度积分/微分、坐标系长时间累积变换、作为唯一键参与
np.unique()或pd.merge()的浮点列 - 特别注意：Pandas Series 默认 dtype 是 float64，但读取 CSV 时若指定
dtype={'col': 'float32'}，后续所有运算都会继承该类型——别让隐式类型传播埋坑
最易忽略的一点：即使你全程用 float32，只要调用某个函数（如 scipy.stats.ttest_ind）内部强制转 float64，就可能触发上述“精度暴露”。遇到诡异的浮点不等，先查 .dtype，再查函数文档是否做了类型提升。
