O (1) хеш смотрит вверх?

Я столкнулся с утверждением, что HashSet <T> .Contains() является операцией O (1). Это меня удивило, так как каждое обсуждение хеширования, с которым я столкнулся, упоминает о возможности коллизий, что потенциально приводит к времени выполнения O (n).

Будучи любопытным, я просмотрел документацию для HashSet <T> .Contains, а также HashTable.Contains. Документация для обоих методов делает то же утверждение.

Когда я смотрю в отражатель, HashSet <T> .Contains() реализуется с циклом for, проходя через список слотов, содержащих значения, которые имеют одинаковый хэш.

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

Итак, неверно ли утверждение O (1)? Или я что-то упускаю?

Ответ 1

Но мое понимание нотации Big O заключается в том, что это наихудшее время выполнения, а не лучше.

К сожалению, при описании алгоритмов нет "стандарта" для Big-O. Часто он использовал для описания общего или среднего случая - не худший случай.

От Wikipedia:

... эта нотация часто также используется при анализе алгоритмов для описания использования алгоритмов вычислительных ресурсов: наихудший случай или средний случай...

В этом случае он описывает стандартный случай, учитывая правильное хеширование. Если у вас есть правильное хеширование на месте, предельное поведение будет постоянным для размера N, следовательно, O (1).

Ответ 2

В целом, это O (1).

Ответ 3

Для правильно реализованной хеш-таблицы look ups amortized постоянная сложность времени.

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

Цитата: Википедия:

Амортизированный анализ отличается от среднего показателя производительности тем, что вероятность не участвует; амортизированный анализ гарантирует время на операцию по наихудшей производительности.

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

Ответ 4

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

Ответ 5

Я считаю, что в среднем это означает O (1).

Ответ 6

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

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

В гайке, да HashSet и Dictionary можно описать как имеющую сложность выполнения O (1), поскольку акцент делается на сценарии среднего размера.

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

Ответ 7

Мое понимание Big Oh заключается в том, что "наихудший случай" обычно относится к числу задействованных элементов. Поэтому, если функция должна была выполнять O (n) с 10 элементами, но O (n квадрат) с 100 или более (не уверен, что такой алгоритм фактически существует), то алгоритм считается O (n квадратом).

Ответ 8

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

Ответ 9

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