Мови програмування для ефективного обчислення

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

Наприклад, для чогось типу : візьміть улюблену мову програмування, і після того, як ви напишете свою програму (відповідну машині Turing Machine M ' ), додайте до заголовка три значення: ціле число c , ціле число k та вихід d за замовчуванням . Коли програма складається, виведіть машину Тюрінга M, яка задана введенням x розміру n працює M ' на x для c n k кроків. Якщо M ′ не зупиняється перед c n $P$$M'$$c$$k$$d$$M$$x$$n$$M'$$x$$c n^k$$M'$$c n^k$кроки вгору, виведіть вихідний за замовчуванням . Якщо я не помиляюся, ці мови програмування дозволять нам виразити всі обчислення в P і нічого більше. Однак ця запропонована мова за своєю суттю нецікава.$d$$P$

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

Однією мовою, яка намагається виразити лише поліномічні обчислення часу, є м'яке обчислення лямбда . Система типу типу вкорінена в лінійній логіці. Недавня дисертація стосується обчислень поліноміального часу та дає хороший підсумок останніх подій, заснованих на такому підході. Мартін Хофманн над цією темою працює вже досить давно. Старіший список відповідних робіт можна знайти тут ; Багато його робіт продовжуються в цьому напрямку.

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

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

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

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

Мова програмування Charity - це досить виразна функціональна мова, яка зупиняється на всіх входах. Я не знаю, який клас складності він може виражати, але функцію Ackermann можна записати в Charity.

Погляньте на документ Гійом Бонфанте, який запропонував дві характеристики для простору журналів та часу полінома з використанням мов програмування.

Гійом Бонфанте, Деякі мови програмування для журналів простору та Ptime, AMAST 2006, LNCS 4019, стор. 66-80, 2006

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

Основна методика полягає у співвіднесенні класів складності з підсистемами лінійної логіки (так звана "легка лінійна логіка"), з ідеєю, що усунення для логічної системи має бути повним для даного класу складності (наприклад, LOGSPACE, PTIME тощо). Потім за допомогою Curry-Howard ви вийдете мову програмування, в якій точно виражаються програми даного класу.

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

Дивіться також мову Pola мовою для програмування PTIME та робіт Japaridze з арифметики PTIME, наприклад http://arxiv.org/abs/0902.2969