Хэш-код — это индекс, а хэш-таблица на самом низком уровне — это массив. Но для заданного значения ключа мы определяем индекс в хэш-таблице по-разному, чтобы обеспечить гораздо более быстрое извлечение данных.
Пример: у вас есть 1000 слов и их определений. Вы хотите сохранить их, чтобы вы могли получить определение слова очень, очень быстро — быстрее, чем бинарный поиск, который вам пришлось бы делать с массивом.
Итак, вы создаете хэш-таблицу. Вы начинаете с массива, значительно превышающего 1000 записей, скажем, 5000 (чем больше, тем эффективнее время).
Вы будете использовать свою таблицу следующим образом: вы берете слово для поиска и конвертируете его в число от 0 до 4999. Вы выбираете алгоритм для этого; это алгоритм хеширования. Но вы, несомненно, могли бы написать что-то, что было бы очень быстро.
Затем вы используете преобразованное число в качестве индекса в свой массив из 5000 элементов и вставляете/находите свое определение по этому индексу. Нет никакого поиска: вы создали указатель непосредственно из слова для поиска.
Все операции, которые я описал, выполняются с постоянным временем; ни один из них не занимает больше времени, когда мы увеличиваем количество записей. Нам просто нужно убедиться, что в хеше достаточно места, чтобы свести к минимуму вероятность «коллизий», то есть вероятность того, что два разных слова будут преобразованы в один и тот же целочисленный индекс. Поскольку это может случиться с любым алгоритмом хеширования, нам нужно добавить проверки, чтобы увидеть, есть ли коллизия, и сделать что-то особенное (если «hello» и «world» оба хэшируют до 1234, а «hello» уже есть в таблице, что что мы будем делать с «миром»? Проще всего поместить его в 1235 и настроить нашу логику поиска, чтобы учесть эту возможность.)
Редактировать: после повторного прочтения вашего сообщения: алгоритм хеширования определенно не является случайным, он должен быть детерминированным. Индекс, сгенерированный для «привет» в моем примере, должен быть равен 1234 каждый раз; это единственный способ поиска может работать.
person
Community
schedule
23.05.2009