C ++ unordered_map自定義哈希函數沖突

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