Является ли бинарный поиск оптимальным в худшем случае?

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

многие люди сказали, что вопрос был неясным. Прости! Таким образом, вход-это любой общий отсортированный массив. Я ищу доказательство, которое говорит, что любой алгоритм поиска займет по крайней мере log2(N) сравнения в наихудшем случае (наихудший случай для рассматриваемого algo).

5 ответов


да, бинарный поиск является оптимальным.

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

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

преобразовать эту последовательность в двоичную строку (1,0,0,1). Назовите эту двоичную строку "сигнатурой элемента относительно алгоритма X". Сделайте это для каждого элемента массива, присвоив каждому элементу "подпись".

теперь вот ключ. Если два элемента имеют одинаковую сигнатуру, то алгоритм X не может их различить! Все алгоритм знает про такие ответы он получает от вопросов он задает, т. е. сравнения, которые он выполняет. И если алгоритм не может различить два элемента, то он не может быть правильным. (Другими словами, если два элемента имеют одну и ту же сигнатуру, то есть они приводят к одной и той же последовательности сравнений алгоритмом, какой из них вернул алгоритм? Противоречие.)

наконец, докажите, что если каждая подпись имеет меньше log N bits, тогда должны существовать два элемента с одной и той же сигнатурой (принцип pigeonhole). Сделанный.

[обновление]

один быстрый дополнительный комментарий. Вышесказанное предполагает, что алгоритм ничего не знает о массиве, кроме того, что он узнает от выполнения сравнения. Конечно, в реальной жизни, иногда вы знаете что-то о массиве априори. Как игрушечный пример, если я знаю, что массив имеет (скажем) 10 элементов от 1 до 100, и что они различны, и что числа 92-100 присутствуют в массиве... Тогда, очевидно, мне не нужно выполнять четыре сравнения даже в худшем случае.

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

но в целом случай, бинарный поиск по-прежнему оптимален.


худший случай для алгоритма? Нет ни одного универсального "худшего случая".- Если это твой вопрос...

"есть случай, когда двоичный поиск требует больше сравнений, чем другой алгоритм?"

тогда, да, конечно. Простой линейный поиск займет меньше времени, если элемент является первым в списке.

" есть ли даже алгоритм с лучшим временем работы в худшем случае, чем двоичный поиск?"

да, в тех случаях, когда вы знаете больше о данных. Например, дерево radix или trie в худшем случае является постоянным по количеству записей (но линейным по длине ключа).

" существует ли общий алгоритм поиска с лучшим временем работы в худшем случае, чем двоичный поиск?"

Если вы можете только предположить, что у вас есть функция сравнения на ключах, нет, лучшим худшим случаем является O (log n). Но есть алгоритмы, которые быстрее, просто не в big-O чувство.

... поэтому, я полагаю, вам действительно нужно сначала определить вопрос!


бинарный поиск имеет худший случай сложности O(log(N)) сравнения-что является оптимальным для поиска на основе сравнения отсортированного массива.

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


Это зависит от характера данных. Например, английский язык и словарь. Вы можете написать алгоритм для достижения лучшего, чем двоичный поиск, используя тот факт, что определенные буквы встречаются в английском языке с разными частотами.

но в целом бинарный поиск является безопасной ставкой.


Я думаю, что вопрос немного непонятно, но все же вот мои мысли.

худший случай двоичного поиска будет, когда элемент, который вы ищете, найден после всех сравнений журнала N. Но те же данные могут быть наилучшим случаем для линейного поиска. Это зависит от расположения данных и того, что вы ищете, но худший случай для двоичного поиска в конечном итоге будет log n. Теперь это нельзя сравнить с теми же данными и искать линейный поиск, так как в худшем случае быть иными. Худшим случаем для линейного поиска может быть поиск элемента, который находится в конце массива.

пример: массив A = 1, 2, 3, 4, 5, 6 и бинарного поиска на 1 будет в худшем случае. В то время как для того же массива линейный поиск 6 был бы худшим случаем, а не поиском 1.