Обґрунтування нехтування постійними факторами у Big O

Багато разів, якщо складності мають постійні, такі як 3n, ми нехтуємо цією константою і говоримо O (n), а не O (3n). Я не можу зрозуміти, як ми можемо знехтувати такими трикратними змінами? Деякі речі змінюються в 3 рази швидше, ніж інші! Чому ми нехтуємо цим фактом?

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

Наприклад, ми говоримо, що функція, яка виконує $3n$ кроків, є $O(n)$ , оскільки, грубо кажучи, для досить великих входів подвоєння розміру вводу не більше ніж удвічі збільшить кількість кроків. Аналогічно, $O(n^2)$ означає, що подвоєння вхідного розміру принаймні вчетверо збільшить кількість кроків, а $O(\log n)$ означає, що подвоєння вхідного розміру збільшить кількість кроків щонайбільше на деяку константу.

Це інструмент для того, щоб сказати, які алгоритми краще масштабуються, а не які - швидше.

По-перше, як уже пояснено в інших відповідях, , або, кажучи словами, функцією є O ( 3 n ), якщо і лише тоді, якщо це O ( n ) . f = O ( 3 n ) означає, що існує точка N і фактор C 3, такий, що для всіх n ≥ N , f ( n ) ≤ C 3 ⋅ $O(3n) = O(n)$$O(3n)$$O(n)$$f = O(3n)$$N$$C_3$$n \ge N$ . Тепер виберіть C 1 = 3 C 3 : для всіх n ≥ N , f ( n ) ≤ C 1 ⋅ n , тому f = O ( n ) . Доказ зворотного подібний.$f(n) \le C_3 \cdot 3n$$C_1 = 3 C_3$$n \ge N$$f(n) \le C_1 \cdot n$$f = O(n)$

Тепер перейдемо до причини, чому це правильний інструмент. Зверніть увагу, що вимірюючи складність алгоритму, ми не даємо одиниці. Ми не рахуємо секунд чи інструкцій на машині: ми підраховуємо кілька невказаних елементарних кроків, які мають кожен обмежений час. Ми робимо це тому, що виконання одного і того ж алгоритму на іншій машині змінило б час, необхідний для виконання інструкції - помножте тактову частоту на а час виконання перейде від f ( n ) до f ( n ) /$3$$f(n)$$f(n)/3$. Якщо ми реалізуємо один і той же алгоритм на іншій мові або в іншій системі, час, який відводиться на кожному елементарному кроці, може бути різним, але знову ж таки це занадто багато деталей: нас навряд чи цікавлять такі відмінності.

Якщо ви дбаєте про точні терміни, асимптотична складність не має значення: асимптотична складність повідомляє про те, що відбувається з дуже великими розмірами вводу, що може бути, а може і не бути фактичним розміром вводу, з яким ви маєте справу.

Нагадаємо, визначення Big-O:

якщо існує c > 0 , що f ( n ) ≤ c g ( n ) для всіх n .$f(n)\in O(g(n))$$c>0$$f(n)\le cg(n)$$n$

Під цим визначенням маємо, що для кожної постійної d . Метою нотації O є саме спрощення виразів таким чином. Дійсно, 3 n росте в 3 рази швидше, ніж n , але вони обидва лінійні. Це виправдано чи ні - це залежить від контексту. Але якщо ви погоджуєтесь використовувати позначення O , то за визначенням це справедливо.$dn\in O(n)$$d$$O$$3n$$n$$O$

Нотація великого O - це одиничне вільне середнє значення для вимірювання зміни продуктивності, таким чином, не спричиняє відносних витрат на обчислювальні примітиви.

Коротше кажучи: позначення Big O - це вільний одиничний розмір, відносний тип вимірювання (на відміну від абсолютного вимірювання). Він може вимірювати лише різницю продуктивності, а не абсолютну продуктивність, для якої константи мають велике значення. Перевага полягає в тому, що це робить його значною мірою незалежним від реалізації, дозволяючи простішим аналізом, який може ігнорувати відносні витрати на елементарні операції, якщо ці витрати мають позитивні фіксовану верхню та нижню межі. Але наслідок цього - постійні фактори безглузді . Тим не менш, навіть за призначенням, аналіз асимптотичної складності може бути поставлений під сумнів з інших причин , і до нього слід ставитися уважно. Наприклад, необмежений розмір введення може бути не правильним параметром, який слід враховувати.

Перше зауваження - це те, що ваше запитання не зовсім точно вказане. Якщо ви нехтуєте постійною в 3 n , то дійсно є "зміна в три рази", але обидві змінюються з однаковою швидкістю, і ви не можете стверджувати, що "[одна] річ змінюється в 3 рази швидше, ніж інша".$3$$3n$

Хорошим приводом ігнорувати константи в нотації Ландау є те, що у нас немає одиниці, на яку можна покластися. Коли хтось заявляє, що A живе вдвічі більше від вас, ніж B, це має значення незалежно від будь-якої одиниці. Ми можемо погодитися з цим, навіть якщо ти вимірюєш відстані в дюймах, поки я це роблю у світлові роки. Але для вимірювання абсолютної відстані потрібно вказати одиниці, і його числове формулювання залежить від обраної одиниці.

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

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

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

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

У будь-якому випадку, лише наївний програміст покладається виключно на асимптотичну складність вибору алгоритму. Існує багато інших критеріїв, включаючи незгадану постійну та фактичну вартість елементарних операцій. Крім того, найгірша складність може бути поганим показником, оскільки джерело найгіршого випадку складності може траплятися рідко, а на фрагментах вхідних даних досить малий, що має обмежений вплив. Наприклад, загальні аналізатори для прилягаючих до граматики дерев мають теоретичну складність , і цілком корисні на практиці. Найгірший випадок, про який я знаю, - це висновок поліморфного типу Дамаса-Хіндлі-Мілнера$O(n^6)$алгоритм, використовуваний для ML, який має експоненціальну найгіршу складність. Але це, схоже, не турбує користувачів ML, або перешкоджає написанню дуже великих програм в ML. Має значення більше, ніж константа. Власне, асимптотичний аналіз пов'язує міру витрат на обчислення з деякою мірою складності вхідних даних. Але розмір сировини може бути не правильним заходом.

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

Інші відповіді дають чудові пояснення, чому, згідно з визначенням Big-O, $O(n)=O(3n)$

$n$$3n$

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

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

означає lim sup n → ∞ f ( $f(n)=O(g(n))$$\limsup\limits_{n\to\infty} \frac{f(n)}{g(n)}<+\infty$

Якщо це справедливо для , це справедливо для g ( n ) = $g(n)=n$$g(n)=3n$

$O(n^2)=O(.00005321n^2+1000000000n+10^{46803})$$f$$=$

Дозвольте пояснити вам просто. Візьмемо n = 100000. Тепер, що таке 3n? Це 300000 ( так, це 3 складені n ) Але що таке n ^ 2 ? 10000000000 . ( це 1 лах складки n ) .. Порівняйте n ^ 2 з n. 3 незначно, якщо порівнювати з 1 лак. тож ми можемо її видалити.

Подумайте, чи n - це мільярди чи трильйони. У цьому випадку ми знову збираємось порівняти 3 з кількома мільярдами чи трильйонами. Тепер ви знаєте, чому ми можемо знехтувати 3.