Чи було б це класифіковано як алгоритм O (1) для "Привіт, світ!" ??

public class Hello1
{
   public static void Main()
   {
      DateTime TwentyYearsLater = new DateTime(2035,01,01);
      while ( DateTime.Now < TwentyYearsLater )
      { 
          System.Console.WriteLine("It's still not time to print the hello ...");
      }
      System.Console.WriteLine("Hello, World!");
   }
}

Я думаю про використання

DateTime TwentyYearsLater = new DateTime(2035,01,01);
while ( DateTime.Now < TwentyYearsLater )
{ 
   // ... 
}

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

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

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

Позначення Big-O означає приблизно "з урахуванням операції над кількістю роботи, N, скільки часу для обчислення, пропорційного N, займає алгоритм?". Наприклад, сортування масиву розміром N може приймати N ^ 2, Nlog (N) тощо.

Тут немає кількості вхідних даних, на які можна діяти. Так це не так O(anything).

Навіть гірше; технічно це не алгоритм. Алгоритм - це метод обчислення значення математичної функції - математичні функції - це відображення від одного входу до виходу. Оскільки це не бере ніяких даних і нічого не повертає, це не є функцією в математичному сенсі. З Вікіпедії:

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

Технічно це система управління. З вікіпедії;

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

Люди, які хочуть отримати більш глибоку відповідь про різницю між математичними функціями та алгоритмами та більш потужними здібностями комп'ютерів робити такі побічні речі, як консольний вихід, показ графіки чи керування роботами, ознайомтеся з цим документом на Сильна гіпотеза Церкви-Тьюрінга

Анотація

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

Прийняттю взаємодії як нової парадигми заважає сильна церковна теза Тюрінга (SCT), поширена думка, що машини Тьюрінга (ТМ) охоплюють усі обчислення, тому моделі обчислень більш виразні, ніж ТМ, неможливі. У цій роботі ми показуємо, що SCT переосмислює оригінальну тезу Церкви-Тьюрінга (CTT) таким чином, який ніколи не передбачав Тьюрінг; її загальноприйнята еквівалентність оригіналу є міфом. Ми визначаємо та аналізуємо історичні причини поширеної віри в SCT. Тільки приймаючи, що це помилково, ми можемо почати сприймати взаємодію як альтернативну парадигму обчислення

Ні, ваш код має складність у часі O(2^|<DeltaTime>|),

Для правильного кодування поточного часу.
Будь ласка, дозвольте мені спочатку вибачитися за свою англійську.

Що таке і як працює Big O в CS

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

У випадку аналізу алгоритму ці дві величини - це не вхід (для якого спочатку потрібно функціонувати "міряти"), а час роботи.
Вони - це довжина кодування екземпляра задачі ¹ та метрика, що цікавить.

Поширені показники є

1. Кількість етапів, необхідних для виконання алгоритму в заданій моделі обчислення.
2. Простір, необхідний, якщо така концепція існує, для моделі обчислення.

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

Чи часто також неявно передбачається, що ми можемо використовувати поліноміально пов'язане кодування замість оригінального, наприклад, функція, яка шукає масив від початку до кінця, має O(n)складність, незважаючи на те, що кодування екземпляра такого масиву повинно мати довжину n*b+(n-1)де b(постійне) число символів кожного елемента. Це тому b, що вважається константою обчислювальної моделі, тому вираз вище і nє асимптотично однаковим.

Це також пояснює, чому такий алгоритм, як пробний відділ, є експоненціальним алгоритмом, незважаючи на те, що він є for(i=2; i<=sqr(N); i++)подібним алгоритмом ³ .

Дивіться це .

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

Тож мова не йде про "вхід" або про те, що "немає вводу".

Вивчіть справу зараз

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

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

Зокрема, це:

<DeltaTime>

Де <>означає будь-яке, непатологічне, кодування вибору.

Дивіться нижче для дуже важливих роз'яснень.

Отже, ваш великий час складності O справедливий O(2^|<DeltaTime>|), тому що ви робите ряд ітерацій, які залежать від значення поточного часу. Немає сенсу ставити інші числові константи, оскільки асимптотичні позначення корисні, оскільки вони виключають константи (так, наприклад, використання O(10^|<DeltaTime>|*any_time_unit)безглуздо).

Де хитра частина

Вище ми зробили одне важливе припущення: що модель обчислення повторно підтверджує ⁵ разів, а часом я маю на увазі (реальний?) Фізичний час. У стандартній обчислювальній моделі такої концепції немає, ТМ не знає часу, ми пов'язуємо час з кількістю кроків, тому що так працює наша реальність ⁴ .

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

Щоб зрозуміти це, слід зазначити, що ніщо не заважає Рамкові використовувати підроблений час, який працює вдвічі, п’ять, десять разів швидше, ніж фізичний час. Таким чином ваш код буде працювати в "половині", "п'ятій п'ятірці", "одній десятій частині" часу ".

Це відображення важливе для вибору кодування <DeltaTime>, це, по суті, стислий спосіб написання <(CurrentTime, TimeInFuture)>. Оскільки часу не існує пріорі, кодування CurrentTime цілком може бути словом Now (або будь-яким іншим вибором) напередодні можна було кодувати як Вчора , там, порушивши припущення, що тривалість кодування збільшується як фізичний час йде вперед (а цей у DeltaTime зменшується)

Ми повинні правильно моделювати час у нашій обчислювальній моделі, щоб зробити щось корисне.

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

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

На жаль, термінологія використовує одні і ті ж слова, але ви можете спробувати використати "складність кроків" в голові і перепросити собі своє питання, сподіваюся, що допоможе зрозуміти відповідь насправді ^ _ ^

¹ Це також пояснює необхідність асимптотичного підходу, оскільки кожен екземпляр має різну, але не довільну довжину.
² Я сподіваюся, що тут я вживаю правильний англійський термін.
^{3 І} саме тому ми часто знаходимо log(log(n))в математиці терміни.
⁴ Точно крок повинен займати деякий кінцевий, але не нульовий і не пов'язаний інтервал часу.
⁵ Це означає, що обчислювальний режим як знання фізичного часу в ньому, тобто може виражати його своїми умовами. Аналогія - як дженерики працюють у рамках .NET.

Хоча тут є маса чудових відповідей, дозвольте трохи перефразувати їх.

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

• Ми можемо розглядати ваш алгоритм як постійну функцію, яка приймає будь-який ввід будь-якого розміру, ігнорує його, чекає фіксованого часу та закінчує. У цьому випадку час його виконання є f (n) = const , і це алгоритм O (1) -time. Це те, що ви очікували почути, правда? Так, це технічно є алгоритмом O (1) .
• Ми можемо розцінювати TwentyYearsLaterяк цікавий параметр "вхідного розміру". У цьому випадку час виконання - f (n) = (nx), де x - "час тепер" у момент виклику. Якщо це бачити таким чином, це алгоритм O (n) -time. Очікуйте цього контр-аргументу щоразу, коли ви переходите демонструвати свій технічний O (1) -алгоритм іншим людям.
• О, але зачекайте, якщо k =TwentyYearsLater вхід, то його розмір n - це фактично кількість бітів, необхідних для його представлення, тобто n = log (k) . Отже, залежність між величиною вхідного n та тривалістю виконання є f (n) = 2 ^ n - x . Схоже, ваш алгоритм просто став експоненціально повільним! Тьфу.
• Іншим входом до програми є насправді потік відповідей, що даються ОС на послідовність DateTime.Nowвикликів у циклі. Ми можемо реально уявити, що вся ця послідовність надається як вхідний момент у момент запуску програми. Потім можна вважати, що час виконання залежить від властивості цієї послідовності, а саме від її довжини до першого TwentyYearsLaterелемента. У цьому випадку час виконання знову f (n) = n, а алгоритм - O (n) .

Але знову ж таки, у своєму запитанні ви навіть не сказали, що вас цікавить час виконання. Що робити, якщо ви мали на увазі використання пам'яті? Залежно від того, як ви моделюєте ситуацію, ви можете сказати, що алгоритмом є O (1) -пам'ять або, можливо, O (n) -пам'ять (якщо реалізація DateTime.Nowвимагає відстежувати всю послідовність викликів, чомусь).

І якщо ваша мета полягала в тому, щоб придумати щось абсурдне, чому б вам не зайти все і сказати, що вас цікавить, як розмір коду алгоритму в пікселях на екрані залежить від обраного масштабу. Це може бути щось на зразок f (zoom) = 1 / zoom, і ви можете з гордістю оголосити свій алгоритм розміром O (1 / n) -пікселя!

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

Отже, якщо ви берете цей код і виконайте його на машині, яка має системний час 1 січня 1970 року, на завершення знадобиться 65 років, незалежно від того, наскільки швидко працює комп'ютер (може бути певна різниця, якщо його годинник несправний ). Якщо взяти цей код і виконати його на машині, що має системний час 2 січня 2035 року, він завершиться майже миттєво.

Я б сказав ваш внесок, n є January 1st, 2035 - DateTime.Now, є , і це O (n).

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

Щодо цього:

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

Ні, не дуже. Інші відповіді висвітлювали це, тому я просто хотів це згадати. Зазвичай ви не можете співвідносити роки виконання з будь-якою великою нотацією O. Напр. З цього приводу не можна сказати 20 років страти = O (n ^ 87) чи що-небудь інше. Навіть в алгоритмі, який ви подали, я міг змінити TwentyYearsFromNowрік на 20110, 75699436 або 123456789, і велике-O все одно O (n).

Аналіз Big-O стосується обсягу обробки, що займається, оскільки кількість оброблюваних даних без обмежень збільшується.

Тут ви справді маєте справу лише з одним об'єктом фіксованого розміру. Застосування аналізу big-O значною мірою залежить (перш за все?) Від того, як ви визначаєте свої умови.

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

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

big-O щодо чого?

Ви, здається, інтуїтивно зрозуміли, що twentyYearsLaterце "вхід". Якщо ви справді ви написали свою функцію як

void helloWorld(int years) {
   // ...
}

Це було б O (N), де N = роки (або просто сказати O(years)).

Я б сказав, що ваш алгоритм є O (N) щодо того, яке число ви запишете в рядку коду, починаючи з twentyYearsLater =. Але люди зазвичай не вважають числа в фактичному вихідному коді вхідним. Вони можуть розглядати вхід командного рядка як вхід, або вхід підпису функції як вхід, але, швидше за все, не сам вихідний код. Це те, що ви спірите зі своїм другом - це «вхід»? Ви встановлюєте свій код таким чином, щоб він інтуїтивно здавався вхідним, і ви, безумовно, можете запитати його великий час роботи O щодо числа N у рядку 6 вашої програми, але якщо ви використовуєте такий вибір, який не використовується за замовчуванням як вхідні дані вам дійсно повинні бути чіткими.

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

Подібне запитання - який час виконання:

void sortArrayOfSizeTenMillion(int[] array)

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

Цей "алгоритм" правильно описано як O (1) або постійний час. Стверджувалося, що в цю програму немає ніякого вкладу, отже, немає Н для аналізу в термінах Big Oh. Я не погоджуюся з тим, що введення немає. Коли це компілюється у виконуваний файл і викликається, користувач може вказати будь-який вхід довільної довжини. Ця вхідна довжина - N.

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

Я здивований, ще не було згадано: позначення big-O - це верхня межа!

Усі, хто помітив, полягають у тому, що немає N, що описує входи в алгоритм, тому немає з чим робити великий аналіз O. Однак це легко пом'якшити за допомогою деяких основних хитрощів, таких як прийняття int nта друк "Hello World" nчасів. Це дозволить обійти цю скаргу і повернутися до реального питання про те, як DateTimeпрацює ця чудовисько.

Немає фактичної гарантії того, що цикл while будь-коли припиниться. Нам подобається думати, що це має бути на певний час, але вважаємо, що це DateTime.nowповертає дату та час системи . Фактично немає гарантії, що це монотонно зростає. Цілком можливо, що є якась патологічно навчена мавпа, яка постійно змінює дату та час роботи системи до 21 жовтня 2015 р. 12:00:00 UTC, поки хтось не подарує мавпі якесь взуття для автоматичного розміщення та ховерборд. Цей цикл насправді може працювати протягом нескінченної кількості часу!

Коли ви фактично заглиблюєтесь у математичне визначення нотацій з великим O, вони є верхніми межами. Вони демонструють найгірший випадок, яким би малоймовірно. Найгірший сценарій * тут - нескінченна тривалість виконання, тому ми змушені заявити, що немає великої нотації O, яка б описувала складність виконання цього алгоритму. Він не існує, так само як 1/0 не існує.

* Редагувати: з мого обговорення з KT не завжди справедливо припускати сценарій, який ми моделюємо з позначенням big-O - це найгірший випадок. У більшості випадків, якщо особа не вказує, який випадок ми використовуємо, він мав намір вивчити найгірший випадок. Однак ви можете зробити великий складний аналіз складності в кращому випадку виконання.

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

Такі проблеми, як сито Ератостена, є O (n ^ exp) і тому вирішуються для малих значень n. Вони піддаються обчислюванню, тільки не в поліноміальний час (NP), і тому, коли їх запитують, чи задане число є простим чи ні, відповідь залежить від величини такої кількості. Більше того, складність не залежить від апаратного забезпечення, тому наявність швидших комп'ютерів нічого не змінює ...

Hello World - це не алгоритм, і тому безглуздо намагатися визначити його складність - що таке ніхто. Простий алгоритм може бути чимось на зразок: задавши випадкове число, визначте, парне чи непарне. Тепер, чи має значення те, що вказане число має 500 цифр? Ні, тому що ви просто повинні перевірити, чи остання цифра є парною чи непарною. Більш складним алгоритмом було б визначити, чи дане число ділиться рівномірно на 3. Хоча деякі числа «легко» обчислити, інші - «важко», і це пов’язано з його величиною: порівняйте час, необхідний для визначення реманера між число з однією цифрою, а інше - з 500 цифр.

Складнішим випадком буде розшифровка тексту. У вас є очевидний випадковий масив символів, який ви також знаєте, що передають повідомлення для тих, хто має ключ розшифровки. Скажімо, відправник використав ключ зліва і ваш Hello World прочитав би: Gwkki Qieks. Рішення "з великим ударом, без мозку" створило б усі комбінації для цих букв: від Аааа до Zzzz, а потім здійснити пошук у словнику слів, щоб визначити, які слова є дійсними, і поділити дві загальні літери в цифрі (i, k) у та ж позиція. Ця функція перетворення - це те, що вимірює Big O!

У більшості людей, здається, не вистачає двох дуже важливих речей.

1. Програма робить біля входу. Це жорстко кодована дата / час, з якою порівнюється системний час. Входи знаходяться під контролем людини, що працює за алгоритмом, а системний час - ні. Єдине, що людина, яка запускає цю програму, може контролювати - це дата / час, коли вони важко закодовані для порівняння.

2. Програма змінюється залежно від вхідного значення , але не розміру вхідного набору , що стосується нотації big-O.

Отже, вона невизначена, і найкращою позначкою 'big-O' для цієї програми, ймовірно, буде O (null) або, можливо, O (NaN).

Всі правильно вказали, що ви не визначаєте N , але відповідь "не" під найдоцільнішою інтерпретацією. Якщо N - довжина струни, яку ми друкуємо, і "привіт, світ!" це лише приклад, як ми можемо зробити висновок з опису цього як алгоритму "для hello, world!", тоді алгоритм є O ( N ), тому що у вас може бути вихідний рядок, який потребує друку тридцяти, сорока або п'ятдесяти років, і ви додаємо до цього лише постійний час. O ( kN + c ) ∈ O ( N ).

Додаток:

На мій подив, хтось заперечує це. Пригадайте визначення великого O та великого Θ. Припустимо, у нас є алгоритм, який чекає постійну кількість часу dN + c років. Всякий раз, коли N > k , dN = c / k N > c . Тому dN < dN + c = f ( N ) <2 dN для всіх N c, а потім виводить повідомлення довжиною N у лінійному часі. (Це узагальнення оригінального зразка коду.) Скажімо довільно, що ми чекаємо двадцяти років, щоб почати друкувати, а на друк трильйона символів потрібно ще двадцять років. Нехай, наприклад, c = 20 і k = 10¹², але будь-які додатні дійсні числа будуть робити. Це швидкість d = c / k (в даному випадку 2 × 10⁻¹¹) років на персонаж, тому наш час виконання f ( N ) асимптотично > k , а f ( N ) ∈ Θ ( N ). QED

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

void TrolloWorld(long currentUnixTime, long loopsPerMs){
    long laterUnixTime = 2051222400000;  //unix time of 01/01/2035, 00:00:00
    long numLoops = (laterUnixTime-currentUnixTime)*loopsPerMs;

    for (long i=0; i<numLoops; i++){
        print ("It's still not time to print the hello …");
    }
    print("Hello, World!");
}

Вхідні дані явні, тоді як раніше вони неявно задавалися часом запуску коду та швидкістю апаратного забезпечення коду. Код детермінований і має чітко визначений вихід для заданих входів.

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

На даний момент часу, так

Цей алгоритм має неявний вхід, а саме час запуску програми. Час виконання буде змінюватися лінійно ¹ залежно від того, коли воно розпочато. Протягом 2035 року і після цього цикл негайно вимикається, і програма припиняється після постійних операцій ² . Тож можна сказати, що тривалість виконання - O(max(2035 - start year, 1))³ . Але оскільки наш стартовий рік має мінімальне значення, алгоритм ніколи не займе більше 20 років для виконання (тобто постійне значення).

Ви можете зробити свій алгоритм більш відповідним вашим намірам, визначивши DateTime TwentyYearsLater = DateTime.Now + new TimeSpan(365*20,0,0,0);⁴

¹ Це стосується більш технічного сенсу часу виконання, виміряного як кількість операцій, оскільки існує максимальна кількість операцій за одиницю часу.
² Припускаючи отримання DateTime.Now- це постійна операція, що є розумним.
³ Я дещо зловживаю великими позначеннями O, оскільки це погіршує функцію щодо start year, але ми могли б легко виправити це, висловивши це в термінах years prior to 2035.
⁴ Тоді алгоритм більше не залежить від неявного введення часу початку, але це не має жодного наслідку.

Я б стверджував, що це O (n). використовуючи http://www.cforcoding.com/2009/07/plain-english-explanation-of-big-o.html в якості посилання.

Що таке Big O?

Позначення Big O прагне описати відносну складність алгоритму шляхом зменшення швидкості росту до ключових факторів, коли ключовий фактор має тенденцію до нескінченності.

і

Найкращий приклад Big-O, який я можу придумати, - це робити арифметику. Основними арифметичними операціями, які ми вивчили в школі, були:

додавання; віднімання; множення; і поділ. Кожне з них - це операція чи проблема. Метод їх вирішення називається алгоритмом.

Для вашого прикладу,

заданий вхід n = 20 (з одиницями років).

алгоритм - математична функція f (). де f () трапляється чекати протягом n років, з рядками 'debug' між ними. Коефіцієнт масштабу - 1. f () можна зменшити / або збільшити, змінивши цей коефіцієнт масштабу.

для цього випадку вихід також дорівнює 20 (зміна входу змінює вихідний лінійно).

по суті функція є

f(n) = n*1 = n
    if  n = 20, then 
f(20) = 20