Чи існують реальні алгоритми, які значно перевершують клас нижче? [зачинено]

Минулої ночі я обговорював з іншим програмістом, що, хоча щось може бути O (1), операція, яка є O (n), може перевершити її, якщо в алгоритмі O (1) є велика константа. Він не погодився, тож я приніс це сюди.

Чи є приклади алгоритмів, які значно перевершують класи класу під ним? Наприклад, що O (n) швидше, ніж O (1) або O (n ² ) швидше, ніж O (n).

Математично це можна продемонструвати для функції з асимптотичною верхньою межею, якщо ви нехтуєте постійними факторами, але чи існують такі алгоритми в дикій природі? І де я можу знайти їх приклади? Для яких ситуацій вони використовуються?

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

Матричне множення. Наївний алгоритм O (n ^ 3) часто використовується на практиці так само швидше, ніж O (n ^ 2.8) Страссена для малих матриць; і для більш великих матриць використовується Страссен замість алгоритму Копперсміта — Винограда замість O (n ^ 2.3).

Простий приклад - різниця між різними алгоритмами сортування. Mergesort, Heapsort та деякі інші - O (n log n) . Квіксорт - це O (n ^ 2) найгірший випадок. Але часто Quicksort швидше, і насправді він виконує в середньому як O (n log n) . Більше інформації .

Інший приклад - це генерація єдиного числа Фібоначчі. Ітераційний алгоритм - O (n) , тоді як алгоритм на основі матриці - O (log n) . І все-таки для перших кількох тисяч чисел Фібоначчі ітераційний алгоритм, ймовірно, швидший. Це також залежить від виконання курсу!

Алгоритми з кращою асимптотичною продуктивністю можуть містити дорогі операції, які не потрібні в алгоритмі з гіршою продуктивністю, але більш прості операції. Зрештою, O- примітка лише нам щось говорить про продуктивність, коли аргумент, на який він працює, різко зростає (наближається до нескінченності).

Примітка: Прочитайте коментарі @ back2dos нижче та інших гуру, оскільки вони насправді корисніші за те, що я написав - Дякую всім учасникам.

Я думаю, що з наведеної нижче діаграми (взято з позначення Big O , пошук "Песимістичний характер алгоритмів:") ви бачите, що O (log n) не завжди кращий, ніж скажімо, O (n). Отже, я думаю, ваш аргумент справедливий.

Для практичних цінностей nтак. Це дуже багато в теорії CS. Часто існує складний алгоритм, який має технічно кращу велику продуктивність, але постійні фактори настільки великі, щоб зробити це недоцільним.

Я колись змусив свого професора обчислювальної геометрії описати алгоритм тріангуляції багатокутника за лінійним часом, але він закінчив "дуже складно. Я не думаю, що його реально реалізували" (!!).

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

Порівняйте вставку у зв’язаний список та вставлення у масив змінного розміру.

Кількість даних має бути досить великою, щоб вставити зв'язаний список O (1).

Зв'язаний список має додаткові накладні витрати для наступних покажчиків та відмежувань. Масив, що змінює розмір, повинен копіювати дані навколо. Це копіювання O (n), але на практиці дуже швидко.

Нотація Big-Oh використовується для опису швидкості росту функції, тому можливо, що алгоритм O (1) буде швидшим, але лише до певної точки (постійний коефіцієнт).

Поширені позначення:

O (1) - Кількість ітерацій (іноді ви можете позначати це як час, який користувач витрачає функція) не залежить від розміру вводу, а насправді є постійною.

O (n) - кількість ітерацій зростає в лінійній пропорції до розміру вводу. Значення - якщо алгоритм повторюється через будь-який вхід N, 2 * N разів, він все ще вважається O (n).

O (n ^ 2) (квадратична) - кількість ітерацій є вхідним розміром у квадрат.

Бібліотеки Regex зазвичай реалізуються для зворотного відстеження, що має найгірший експоненційний час, а не генерації DFA, що має складність O(nm).

Наївне зворотне відстеження може бути кращим виконавцем, коли вхід залишається на швидкому шляху або не вдається, без необхідності зайвого зволікання.

(Хоча це рішення базується не лише на ефективності, воно також має змогу повертатися назад.)

O(1)алгоритм:

def constant_time_algorithm
  one_million = 1000 * 1000
  sleep(one_million) # seconds
end

O(n)алгоритм:

def linear_time_algorithm(n)
  sleep(n) # seconds
end

Зрозуміло, що для будь-якого значення nде n < one_million, O(n)алгоритм, наведений у прикладі, буде швидшим, ніж O(1)алгоритм.

Хоча цей приклад трохи вибагливий, він по духу рівнозначний наступному прикладу:

def constant_time_algorithm
  do_a_truckload_of_work_that_takes_forever_and_a_day
end

def linear_time_algorithm(n)
  i = 0
  while i < n
    i += 1
    do_a_minute_amount_of_work_that_takes_nanoseconds
  end
end

Ви повинні знати константи і коефіцієнти у своєму Oвираженні, і ви повинні знати очікуваний діапазон n, щоб апріорі визначити, який алгоритм у результаті виявиться швидшим.

В іншому випадку ви повинні порівняти два алгоритми зі значеннями nв очікуваному діапазоні, щоб визначити, що після цього, який алгоритм виявився швидшим.

Сортування:

Сортування вставки - це O (n ^ 2), але перевершує інші алгоритми сортування O (n * log (n)) для невеликої кількості елементів.

Саме тому більшість сортування реалізацій використовують комбінацію двох алгоритмів. Наприклад, використовуйте сортування злиття для розбиття великих масивів, поки вони не досягнуть масиву певного розміру, а потім використовуйте вставку сортування, щоб сортувати менші одиниці та знову об'єднати їх із сортуванням злиття.

Див. Розділ Timsort про поточну реалізацію сортування Python та Java 7 за замовчуванням, які використовують цю методику.

Алгоритм об'єднання , що використовується на практиці, є експоненціальним у гіршому випадку для деяких патологічних входів.

Існує алгоритм об'єднання поліномів , але це занадто повільно на практиці.

Bubblesort в пам’яті може перевершити швидкодію, коли програма переходить на диск або потрібно читати кожен елемент з диска при порівнянні.

Це повинен бути приклад, до якого він може ставитися.

Часто більш досконалі алгоритми передбачають певну кількість (дорогих) налаштувань. Якщо вам потрібно запустити його лише один раз, вам може бути краще за допомогою методу грубої сили.

Наприклад: бінарний пошук і пошук хеш-таблиць обидва набагато швидше за пошук, ніж лінійний пошук, але вони вимагають, щоб ви сортували список або склали хеш-таблицю відповідно.

Сортування обійдеться вам N log (N), а хеш-таблиця обійдеться щонайменше N. Тепер, якщо ви збираєтеся робити сотні чи тисячі пошуку, це все-таки амортизована економія. Але якщо вам потрібно зробити лише один або два підшуки, можливо, буде просто сенс зробити лінійний пошук і заощадити вартість запуску.

Розшифровка часто 0 (1). Наприклад, простір ключів для DES становить 2 ^ 56, тому розшифровка будь-якого повідомлення є постійною операцією в часі. Це тільки те, що у вас є коефіцієнт 2 ^ 56, так що це дійсно велика константа.

Різні втілення наборів ведуть мені на думку. Одне з найбільш наївних - це реалізувати його над вектором, що означає remove, а також, containsтому і addвсі приймають O (N).
Альтернативою є його реалізація над деяким хешем загального призначення, який відображає хеши вводу на вхідні значення. Така реалізація набору виконується за допомогою O (1) для та add, containsа remove.

Якщо припустити, що N становить приблизно 10 або більше, то перша реалізація, ймовірно, швидша. Все, що потрібно зробити, щоб знайти елемент - це порівняти 10 значень з одним.
Інша реалізація повинна буде розпочати всілякі розумні перетворення, які можуть бути набагато дорожчими, ніж 10 порівнянь. З урахуванням усіх накладних витрат, у вас можуть бути навіть пропуски кешу, і тоді це насправді не має значення, наскільки швидким є теоретичне рішення.

Це не означає, що найгірша реалізація, яку ви можете придумати, перевершить гідну, якщо N досить мала. Це просто означає для досить малого N, що наївна реалізація, з низькою площею та накладними витратами, насправді може вимагати менших вказівок та спричиняти менше пропусків кешу, ніж реалізація, яка ставить масштабність на перше місце, а отже, буде швидшою.

Ви дійсно не можете знати, наскільки швидко все відбувається в реальному сценарії, поки ви не введете його в один і просто не виміряєте. Часто результати дивують (принаймні, для мене).

Так, для відповідно малих N. Завжди буде N, над яким ви завжди матимете впорядкування O (1) <O (lg N) <O (N) <O (N log N) <O (N ^ c ) <O (c ^ N) (де O (1) <O (lg N) означає, що в алгоритмі O (1) буде проведено менше операцій, коли N є відповідно великим, а c - деякою фіксованою постійною, що перевищує 1 ).

Скажімо, певний алгоритм O (1) займає точно f (N) = 10 ^ 100 (googol) операцій, а алгоритм O (N) займає рівно g (N) = 2 N + 5 операцій. Алгоритм O (N) буде давати більшу продуктивність, поки ви N буде приблизно рівним googol (насправді, коли N> (10 ^ 100 - 5) / 2), тож якщо ви лише очікували, що N буде в межах від 1000 до мільярда, ви зазнав би великого штрафу за допомогою алгоритму O (1).

Або для реалістичного порівняння скажіть, що ви множите n-значні числа разом. Алгоритм Карацуби - це щонайбільше 3 n ^ (lg 3) операцій (тобто приблизно O (n ^ 1,585)), тоді як алгоритм Шенгаге – Страссена - O (N log N log log N), що є швидшим порядком , але для цитування Вікіпедія:

На практиці алгоритм Шенгаге-Страссена починає перевершувати більш старі методи, такі як множення Карацуби та Тома – Кука для чисел, що перевищують 2 ^ 2 ^ 15 до 2 ^ 2 ^ 17 (від 10 000 до 40 000 десяткових цифр). [4] [5] [6 ]

Отже, якщо ви множите 500-цифрові числа разом, не має сенсу використовувати алгоритм, який "швидший" великими аргументами O.

EDIT: Ви можете визначити f (N) порівняно g (N), взявши межа N-> нескінченність f (N) / g (N). Якщо межа дорівнює 0, то f (N) <g (N), якщо межа є нескінченністю, то f (N)> g (N), а якщо межа є якоюсь іншою постійною, то f (N) ~ g (N) з точки зору великого O позначення.

Симплексний метод лінійного програмування в гіршому випадку може бути експоненціальним, тоді як відносно нові алгоритми точок інтер'єру можуть бути поліноміальними.

Однак на практиці найгірший показник для симплексного методу не підходить - симплексний метод швидкий і надійний, тоді як ранні алгоритми внутрішніх точок були занадто повільними, щоб бути конкурентоспроможними. (Зараз є більш сучасні алгоритми точок інтер'єру, які є конкурентоспроможними - але симплексний метод теж ...)

Алгоритм Укконена для побудови суфіксних спроб становить O (n log n). Він має перевагу в тому, що він є "он-лайн" - тобто ви можете поступово додавати більше тексту.

Останнім часом інші більш складні алгоритми стверджують, що на практиці більш швидкі, значною мірою тому, що доступ до пам'яті має більш високу локальність, тим самим покращуючи використання кеш-процесора та уникаючи зупинок конвеєра конвеєра. Дивіться, наприклад, це опитування , в якому стверджується, що 70-80% часу на обробку витрачається на очікування пам'яті, і цей документ, що описує алгоритм "wotd".

Суфіксні спроби мають важливе значення в генетиці (для узгодження послідовностей генів) і, що не менш важливо, у реалізації словників Scrabble.

Завжди є найшвидший і найкоротший алгоритм для будь-якої чітко визначеної проблеми . Це лише чисто теоретично (асимптотично) найшвидший алгоритм.

З огляду на будь-який опис проблеми P і екземпляр для цього завдання I , він перебирає всі можливі алгоритми і докази Pr , перевіряючи для кожної такої пари чи Pr є допустимим доказом того, що є асимптотично швидкий алгоритм для P . Якщо він знаходить такий доказ, він потім виконує А на I .

Пошук цієї пари, що підтверджує проблему, має складність O (1) (для фіксованої проблеми P ), тому ви завжди використовуєте алгоритм найсильнішого асимптотичного завдання. Однак, оскільки ця константа настільки невимовно величезна майже у всіх випадках, цей метод на практиці абсолютно марний.

Багато мов / фреймворків використовують наївні відповідність візерунка, щоб відповідати рядкам замість KMP . Ми шукаємо такі струни, як Том, Нью-Йорк, а не абабаабабабабабаабабабабабаб.