Например, при написании класса словаря коллизии случаются редко, но они существуют. В результате вам нужно сохранить ключ, чтобы убедиться, что когда вы найдете свой ключ в хэш-таблице, он будет правильным, а не коллизией.
Иногда ключи длинные и обычно представляют собой строки, поэтому каждый ключ может иметь размер более 40 байт по сравнению с тем, если бы это был просто хэш-код. Что, если сохраненный ключ был хешированным объектом, но с использованием немного другого алгоритма хеширования с другими простыми числами? Тогда вероятность столкновения будет (1/(2^32)) * (1/(2^32)).
Вы даже можете использовать другой алгоритм хеширования и вместо этого хранить этот хэш, поэтому шансы на коллизию будут (1/(2^32)) * (1/(2^32)) * (1/(2^32)). Очевидно, что коллизия ВСЕ ЕЩЕ может произойти, но шансы настолько малы, и вы экономите так много памяти, сохраняя только 4 байта для ключа вместо более 32 байтов.
Я предполагаю, что это по-прежнему неприемлемо, верно, потому что все еще есть ШАНС, но также есть шанс, что чья-то оперативная память может случайно немного перевернуться и появится синий экран, и это кажется настолько маловероятным, что заманчиво не реализовать. Есть ли какие-то альтернативы или маленький шанс все же не стоит того?
dictionaryзаключается в том, что у вас есть известный уникальный индексатор, и вы хотите найти значение, хранящееся в этом индексе. Если у вас есть нестандартный хэш, который вы можете получить только из самого объекта, вам, вероятно, не нужен словарь, а только список. - person ps2goat schedule 03.03.2015(1/(2^32)) * (1/(2^32)) * (1/(2^32)) * (1/(2^32)) * (1/(2^32)) * (1/(2^32))или1.59 × 10^-58Очевидно, что хеширование не совсем однородно, поэтому я вынул много порядков, чтобы компенсировать. - person John Smith schedule 03.03.2015