когда изменить размер хэш-таблицы?
в различных реализациях хэш-таблицы я видел "магические числа", когда изменяемая хэш-таблица должна изменять размер (расти). Обычно это число находится где-то между 65% до 80% значений, добавленных на выделенные слоты. Я предполагаю, что компромисс заключается в том, что большее число даст потенциал для большего количества столкновений, а меньшее-за счет использования большего объема памяти.
мой вопрос в том, как этот номер прибыл?
это произвол? основываясь на тестировании? основываясь на какой-то другой логике?
5 ответов
на предположение, большинство людей, по крайней мере старт из чисел в книге (например, кнут, Том 3), которые были получены путем тестирования. В зависимости от ситуации, некоторые могут провести тестирование позже и внести соответствующие коррективы, но из того, что я видел, они, вероятно, в меньшинстве.
Как я изложил в предыдущий ответ, "правильный" номер, также сильно зависит от разрешения коллизий. Хорошо это или плохо, но факт остается фактом. широко игнорируется - люди часто не выбирают номера, которые особенно подходят для разрешения столкновений, которые они используют.
OTOH, другой момент, который я нашел в своем тестировании, заключается в том, что это редко имеет большое значение. Вы можете выбрать номера в довольно широком диапазоне и получить довольно похожую общую скорость. Главное, будьте осторожны, чтобы не нажимать слишком высокой, особенно если вы используете что-то вроде линейного зондирования для разрешения коллизий.
Я думаю, вы не хотите рассматривать "насколько заполнена" таблица (сколько "ведер" из общего количества ведер имеют значения), а скорее количество столкновений, которые могут потребоваться, чтобы найти место для нового элемента.
Я читал некоторые книги компилятора лет назад (не могу вспомнить название или авторов), которые предложили просто использовать связанные списки, пока у вас не будет более 10 до 12 элементов. Казалось бы, поддержка более 10 столкновений означает время для изменения размера.
дизайн и Реализация динамического. Хэширование для наборов и таблиц в Icon предполагает, что средней длины хэш-цепи 5 (в этом алгоритме среднее количество столкновений) достаточно для запуска повторного хэша. Кажется, поддерживается тестированием, но я не уверен, что правильно читаю статью.
похоже, что условие изменения размера в основном является результатом тестирования.
Это зависит от ключей. Если вы знаете, что ваш хэш-функция идеально подходит для всех возможных ключей (например, с помощью gperf), то вы знаете, что у вас будет только несколько столкновений, поэтому число выше.
но большую часть времени, вы не знаете много о ключах кроме того, что они являются текстовыми. В этом случае вы должны угадать, так как у вас даже нет тестовых данных, чтобы заранее выяснить, как ведет себя ваша хэш-функция.
Так что вы надейтесь на лучшее. Если у вас хэш-функция очень плоха для ключей, то у вас будет много коллизий и точка роста никогда не будет достигнута. В этом случае выбранная цифра не имеет значения.
Если ваша хэш-функция адекватна, то она должна создавать только несколько коллизий (менее 50%), поэтому число между 65% и 80% кажется разумным.
это сказало: если ваша хэш-таблица не должна быть идеальной (= огромный размер или много обращений), не беспокойтесь. Если у вас есть, скажем, десять элементов, рассмотрение этих вопросов-пустая трата времени.
насколько мне известно, число является эвристическим, основанным на эмпирическом тестировании.
при достаточно хорошем распределении хэш-значений кажется, что коэффициент магической нагрузки , как вы говорите, обычно составляет около 70%. Меньший коэффициент загрузки означает, что вы тратите пространство без реальной выгоды; более высокий коэффициент загрузки означает, что вы будете использовать меньше места, но тратить больше времени на хэш-коллизии.
(конечно, если вы знаете, что ваши хэш-значения отлично распределены тогда ваш коэффициент загрузки может быть 100% , и у вас все равно не будет пустого места и никаких хэш-коллизий.)
столкновения сильно зависят от данных и используемой хэш-функции.
большинство чисел, основанных на эвристике или предположении о нормальном распределении хэш-значений. (Значения AFAIK около 70% типичны для расширяемых хэш-таблиц, но всегда можно построить такой поток данных, что вы получите гораздо больше/меньше столкновений)