java - 如何使用 equals() 和 hashCode() 实现近似几何相等

Question

我想实现一些具有数值鲁棒性的几何算法。

为此，使用系统范围的delta来实现几何相等。点的 equals() 是通过使用 delta 近似相等的距离计算来实现的。

我希望能够使用常规的 java 集合，例如 Set。但我无法想出一个合理的 hashCode() 实现。

我的猜测是，有效使用 HashSet 的实现将导致具有“软”边界的空间分区。与分区边界距离小于 delta 的点应该能够同时分类到最多八个(对于 3D)相邻区域。距离足够近以被视为相等但位于分区不同侧的点将被“错误分类”。

这是我无法理解的。 hashCode() 就像将项目放入桶中，其中单个项目最终放入单个桶中，而我需要将其放入最多八个。

什么是合理的解决方案？我是否滥用了 hashCode() 的用途？仍然使用 hashCode() 的最合理解决方案是什么:)

编辑:谢谢，我有一种直觉，这个想法有问题，但无法指出。你把事情说得很清楚了

请让我扩展我的问题:如果我可以接受较慢的 HashSet 操作(这不是一个阻碍)，我可以让 hashCode() 返回 1 因为在我的例子中没有正确的实现，如果我确实实现了 equals() 并放弃了传递性要求，会产生什么可怕的后果(就几何计算而言)？

编辑我找到了this post ，突出显示缺少传递性的问题以及和 this post ，与此密切相关。

Answer 1

对于非equals() 对象，

hashCode() 可以相等。所以，事实上，桶装可能就很好。例如，如果您只使用最近“网格”点的某个哈希函数，您可以在其中任意定义该网格，只要您一致且正确地定义舍入，它就可以作为哈希函数使用。

但是，您不会从第一个定义中得到 equals() 的正确概念。如果 A 和 B、B 和 C 彼此在 delta 范围内，这并不意味着 A 和 C 也在范围内。传递性不成立。

您可以根据分桶定义equals()。当点接近但线的另一侧不相等时，它可能会给出稍微令人惊讶的结果。