9.3. Заказанные карты 397

Мы иллюстрируем алгоритм двоичного поиска в рисунке 9.7.

Рисунок 9.7: Пример двоичного поиска, чтобы выполнить операцию находит (22), в карте с ключами целого числа, осуществленными с заказанным вектором. Для простоты мы показываем ключи, не целые записи.

Рассматривая продолжительность двоичного поиска, мы замечаем, что постоянная цифра - частота ошибок по битам примитивных операций выполнена в каждом рекурсивном вызове Двоичного поиска функции. Следовательно, продолжительность пропорциональна числу выполненных рекурсивных вызовов. Решающий факт - то, что с каждым рекурсивным вызовом число записей кандидата все еще, чтобы быть обысканным в векторе L дано стоимостью

высоко- низко + 1.

Кроме того, количество остающихся кандидатов сокращено по крайней мере одной половиной с каждым рекурсивным вызовом. Определенно, из определения середины, число остается - кандидаты луга также

(середина- 1)- низко + 1 = низко + высоко- низкий£ высокий-2low + 1 2

или высоко- (середина + 1) + 1 = высоко- низко + высокий£ высокий-2low + 1. 2

Первоначально, число записей кандидата - n; после первого звонка в BinarySearch это в большей части n/2; после второго требования это в большей части n/4; и так далее. В целом, после того, как ith звонят в BinarySearch, число остающихся записей кандидата в большей части n/2i. В худшем случае (неудачный поиск), останавливаются рекурсивные вызовы, когда больше нет записей кандидата. Следовательно, максимальное количество выполненных рекурсивных вызовов, является самым маленьким целым числом m, такой что

n/2m <1.

398

Глава 9. Хеш-таблицы, Карты и Списки Пропуска, Другими словами (вспоминающий, что мы опускаем основу логарифма, когда это 2), m> регистрируют n. Таким образом мы имеем

m =⌊log n ⌋ + 1,

который подразумевает, что пробеги двоичного поиска в O (регистрируют n), время.

Таким образом мы можем использовать заказанный стол поиска, чтобы выполнить быстрые поиски в заказанном

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

Сравнение внедрений карты

Обратите внимание на то, что мы можем использовать заказанный стол поиска, чтобы осуществить карту ADT, даже если мы не хотим использовать дополнительные функции заказанной карты ADT. Таблица 9.2 сравнивает продолжительность функций (стандартной) карты, понятой или незаказанным списком, хеш-таблицей или заказанным столом поиска. Обратите внимание на то, что незаказанный список допускает быстрые вставки, но медленные поиски и удаления, тогда как поиск ta-ble допускает быстрые поиски, но медленные вставки и удаления. Случайно, хотя мы явно не обсуждаем его, мы отмечаем, что сортированный список, осуществленный с вдвойне связанным списком, был бы медленным в выполнении почти всех операций по карте. (См. Exer-cise R-9.5.), Тем не менее, подобная списку структура данных, которую мы обсуждаем в следующей секции, может выполнить функции заказанной карты ADT вполне эффективно.

Метод

Список

Хеш-таблица

Стол поиска

размер, пустой

O (1)

O (1)

O (1)

найти

O (n)

O (1) экспорт, O (n) худший случай

O (регистрируют n),

вставка

O (1)

O (1)

O (n)

стереть

O (n)

O (1) экспорт, O (n) худший случай

O (n)

Таблица 9.2: Сравнение продолжительности функций карты поняло посредством незаказанного списка, хеш-таблицы или заказанного стола поиска. Мы позволяем n обозначить число записей в карте, и мы позволяем N обозначить способность множества ведра во внедрении хеш-таблицы. Космическое требование всех внедрений - O (n), предполагая, что множества, поддерживающие хеш-таблицу и внедрения стола поиска, сохраняются таким образом, что их способность пропорциональна числу записей в карте.