Чи є підмножина програм, які уникають проблеми зупинки

Я просто читав чергове пояснення проблеми зупинки, і це змусило мене думати, що всі проблеми, які я бачив, наведені як приклади, включають нескінченні послідовності. Але я ніколи не використовую нескінченні послідовності у своїх програмах - вони займають занадто багато часу. Усі додатки в реальному світі мають нижню та верхню межі. Навіть реальні фактично не справжні - вони є наближеннями, які зберігаються як 32/64 біт тощо.

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

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

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

тіа

[Оновлення]

Прочитавши коментарі та відповіді, можливо, я повинен переробити своє запитання.

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

[Оновлення 2]

ось відповідь, так, ще в 1967 році з http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

Про те, що проблема зупинки може бути принаймні теоретично вирішена для кінцево-державних систем, Мінський вже стверджував у 1967 р. [4]: ​​«... будь-яка кінцева машина держави, якщо її повністю залишити для себе, з часом потрапить у ідеально періодичний повторюваний візерунок. Тривалість цієї повторюваної картини не може перевищувати кількість внутрішніх станів машини ... "

(і так, якщо ви будете дотримуватися машин з обмеженими термінами, тоді ви можете побудувати оракул)

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

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

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

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

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

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

Рекомендую прочитати Геделя, Ешера, Баха . Це дуже весела і освітлююча книга, яка, серед іншого, торкається теореми про незавершеність Геделя та проблеми зупинки.

Відповідь на ваше запитання у двох словах: проблема зупинки вирішується до тих пір, поки ваша програма не містить whileциклу (або будь-якого з багатьох можливих його проявів).

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

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

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

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

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

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

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

Які програми можна перевірити підходом, описаним у статті? По суті, всі програми, які зупиняються перед повторенням стану (де 'state' приблизно відповідає рядку коду в програмі).

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

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

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

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

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

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

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

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

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

ось відповідь, так, ще в 1967 році з http://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdf

Про те, що проблема зупинки може бути принаймні теоретично вирішена для кінцево-державних систем, Мінський вже стверджував у 1967 р. [4]: ​​«... будь-яка кінцева машина держави, якщо її повністю залишити для себе, з часом потрапить у ідеально періодичний повторюваний візерунок. Тривалість цієї повторюваної картини не може перевищувати кількість внутрішніх станів машини ... "

(і так, якщо ви будете дотримуватися машин з обмеженими термінами, тоді ви можете побудувати оракул)

Звичайно, скільки часу це займе - інше питання

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

Так.

Це досить добре для більшості програм?

Визначте "найбільше".

Чи можу я побудувати набір мовних конструкцій, за допомогою яких я можу визначити "придатність" програми?

Так.

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

Визначте "майже".

Багато людей пишуть Python, не використовуючи whileтвердження чи рекурсії.

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

Уникнути whileта рекурсії досить легко .

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

Ні.

Якщо так, то які обмеження мови і які межі набору вводу.

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

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

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

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

Так. Це називається "Теорія групи". Набір значень, закритих під набором операцій. Досить добре зрозумілі речі.