LINUX.ORG.RU

Хэш-таблица с прямой адресацией

 ,


0

1

Помогите разобрать теорию. При прямой адресации к хэш-таблице ключи перенумерованы целыми числами из множества. Ну и понятно, что тогда к элементу массива (хэш-таблицы) мы добираемся за время O(1).

Но, чтобы по произвольному ключу получить его индекс, требуется время O(n), если эти ключи храняться в списке или массиве, или O(log(n)), если ключи и их индексы хранит сбалансированное двоичное дерево.

Или, все-таки здесь все полагают, что всегда можно придумать hash функцию с трудоемкостью O(1)? Например, есть множество ключей: «one», «two» ..., например n штук. причем n известно. Как добиться разыменования «one»->1, «two»->2 ... за O(1), а не O(n)?



Последнее исправление: CYB3R (всего исправлений: 2)

если эти ключи храняться в списке или массиве, или O(log(n)), если ключи и их индексы хранит сбалансированное двоичное дерево.

А зачем? Если затраты на адресацию незначительны, то и не стоит усложнять.

Ну а сбалансированное дерево всегда даёт ln(X). O тут не при чём.

ziemin ★★
()
Ответ на: комментарий от ziemin

А зачем? Если затраты на адресацию незначительны, то и не стоит усложнять.

смысл хэш-таблицы --- добраться до значения за O(1) по ключу

Ну а сбалансированное дерево всегда даёт ln(X). O тут не при чём.

так трудоемкость оценивается (O, Theta, Omega ...)

linux276
() автор топика

Как добиться разыменования «one»->1, «two»->2 ... за O(1), а не O(n)?

В общем случае никак.

Или, все-таки здесь все полагают, что всегда можно придумать hash функцию с трудоемкостью O(1)?

Сложность алгоритма обязана зависеть, очевидно, от количества ключей, а не от их средней длины.

mix_mix ★★★★★
()
Ответ на: комментарий от mix_mix

похоже только подбор наиболее эффективной хэш-функции позволит делать эффективную хэш-таблицу

Как добиться разыменования «one»->1, «two»->2 ... за O(1), а не O(n)?

В общем случае никак.

Или, все-таки здесь все полагают, что всегда можно придумать hash функцию с трудоемкостью O(1)?

Сложность алгоритма обязана зависеть, очевидно, от количества ключей, а не от их средней длины.

linux276
() автор топика
Ответ на: комментарий от linux276

так трудоемкость оценивается (O, Theta, Omega ...)

Это если в рантайме. Хорошо построенное дерево даёт ln(X).

Ты что, их тех дибилов, которые для проверки сортировки латинских букв заполняешь массив случайными байтами? И ещё и в юникоде? Эдика на тебя нет.

ziemin ★★
()
Ответ на: комментарий от linux276

Эффективность хэш-функции определяется лишь количеством коллизий. В качестве одной можно взять убогую strlen(key)%buckets, а можно murmur(key)%buckets, — все они будут работать за линейное время относительно длины ключа, но эффективность разная будет, да.

Сложность доступа же по ключу в обоих случаях будет оставаться амортизированной константой относительно количества ключей с высокой вероятностью (т.е. при определённом load factor).

mix_mix ★★★★★
()
Последнее исправление: mix_mix (всего исправлений: 1)

Например, есть множество ключей: «one», «two» ..., например n штук. причем n известно.

делаешь n в виде чисел, которые будут смещения от обзей базы, делаешь джамп база + смещение на новую точку исполнения.

dimon555 ★★★★★
()
Ответ на: комментарий от ziemin

Поля ЛОРа слишком малы, чтобы я мог доказать.

Конечно, публика ЛОРа просто не доживёт до времени когда ты узнаешь что такое балансировнное дерево, познакомишься с видами оценок сложностей и с многими другими интересными вещами о которых тут иногда упоминают.

mashina ★★★★★
()

самое не замысловатое решение: иметь 2 хеш таблицы, прямую и обратную

novoxudonoser
()

Но, чтобы по произвольному ключу получить его индекс,

Его индекс - это выхлоп хеш-функции, в чем проблема?

требуется время O(n), если эти ключи храняться в списке или массиве, или O(log(n)), если ключи и их индексы хранит сбалансированное двоичное дерево.

Требуется время порядка, а не просто. Что из этого следует?

Или, все-таки здесь все полагают, что всегда можно придумать hash функцию с трудоемкостью O(1)?

Для общего случая таких нет. В примитивной школьной O-нотации все клали и на трудоёмкость единицы, поэтому всем насрать сколько там работает твоя хешфункция.

Как добиться разыменования «one»->1, «two»->2 ... за O(1), а не O(n)?

Что значит разыменования? По талмуду средний случай - это m[hash(«one»)] == 1; В чем конкретно заключается твой вопрос?

anonymous
()
Ответ на: комментарий от ziemin

Идеально сбалансированное дерево, а не сбалансированное. Просто сбалансированное даёт порядок логарифма, т.е. +- трамвайная остановка.

anonymous
()
Ответ на: комментарий от ziemin

Ну а сбалансированное дерево всегда даёт ln(X). O тут не при чём.

Болван и неуч! Учи нотацию! Натуральный логарифм это ему дает! А с O можно писать хоть O(ln(n)), хоть O(log(n)), разницы нет. Угадаешь почему?

anonymous
()

что всегда можно придумать hash функцию с трудоемкостью O(1)?

Да

Как добиться разыменования «one»->1, «two»->2

Обычно это не требуется, достаточно чтобы «one»->n_1, «two»->n_2 и т.д. причём n_i<N. Простейший вариант - сумма байт по модулю 256. Ещё быстрее - просто значение первого байта.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от ziemin

Ну а сбалансированное дерево всегда даёт ln(X). O тут не при чём.

O всегда при том =).

Waterlaz ★★★★★
()

Если я тебя правильно понял, то ты смешиваешь всё в кучу. Тут два разных «n». Одно - размер хэш таблицы, другое - длина аргумента хэш-функции (при условии что это вообще текст, ведь может быть и число, например индекс БД).

invy ★★★★★
()

вносите царя

anonymous
()
Ответ на: комментарий от parrto

Он либо пишет задания для соискателей в янбекс, либо пытается их выполнить.

ieeya
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.