Python 2.7自定义类__hash__与__eq__方法实现问题求助

这种情况十有八九是浮点数精度误差在搞鬼！咱们来拆解一下核心问题：

你的Line类是通过两个Point对象计算斜率（slope）和截距（intercept）对吧？这两个值本质是浮点数，而计算机里的浮点数是用二进制近似存储的——哪怕理论上完全相等的直线，实际计算出来的斜率/截距可能会有极其微小的差异，肉眼根本看不到，但足以让==判断失效。

举个实际场景的例子：

• 第一组直线：用Point(0,0)和Point(2,2)计算，得到slope=1.0，intercept=0.0
• 第二组直线：用Point(1,1)和Point(3,3)计算，理论上斜率和截距应该完全一样，但实际计算时，可能因为中间运算的顺序、精度截断等问题，得到slope=1.0000000000000002，或者intercept=-1e-16这种近似值

如果你的__eq__方法是直接用==比较这两个浮点数，那第一组刚好因为计算路径的差异产生了微小误差，导致判断为不等；而第二组的计算路径刚好让两个值的近似结果完全重合，所以判断为相等。

另外还要注意__hash__方法：如果它是基于原始的斜率/截距计算的，那浮点精度问题会直接导致理论相等的直线生成不同的哈希值，这会让它们在集合、字典这类依赖哈希的结构里被当成完全不同的对象，进一步放大问题。

解决思路 #

1. 放弃直接用==比较浮点数：改用「近似相等」判断，设定一个极小的误差阈值（比如1e-9），当两个值的绝对差小于阈值时，就认为它们相等。示例代码：

   def __eq__(self, other):
       if not isinstance(other, Line):
           return False
       # 用阈值判断斜率和截距是否近似一致
       slope_match = abs(self.slope - other.slope) < 1e-9
       intercept_match = abs(self.intercept - other.intercept) < 1e-9
       return slope_match and intercept_match
   

2. 同步修正__hash__方法：因为__eq__逻辑变了，__hash__必须保持一致性——不能再用原始浮点数计算哈希，得先把斜率/截距「量化」到固定精度，比如四舍五入到小数点后9位，再基于量化后的值生成哈希：

   def __hash__(self):
       # 先将浮点数统一到固定精度
       quantized_slope = round(self.slope, 9)
       quantized_intercept = round(self.intercept, 9)
       return hash((quantized_slope, quantized_intercept))
   

3. 终极避坑方案：完全绕开浮点数：如果Point的坐标是整数，其实可以用向量叉乘的方式判断两条直线是否共线，完全避免浮点运算。比如直线AB和直线CD相等的条件是：(B.x - A.x)*(C.y - A.y) - (B.y - A.y)*(C.x - A.x) == 0，且(B.x - A.x)*(D.y - A.y) - (B.y - A.y)*(D.x - A.x) == 0，用整数运算彻底杜绝精度问题。

这种几何计算的坑太常见了，核心就是别拿浮点数当精确值直接比！

内容的提问来源于stack exchange，提问作者mlander