Question

下面的代码用于计算不同斜率值的平面中的行数。建议使用一对x轴和y轴位置来表示直线的斜率，直接计算除法y / x的b / c会产生浮点精度问题。所有x和y位置都是整数。

尽管我正在使用测试代码的方法，但是我仍然不清楚：

1）对于方法I，对{5，3}和{3，5}将具有相同的哈希值（x ^ y），但是这两行的斜率不同！为什么不引起考虑两条线具有相同斜率的问题？还是散列函数值仅确定要散列的插槽，而比较实际对值的等效性确定是否将它们视为相等？

2）由于对{5，3}和{3，5}将被散列到同一插槽中，因此还有许多其他类似的冲突，例如{a，b}和{b，a}。为什么冲突哈希表仍会产生正确的最终结果？

3）对负整数进行XOR可以吗？我们通常在这里使用更好的哈希函数来避免高冲突吗？

struct hashfunc
{
    //Method I:
    size_t operator() (const pair<int,int>& l) const
    { return l.first ^ l.second; }   

    //Method II is WRONG: can NOT left shift negative int!!
    size_t operator() (const pair<int, int>& l) const {
         return l.first << 32 | l.second; 
    }
};

unordered_map< pair< int,int >, int, hashfunc> lines;

Answer 1

在任何输出小于组合输入的函数中，都无法完全避免冲突。正确性不取决于缺少碰撞，只有性能才如此。即使使用始终返回零的哈希函数（尝试一下），您也应该获得正确的结果。

哈希函数值仅确定要哈希的插槽，而比较实际对值的等效性确定是否算他们相等吗？

正确。

通常的方法是将数字以不可预测的方式混在一起，例如

choose distinct primes a,b,c
hash(x,y) = (a*x + b*y) % c

例如https://en.wikipedia.org/wiki/Universal_hashing#Hashing_integers

C ++ unordered_map自定义哈希函数冲突

1 个答案: