Що саме є алгоритмом?

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

Розглянемо факторіальну функцію. Зазвичай ми визначаємо цю функцію як

 int fact(int n) 
 { 
 int r = 1; 
 for(int i=2;i<=n;i++) 
 r = r*i; 
 return r; 
 } 

Я б назвав це алгоритмом і не сумніваюся, що це правильний спосіб зробити це. Тоді я замислився: «чи можу я це робити в постійний час?», Що дозволив зробити таку ідею: що робити, якщо я мав масив цілих чисел, де масив [n] розміщує фактор n? Після заповнення цього масиву я міг просто визначити факт як:

 int fact(int n) 
 { 
 return array[n]; 
 } 

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

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

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

В якості іншого прикладу розглянемо загальне використання масиву: я виділяю масив спочатку розміром N, потім додаю елементи до масиву, зберігаючи значення в індексі n та збільшуючи n на одну одиницю. Тоді, якщо я хочу шукати елемент, я не можу допомогти, але здійснити лінійний пошук по масиву. Якщо замість цього я створив масив розміру, наприклад, Integer.MAXVALUE, для зберігання цілих чисел, ініціалізованих нулями, я міг би зберегти ціле число, розмістивши 1 в його індексі. Тоді я міг би пошукати його існування в масиві в О (1) час. Що робити, якщо я хотів би мати можливість розмістити кілька одиниць однієї кількості? Немає проблеми, я б просто збільшив значення, збережене в цілому індексі.

Сортування було б трохи складніше, але тим не менш пошук і додавання можна було б виконати за O (1) час.

Неофіційне визначення алгоритму в популярному підручнику виглядає приблизно так:

Алгоритм - це (1) чітко визначена обчислювальна процедура (2), яка займає деякий вхід і (3) виробляє деякий вихід (4) для чітко визначеної обчислювальної задачі.

У вашому першому випадку ви зашифрували алгоритм, де: Проблема полягає у пошуку факторіалу (частина 4 визначення), заданому int n як вхідний (частина 2 визначення), код описує обчислення, які слід виконати (частина 1 визначення ), вихід - факторний (частина 3 визначення).

У вашому другому випадку: проблема полягає в пошуку елемента масиву в положенні n (частина 4 визначення), заданому n як вхідному (частина 3 визначення), код описує обчислення, які слід виконати (частина 2 визначення), вихід - елемент у положенні n (частина 1 визначення).

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

І якщо ви скажете, що пошук масиву разом з масивом, що має f (n) в положенні n, є алгоритмом для обчислення f (n), то ви пройшли так глибоко, що нижче немає більше обчислень. Чітко визначена обчислювальна процедура повинна бути кінцевою інформацією. Якщо нескінченний масив факторіалів є частиною обчислювальної процедури, це не дотримується. Тож це не було б алгоритмом для обчислення факторіалів.

Найширше, алгоритм - це ряд кроків для вирішення проблеми .

У CS зазвичай використовуються термін алгоритм:

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

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

Зауважимо, що теза Церкви Тьюрінга говорить про те, що ми вважаємо, що не існує "більш потужної" формалізації алгоритмів, ніж машина Тьюрінга.

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

Тепер ми могли б розглянути обчислення таким чином: Для кожного розміру вводу існує TM (або якийсь інший обчислювальний пристрій), який вирішує проблему. Це зовсім інше питання. Зауважте, що одна TM не може зберігати факториал кожного цілого числа, оскільки TM має обмежений опис. Однак ми можемо зробити TM (або програму на C), яка зберігає фактичні дані всіх чисел нижче 1000. Потім ми можемо зробити програму, яка зберігає фактичні дані всіх чисел від 1000 до 10000. І так далі.

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

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

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

Визначення алгоритму є дуже стійким: в перші дні теорії рекурсії було запропоновано багато визначень, і всі вони показали рівнозначні. Наприклад, замість C можна використовувати машини Тюрінга. Однак ці моделі не обов'язково еквівалентні за ефективністю : проблему можна вирішити набагато ефективніше на З, ніж використання машин Тьюрінга. Зацікавившись ефективністю, ми повинні обмежитися усіма моделями, які «досить близькі» до С щодо часу роботи. Наприклад, якщо нам дозволено використовувати інструкцію, яка обчислюєв одній одиниці часу, то отримана модель все ще визначає той самий набір обчислюваних функцій, але деякі функції (як ) можна обчислити в ній набагато ефективніше, порівняно з C.$n!$$n!$

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

Якщо ми дуже метушливі, нам потрібно зрозуміти різницю між алгоритмами та функціями, обчисленими алгоритмами . Наприклад, факторіальна функція отримує як вхід натуральне число і виводить. Функціональну функцію можна обчислити алгоритмом. Ми говоримо, що функція обчислюється, якщо її можна обчислити за допомогою якогось алгоритму.$n$$n!$

Яке поняття алгоритму ми повинні використовувати? Однією з пропозицій, викладених вище, є використання програм C. Це поняття можна назвати С-обчисленням. Тюрінг-обчислення - це те, що ви отримуєте при використанні машин Тьюрінга. Виявляється, функція є C-обчислювальною і тоді, і лише тоді, коли вона обчислюється Тьюрінгом. Саме в цьому сенсі обидві ці моделі обчислення є рівнозначними. Дійсно, багато інших моделей є рівнозначними, наприклад, всі мови програмування, які є загальними для використання (припускаючи нескінченну пам'ять і необмежену змінні).

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

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

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

Unrelated на ваше запитання, будь реалістичне визначення алгоритму машини матиме пошук пам'яті, по крайней мере для вилучення пам'яті за адресою . Тож алгоритм пошуку буде принаймні мати час для кожного біта виводу, який має біти , Тож загальний час виконання вашого пошуку буде . Але якщо вхід є бітами, то , тож ваш алгоритм пошуку , ніде в бальній частині .$O(\log A)$$A$$O(\log n)$$O(\log n!)$$O(n (\log n)^2)$$s$$n = O(2^s)$$O(2^s~s^2)$$O(1)$

Кілька спостережень, які можуть бути корисними:

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

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

1. Дано , обчислити$n$$n!$
2. Дано таких, що , обчислити.n ! < n $n > 0$$n! <$ INT_MAX$n!$

Деякі тлумачення вашого першого фрагмента коду:

1. Це псевдокод, який нагадує C / C ++, за винятком деталей. intнасправді означає "будь-яке ціле число", наприклад.
2. Це слід трактувати так, ніби це справжня програма C / C ++.

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

Другий фрагмент передбачає, що an arrayбув попередньо обчислений і доступний для функції. Враховуючи це, існують такі завдання array, що цей алгоритм був би правильним під інтерпретацією "інтерпретувати як C / C ++" для даної постановки проблеми: задано таким, що і , обчислити. Зауважимо, що цей алгоритм має невизначену поведінку для і, як такий, було б нереально сподіватися, що алгоритм буде правильним для проблеми, що дозволяє ці значення.n > 0 n ! < n ! n < $n$$n > 0$$n! <$ INT_MAX$n!$$n < 0$

Більш загально - попередньо обчислювальні функції в таблицях є поширеною технікою саме з тієї причини, яку ви помітили: ви можете виконати обчислення один раз, а потім повторно використовувати результати цього обчислення знову і знову. Для багатьох функцій це має багато сенсу. Факторний - чудовий приклад: він так швидко росте, порівняно невеликий масив може зберігати практично всі цілі значення, які вам знадобляться на практиці (вправа: яке найменше ціле число таке, що ? Таке, що ?)n ! ≥ 2 32 п ! ≥ 2 $n$$n! \geq 2^{32}$$n! \geq 2^{64}$

Для аналізу таких алгоритмів можна використовувати те, що називається амортизованим аналізом. Як правило, ви використовуєте це, коли деякі виклики алгоритму можуть зайняти тривалий час, тоді як майже всі (асимптотично кажучи) займають менше часу. У цьому випадку, якщо ви хочете обчислити випадкових факторіалів (з набагато більшим ніж , типове значення, для якого ви обчислюєте факторіал), ви в кінцевому підсумку виконаєте роботу, пропорційну використовуючи перший алгоритм, але більше як використовуючи другий. Отже, ви можете зберегти деякі, попередньо обчисливши тут.k n k n k + $k$$k$$n$$kn$$k+n$

Алгоритм є програма , написана на Тьюрингу мовою , який доказово зупиняється на всіх допустимих вхідних сигналів. Всі стандартні мови програмування є повним Turing. Слово походить від європейського перекладу імені аль-Хварізмі, перського математика, астронома та географа, робота якого будується на роботі індійського математика 7 століття Брахмагупта, який впровадив в західний світ індійську систему числення.

Здається, питання в основному полягає в тому, чи є таблиці пошуку частинами алгоритмів. Абсолютно! У машинах Тьюрінга (ТМ) таблиці можуть бути закодовані в таблиці стану ТМ. TM може ініціалізувати стрічку на основі обмеженого обсягу даних, що зберігаються в таблиці переходу. Однак "алгоритми", які не працюють на нескінченних входах, а лише кінцеві входи, є "тривіально" машинами з кінцевим станом (FSM) .

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

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

Визначення деяких питань

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

$\pi$

$\pi$, можливо, в математичному сенсі майже всіх. Але це вимагало б більшої точності у визначеннях.

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

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

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

Цікаві алгоритми (або програми)

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

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

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

Враховуючи всі параметри задачі (вхідні дані), вона розповідає, як отримати визначений результат поетапно. Типовим прикладом є роздільна здатність рівнянь ( алгоритм імен насправді походить від імені перського математика Мухаммада ібн Муса аль-Хварізмі , який вивчав роздільну здатність деяких рівнянь). Частини доказування використовуються для встановлення того, що деякі значення, обчислені в алгоритмі, мають деякі властивості, але ці частини не потрібно зберігати в самому алгоритмі.

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

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

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

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

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

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

$2^{1000}$

Які програми цікаві

Ця дискусія повинна бути більш правильно пов'язана з результатами, такими як ізоморфізм Крірі-Говарда між програмами та доказом. Якщо будь-яка програма насправді є доказом чогось, будь-яка програма може бути розтлумачена як цікава програма у розумінні вищевказаного визначення.

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

Це, ймовірно, виключає більшість "випадково створених" програм.

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

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

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

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

Не існує хорошого формального визначення поняття "алгоритм" на момент написання. Однак над цим працюють розумні люди.

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

Математична функція - це формальне поняття відображення від входів до виходів. Так, наприклад, "сортування" - це відображення між послідовністю впорядкованих елементів та послідовністю впорядкованих елементів одного типу, яка відображає кожну послідовність у її упорядкованій послідовності. Ця функція може бути реалізована за допомогою різних алгоритмів (наприклад, сортування об'єднань, сортування купи). Кожен алгоритм, у свою чергу, може бути реалізований за допомогою різних програм (навіть з урахуванням тієї ж мови програмування).

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

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

Важкою частиною у всьому цьому є намагання зафіксувати те, що ми маємо на увазі під "по суті одне і те ж".

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

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

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

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