np.round() 后数据看似已保留指定小数位，但经 np.unique() 处理后却出现微小偏差——这并非数值被“还原”，而是 float32 与 float64 的底层表示差异导致的显示/计算不一致。根本原因在于精度类型不匹配。
`np.round()` 后数据看似已保留指定小数位，但经 `np.unique()` 处理后却出现微小偏差——这并非数值被“还原”，而是 `float32` 与 `float64` 的底层表示差异导致的显示/计算不一致。根本原因在于精度类型不匹配。
在科学计算与数据分析中，np.round() 常用于控制浮点数精度，但其行为受输入数据类型的严格制约。当原始数据（如 Pandas Series）以 float32 存储时（常见于内存敏感场景），即使调用 .round(decimals=2)，其结果仍为 float32——而 NumPy 默认的 np.unique()、np.column_stack() 等函数会将输入提升至 float64 进行内部运算。由于 float32 和 float64 对同一十进制数（如 0.01）的二进制近似表示不同，float32 中“看起来是 0.01”的值，在 float64 精度下会展现出细微的表示误差（例如 9.99999978e-03），从而在输出中呈现为“未四舍五入”的假象。
以下是一个可复现该现象的最小示例：
import numpy as np
import pandas as pd
# 构造 float32 数据（模拟原始问题）
data = pd.Series([0.009999999, 0.013242, 0.10999999], dtype='float32')
rounded = data.round(decimals=2) # 仍为 float32
print("rounded (float32):", rounded.values)
# 输出: [0.01 0.01 0.11] —— 显示正常
unique_vals, counts = np.unique(rounded, return_counts=True)
result = np.column_stack((unique_vals, counts))
print("np.unique result (float64):", result)
# 输出类似: [[9.99999978e-03 2.00000000e+00]
# [1.10000002e-01 1.00000000e+00]]
⚠️ 注意：这不是 round() 失效，也不是 unique() 错误，而是类型隐式转换引发的精度投射效应。float32 的有效精度约 6–7 位十进制数字，而 float64 约 15–17 位；当 float32 值被升格为 float64 时，其底层二进制形式被直接扩展，而非重新四舍五入，因此“暴露”了原始 float32 表示的固有误差。
✅ 推荐解决方案（二选一，优先方案2）：
方案 1：统一输出精度（简单快捷）
将 np.column_stack 结果显式转为 float32，使其与输入精度对齐：
result_array = np.column_stack((unique_values, counts)).astype(np.float32)
方案 2：统一输入精度（更稳健，推荐）
在 round() 前将数据升至 float64，确保整个流水线在更高精度下运行：
rounded_data = data_with_target_label.astype('float64').round(decimals=2)
unique_values, counts = np.unique(rounded_data, return_counts=True)
result_array = np.column_stack((unique_values, counts)) # 此时 unique_values 为 float64，但值精确符合预期
? 额外提示：若需最终结果以固定小数位展示（如导出 CSV），建议使用 np.round(result_array, decimals=2) 或 pd.DataFrame(result_array).round(2)，而非依赖底层浮点表示——因为显示精度 ≠ 存储精度。
总结：浮点数的“四舍五入感”本质是人眼对有限精度的感知，而 NumPy 的类型规则决定了计算链路中的精度传递逻辑。始终明确数据类型，并在关键环节（如 round → unique）保持精度一致性，是避免此类“幻觉问题”的根本之道。
