哈希表和碰撞计算结果

如何解决哈希表和碰撞计算结果

我知道我没有可用的代码/最小代码，但我并没有在代码中寻求更多帮助。我将尝试尽可能多地总结。测试运行 1000 次，试图将 50 人插入表中。试验根据 getRandomPersonalNumber 随机生成密钥。

如果有任何冲突，线性探测函数会返回，如果需要更新索引，并搜索键是否与索引匹配。现在在结果中，唯一看起来很奇怪的是 Table 1 我向一些朋友询问了结果，他们说可能模 100 正在做某事，这就是为什么我得到高共谋结果在Table 1。

我担心这可能与我的计算有关，但话说回来，它只发生在 100 modulo 中，所以我不知道我能否在不依赖代码的情况下精确计算碰撞量也许是数学？最后，有没有办法计算存储量与共谋量（负载因子）之间的良好中间地带？

typedef struct
{
    struct Bucket *table; 

} HashTable;

static int hash(Key key,int tablesize)
{
    return (key % tablesize);
}

static int addPersonsToTable(HashTable *htable,const Person *personArray,int amount)
{
    int collissions = 0,i;
    for (i = 0; i < amount; i++)
    {
        int key = personArray[i].personalNumber;
        collissions += insertElement(htable,key,personArray[i]);
    }
    return collissions;
}

static int getRandomPersonalNumber(void)
{
    int day = rand() % 30 + 1; 
    int month = rand() % 12 + 1;
    int year = rand() % 60 + 40;
    return day + 100 * month + 10000 * year;
}

int insertElement(HashTable *htable,const Key key,const Value value)
{
    int coll;
    int index = hash(key,htable->size);
    coll = linearProbe(htable,&index);
    if (coll ==0 || index > -1)
    {
        htable->table[index].key = key;
        htable->table[index].value = value;
    }
    else
    {

    }

    return coll;
}

表测试。

-- Summary ----------------------
Average collisions on 1000 runs. Inserted 50 persons.
Table 1 (size 100) - average number of collisions: 516 - load factor: 0.50
Table 2 (size 150) - average number of collisions: 26 - load factor: 0.33
Table 3 (size 200) - average number of collisions: 68 - load factor: 0.25
Table 4 (size 250) - average number of collisions: 12 - load factor: 0.20
Table 5 (size 300) - average number of collisions: 26 - load factor: 0.17
Table 6 (size 350) - average number of collisions: 7 - load factor: 0.14
Table 7 (size 400) - average number of collisions: 16 - load factor: 0.13
Table 8 (size 450) - average number of collisions: 5 - load factor: 0.11
----------------------------------

解决方法

这是哈希表工作的自然结果；即使您的哈希值非常独特，当映射到一个小范围的可能值时，也会出现大量冲突。假设您的哈希函数是完全随机的，则预期负载因子为 usedSpace/availableSpace。

也就是说，您似乎错误地认为您的 .5 负载因子效率低下。这个负载系数非常好；例如，Java 的默认负载因子为 .75！对极少数元素进行线性搜索的效率很高，因此只要每个哈希位置中的元素数量很少，就不会造成真正的性能损失。

比散列冲突的总数更令人担忧的是，如果在同一个地方有大量的散列冲突，即你的散列不够随机。填充到单个哈希位置的元素越多，您的搜索时间就越线性；这就是为什么对哈希函数的保证比对哈希冲突的保证更重要。

编辑：虽然上述内容是正确的，但表大小 100（我误读为：哎呀）的异常高冲突是由于模数是 month 和 year 倍数的因子: 请看下面的评论。