Большой O или Большой Θ?

Я знаю разницу Big O и Big Θ, но я могу найти несколько случаев, когда мне действительно нужно использовать Big O или Big Ω вместо Big Θ.

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

С одной стороны, просто говорит, что время работы алгоритма без указания сложности случая неоднозначно. С другой стороны, если это относится к одному из этих случаев, Big O и Big Ω теряют свое приложение, потому что мы специфичны для случая и не более или не менее теряют смысл. Мы просто можем вычислить T (n) или использовать Θ, если хотим быть грубыми.

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

Тогда как или почему мы должны использовать O или Ω для времени работы этого алгоритма? Не забудьте указать ответ на этот конкретный экземпляр.

Я не ищу их объяснения, просто некоторые реальные примеры, которые нам действительно нужны Big O, а не Big Θ.

Ответ 1

частичный небольшой ответ

Используйте Θ, когда это известно, потому что оно одновременно передает сообщение об O и Ω. Тем не менее вы удваиваете свои шансы быть неправильными, как в комментариях. Когда неизвестно использовать Ω

Длинный ответ

Это не имеет значения. Что измеряется, big O notation, анализ случая - это ортогональные размеры в одном и том же проблемном пространстве.

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

Теперь предоставление наивысших оценок времени выполнения в худшем случае является наиболее популярным типом анализа.

Примечание:

Если вам дана домашняя работа, она должна указать что-то вроде

какая худшая временная сложность этого алгоритма в терминах O.

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

Чтобы быть прямым, какие обозначения (O, Θ или Ω) и какое время мы должны использовать на время быстрого алгоритма сортировки, почему?

В чем смысл (O, Θ or Ω)?

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

Среднее значение joe alg. дизайнер найдет алгоритм O(n^3), используя наивный метод. Это не так неэффективно, поэтому он движется дальше.
Далее Штрассен узнает, что его можно улучшить до O(n^2.807)
Теперь люди начинают спрашивать, может ли он быть улучшен дальше.
Часть этого вопроса как дальше?. Чтобы ответить, вам нужно предоставить нижние границы Ω. чем выше, тем лучше. Одна оценка - Ω(n^2). Конкретная оценка Ω(n^2 log(n)). Они не демонстрируются путем предоставления алгоритмов, но могут быть выведены из описания проблемы.
Теперь, когда разработчик алгоритма, если вы нажмете сложность верхней границы O(n^2 log(n)) для вычисления матрицы, вы знаете, что попали в джэкпот. Когда вы нажимаете на джэкпот, вы начинаете использовать Θ для передачи двух сообщений одновременно.
Поскольку никто еще не ударил джекпот, люди выражают новые результаты в алгоритмах умножения матрицы в лучших верхних границах, например O(n^2.237)

Пример другой нижней оценки в худшем случае - перераспределение в массивах

Скажем, вы реализуете набор, используя массив. Чтобы вставить элемент, вы просто помещаете в следующий доступный ковш. Если нет свободного ведра, вы увеличиваете емкость массива на значение m.

Для алгоритма вставки "недостаточно места" - худший случай.

 insert (S, e)
   if size(S) >= capacity(S) 
     reserve(S, size(S) + m)
   put(S,e)

Предположим, мы никогда не удаляем элементы. Следя за последней доступной позицией, put, size и capacity являются Θ(1) в пространстве и в памяти.

Как насчет reserve? Если он реализован как realloc в C, в лучшем случае вы просто выделите новую память в конце существующей памяти (лучший вариант для резерва), или вам нужно также перемещать все существующие элементы (худший вариант для резерва).

Нижняя граница наихудшего случая для insert - лучший случай reserve(), который является линейным в m, если мы не зацикливаемся. insert в худший случай Ω(m) в пространстве и времени.
Верхняя граница наихудшего случая для insert - худший случай reserve(), который является линейным по m+n. insert в худшем случае O(m+n) в пространстве и времени.

Ответ 2

Big O и лучший/средний/худший взгляд на различные аспекты скорости выполнения.

Big O/Big Θ не говорят, сколько времени требуется для выполнения некоторого кода.
В нем указано, как время работы зависит от размера ввода.

Фактическое время зависит от множества факторов, почти все из которых игнорируются. (см. сноску ниже)

Лучший/худший/средний/типичный - совершенно другой взгляд на время работы. Они (обычно) более специфичны, чем нотация Big O, но часто время указывается в Big (O):

Типичным временем для поиска хэш-таблицы является O (1). В худшем случае O (N)

Обратите внимание, что это утверждение технически неверно: Big O не указывает время. Педантичная версия этого утверждения:

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

Сноска:

Нотация Big O даже игнорирует все, кроме самого быстрорастущего.

Если у вас есть два алгоритма с детерминированным временем выполнения

tA(N) = 10s * N^2 + 1s * N + 42 days 
tB(N) = 1 day * N^2

Оба будут O(N^2)

Несмотря на то, что вторая явно хуже для больших N, это не выражается в Big O.

Имейте в виду, что хотя время работы является наиболее распространенным при использовании нотации Big O, оно также может использоваться для использования в памяти или для конкретных операций, таких как доступ к диску или свопы.

Относительно вашего обновления:

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

Формально: если он не указан, он не указан.

Неформально, независимо от того, что имеет смысл в данном контексте. Если ничего не указано, большинство людей будет считать, что это средний или, по крайней мере, типичный случай, - но насколько вы полагаетесь на это, зависит от вас.

Сортировка раздела:

Формально, не указывая случай, - Любой O(f(N)) >= O(N^2) формально корректен, не указывая случай. Даже O(N^N) будет правильным, просто не полезно. - То же самое для любого Ω(f(N)) <= O(n lg n)

Спецификация

То, что нужно указать, зависит от контекста.

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

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

С другой стороны, полная спецификация будет определять алгоритм достаточно, чтобы вы могли рассчитать O и Ω для всех случаев самостоятельно - так же как и больше. Как уже было сказано, Big O/Ω может быть недостаточным для принятия обоснованного решения о работе во время выполнения.

Взаимосвязь между тем, что необходимо:

Как правило, O чаще встречается, чем другие, потому что Ω почти никогда не актуальна, и Θ не всегда доступна.
Если задано только одно значение, это обычно среднее или типичное время, поскольку это позволяет судить о "значении" алгоритма.
Если указаны два значения, это в худшем случае дополнительно, поскольку последний является наиболее распространенным критерием при сравнении алгоритмов с идентичным типичным поведением или у вас есть требования в реальном времени.
Следующим шагом будут условия, при которых производительность ухудшается. Поскольку алгоритм, который является "O (N) типичным, O (N ^ 2) для одного в миллионах входов" является чем-то совершенно отличным от "O (N), типичным, O (N ^ 2) в понедельник утром".
Если этого еще недостаточно, вы обычно увидите максимальное количество конкретных операций, таких как "не более N ^ 2 + 1 товарищей и N/2-1 свопов".

Ответ 3

Таким образом, как theta, так и O, если не указано иное, обычно относятся к среднему времени работы алгоритма. Следовательно, сортировка разделов - это O (nlogn) и theta (nlogn).

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

Например, когда умножает матрицы, ясно, что у вас может быть алгоритм O (n ^ 3), так как вы это сделаете это вручную. Наиболее известный алгоритм - это тета (n ^ 2.4), грубо говоря. Однако некоторые другие математики утверждали, что нижняя граница алгоритма - Омега (n ^ 2 log n), и все же другие исследователи утверждают, что это неправильно, и что существует алгоритм тета (n ^ 2).