Що ми знаємо про обмежені версії проблеми зупинки

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

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

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

Питання:

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

ОНОВЛЕННЯ

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

Передумови: Припускаючи протиріччя, що існує машина Тьюрінга яка може приймати рішення про вхід M, який є кодуванням для машини Тьюрінга та X , зупиняється чи ні M ( X ) . Тоді розглянемо машину Тюрінга K, яка приймає M і X і використовує Q, щоб вирішити, зупиняється чи ні M ( X ) , а потім робить навпаки, тобто K зупиняється, якщо M ( X ) не зупиняється, і не зупиняється, якщо M ( X $Q$$M$$X$$M(X)$$K$$M$$X$$Q$$M(X)$$K$$M(X)$$M(X)$зупинки. Тоді демонструє протиріччя, так як K повинен зупинятися, якщо він не зупиняється, і не зупиняється, коли він зупиняється.$K(K)$$K$

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

ОНОВЛЕННЯ

На підставі коментарів нижче я уточнюю значення несанкціонованих машин Тьюрінга.

Мета полягає в тому, щоб визначити її як множину, яка не призводить до суперечності, викладеної у доказі (пор. "Передумови" вище). Його можна визначити так:

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

Щоб уточнити, що розуміється під посиланням на S побічно:$Q$$S$

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

ОНОВЛЕННЯ 2

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

ОНОВЛЕННЯ 3

Визначення гомоморфізму машини Тьюрінга:

TM A є гомоморфним TM B, якщо графік переходу A гомоморфний до B, в стандартному розумінні гомоморфізмів графіків з міченими вузлами AND ребрами. Графік переходу (V, E) TM такий, що V = стани, E = перехідні дуги між станами. Кожна дуга позначена символом (S, W, D), S = символ, який зчитується із стрічки, і W = символ, який потрібно записати на неї, і D = напрямок, в якому показують голову.

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

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

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

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

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

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

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

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

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