Я не раз чув, що для досить малих значень n, O (n) можна думати про / трактувати так, ніби це O (1).

Приклад :

Мотивація цього ґрунтується на неправильній ідеї, що O (1) завжди кращий, ніж O (lg n), завжди кращий, ніж O (n). Асимптотичний порядок операції є актуальним лише в тому випадку, якщо за реалістичних умов розмір проблеми фактично стає великим. Якщо n залишається малим, то кожна проблема - O (1)!

Що достатньо мало? 10? 100? 1000? У який момент ви говорите "ми більше не можемо ставитися до цього, як до безкоштовної операції"? Чи є правило:

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

Всі порядки включають постійну , фактично декілька з них. Коли кількість предметів досить велика, ця константа не має значення. Питання в тому, чи кількість предметів є достатньо малою, щоб ця константа домінувала.$C$

Ось наочний спосіб подумати про це.

Усі мають постійну старт, яка визначає їх початкову точку на осі Y. Кожен також має критичну константу домінує, як швидко вони зростатимуть.$C$

• Для , С визначає час.$O(1)$$C$
• дійсно C × n , де C визначає кут.$O(n)$$C \times n$$C$
• - це дійсно ( C × n ) 2 , де C визначає різкість кривої.$O(n^2)$$(C \times n)^2$$C$

Щоб визначити, який алгоритм слід використовувати, потрібно оцінити місце, де перетинаються періоди виконання. Наприклад, рішення з високим часом запуску або високим C втрачає рішення O ( n ) з низьким часом запуску і низьким C при досить великій кількості елементів.$O(1)$$C$$O(n)$$C$

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

Ось приклад CS. Скажімо, вам потрібен список, який завжди сортується. Ви можете використовувати дерево, яке збереже себе в порядку для . Або ви можете використовувати несортований список і пересортувати після кожного вставки або видалення в O ( n log n ) . Оскільки операції з деревом є складними (у них висока константа), а сортування настільки просте (низька константа), список, ймовірно, виграє сотні чи тисячі елементів.$O(\log{n})$$O(n \log{n})$

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

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

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

Показово, що питання обговорює "досить малі значення n ". Вся суть Big-O полягає в тому, щоб описати, як обробка зростає як функція того, що обробляється. Якщо дані, що обробляються, залишаються невеликими, неважливо обговорювати Big-O, тому що вас не цікавить зростання (що не відбувається).

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

Для малих росіян використовуйте все, що зручно.

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

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

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

Більш практичне справу, що, коли ми говоримо , що час роботи алгоритму є , це означає тільки те , що вона асимптотично з п 2  кроку, для деякої константи  C . Тобто є деяка константа n 0 така, що для всіх n ≥ n 0 алгоритм виконує приблизно c n 2 кроки. Але може бути n 0 = 100 , 000 , $\Theta(n^2)$ $cn^2$$C$$n_0$$n\geq n_0$$cn^2$$n_0=100,000,000$і вас цікавлять лише екземпляри, розміри яких набагато менші. Асимптотична квадратична межа може навіть не застосовуватися до ваших невеликих примірників. Можливо, вам пощастить, і на невеликих входах це може бути швидше (або ви можете не пощастити і повільніше). Наприклад, для малих  , n 2 < 1000 n, тому ви краще запустите квадратичний алгоритм з хорошими константами, ніж лінійний алгоритм з поганими константами. Прикладом реального життя є те, що асимптотично найефективніші алгоритми множення матриці (варіанти Копперсміта – Винограда , що працюють в часі O ( n 2.3729 ) ) рідко використовуються на практиці, оскільки О Strassen's$n$$n^2 < 1000n$$O(n^{2.3729})$ алгоритм швидший, якщо ваші матриці дійсно великі.$O(n^{2.8074})$

Третій момент полягає в тому, що якщо  малий, n 2 і навіть n 3  малі. Наприклад, якщо вам потрібно сортувати кілька тисяч елементів даних і вам потрібно сортувати їх лише один раз, будь-який алгоритм сортування досить хороший: a Θ ( n 2$n$$n^2$$n^3$$\Theta(n^2)$Алгоритм все ще потребує, можливо, декількох десятків мільйонів інструкцій для сортування ваших даних, що зовсім не так багато часу на процесорі, який може виконувати мільярди інструкцій в секунду. Гаразд, також є доступ до пам'яті, але навіть повільний алгоритм займе менше секунди, тому, мабуть, краще скористатися простим, повільним алгоритмом і правильно його, ніж використовувати складний, швидкий алгоритм і виявити, що це блискавично але баггі і насправді не сортує дані належним чином.

Нотація Big-O насправді лише щось говорить про поведінку для довільно великих n. Наприклад, означає, що існує константа c> 0 і ціле число n 0 таке, що f ( n ) < c n 2 для кожного n > n 0 .$f (n) = O (n^2)$$n_0$$f (n) < c n^2$$n > n_0$

У багатьох випадках можна знайти константу c і сказати "Для кожного n> 0, f (n) - приблизно ". Яка корисна інформація мати. Але в деяких випадках це неправда. Якщо f (n) = n 2 + 10 18 , то це цілком оману. Так що лише те, що щось є O (n ^ 2), не означає, що ви можете вимкнути мозок і проігнорувати фактичну функцію.$c n^2$$n^2 + 10^{18}$

З іншого боку, якщо ви коли-небудь стикаєтесь зі значеннями n = 1, 2 і 3, то на практиці це не має значення, що f (n) робить для n ≥ 4, тож ви можете також вважати, що f ( n) = O (1), з c = max (f (1), f (2), f (3)). І ось що означає досить малий: Якщо твердження, що f (n) = O (1) не вводить вас в оману, якщо єдині значення f (n), з якими ви стикаєтесь, "достатньо малі".

Якщо він не росте, це O (1)

Заява автора трохи аксіоматична.

Замовлення зростання описують те, що відбувається з кількістю роботи, яку ви повинні виконати, як Nзбільшується. Якщо ви знаєте, що Nце не збільшується, ваша проблема ефективно O(1).

Пам'ятайте, що O(1)це не означає "швидкий". Алгоритм, для виконання якого завжди потрібно 1 трлн кроків, є O(1). Алгоритм, який займає від 1-200 кроків, але ніколи більше, є O(1). [1]

Якщо ваш алгоритм виконує саме такі N ^ 3кроки, і ви знаєте, що Nне може бути більше 5, він ніколи не може зробити більше 125 кроків, тому це ефективно O(1).

Але знову ж таки, O(1)не обов'язково означає «досить швидко». Це окреме питання, яке залежить від вашого контексту. Якщо на те, щоб закінчити щось, потрібен тиждень, вам, мабуть, все одно, якщо це технічно O(1).

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

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

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

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

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

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

(майте на увазі, це все ще невеликий сценарій списку.)

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

Виявляється, цей список був списком клієнтів, а наших клієнтів було лише приблизно 100 клієнтів, тому ніхто не помічав. Операція заповнення списку в основному була операцією O (1), оскільки вона займала менше мілісекунди. Ну, не так вже й багато, коли до нього потрібно додати 10 000 клієнтів.

І через роки після первісного поганого рішення O (1) компанія майже втратила великого клієнта. Все через одну маленьку помилку дизайну / припущення років тому.

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

Якщо у мене є два алгоритми з цими часами:

• журнал (n) +10000
• n + 1

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

Якщо n залишається малим, то кожна проблема - O (1)!

Я спекулюють , що тут це означає, що якщо nобмежена, то кожна проблема є O (1). Наприклад, якщо ми сортуємо цілі числа, ми можемо вирішити використовувати quicksort. O(n*log(n))очевидно. Але якщо ми вирішимо, що ніколи не може бути більше 2^64=1.8446744e+19цілих чисел, знаємо, що n*log(n)<= 1.8446744e+19*log(1.8446744e+19)<= 1.1805916e+21. Тому алгоритм завжди займе менше 1.1805916e+21"одиниць часу". Оскільки це постійний час, ми можемо сказати, що алгоритм завжди можна виконати в той постійний час -> O(1). (Зауважте, що навіть якщо ці одиниці часу є наносекундами, це загальна сума понад 37411 років). Але все ж O(1).

Я підозрюю, що багато з цих відповідей не мають фундаментальної концепції. O (1): O (n) - не те саме, що f (1): f (n), де f - одна і та ж функція, оскільки O не являє собою жодної функції. Навіть хороший графік Шверна недійсний, оскільки він має однакову вісь Y для всіх рядків. Щоб усі користувались однією віссю, лінії повинні бути fn1, fn2 та fn3, де кожен був функцією, продуктивність якої можна було б безпосередньо порівняти з іншими.

Я декілька разів чув, що для досить малих значень n, O (n) можна думати про / обробляти так, ніби це O (1)

Що ж, якщо n = 1 - вони точно однакові? Ні. Функція, що дозволяє змінювати кількість ітерацій, не має нічого спільного з тією, яка не має, позначення big-O не хвилює, і ми також не повинні.

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

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

Ось подібне запитання: Якщо я перебираю рядок символів і знаю, що в цілому мої рядки будуть менше 10 символів, чи можу я сказати, що це еквівалент O (1), але якщо мої рядки були довші, то я скажу, що це був О (п)?

Ні, тому що рядок з 10 символів займає в 10 разів більше, ніж рядок з 1 символом, але в 100 разів менше, ніж рядок з 1000 символів! Це на).

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

$O(1)$$O(1)$

Тепер візьмемо порівняно невеликий набір з 10 елементів і матимемо декілька алгоритмів для їх сортування (лише приклад). Припустимо, що ми зберігаємо елементи в структурі, яка також надає нам алгоритм, здатний сортувати елементи в постійному часі. Скажімо, наші алгоритми сортування можуть мати такі складності (із позначенням big-O):

1. $O(1)$
2. $O(n)$
3. $O(nlog(n))$
4. $O(n^2)$

$O(1)$

Тепер давайте "розкриємо" справжні складності алгоритмів сортування, згаданих вище (де "true" означає не приховувати константу), представлених числом кроків, необхідних для завершення (і припустимо, що всі кроки займають однакову кількість часу):

1. $200$
2. $11n$
3. $4nlog(n)$
4. $1n^2$

Якщо наше введення має розмір 10, то це точна кількість кроків для кожного алгоритму, згаданого вище:

1. $200$
2. $11 \times 10 = 110$
3. $4 \times 10 \times 3.32 \approx 134$
4. $1 \times 100 = 100$

$O(n^2)$$O(1), O(n)$$O(nlog(n))$$O(n^2)$$O(1)$$O(n^2)$$O(1)$ через приховану константу. І якщо константа відносно велика в порівнянні з розміром вводу, це може мати значення більше, ніж асимптотична складність.