¿Qué sabemos sobre las versiones restringidas del problema de detención?

( ACTUALIZACIÓN : aquí se plantea una pregunta mejor formada ya que los comentarios para la respuesta aceptada a continuación muestran que esta pregunta no está bien definida)

La prueba clásica de la imposibilidad del problema de detención depende de demostrar una contradicción al intentar aplicar el algoritmo de detección de detención a sí mismo como entrada. Consulte los antecedentes a continuación para obtener más información.

La contradicción demostrada se aplica debido a una paradoja autorreferencial (como la oración "Esta oración no es verdadera"). Pero si prohibimos estrictamente tales auto-referencias (es decir, aceptamos el hecho de que tales auto-referencias no pueden detenerse), ¿qué resultado nos queda? ¿Se puede detener o no el problema de detención para el conjunto restante de máquinas sin autorreferencia?

La pregunta es:

Si consideramos un subconjunto de todas las máquinas de Turing posibles, que no son autorreferenciadas (es decir, no se toman como entrada), ¿qué sabemos sobre el problema de detención de este subconjunto?

ACTUALIZAR

Quizás una mejor reformulación de lo que busco es una mejor comprensión de lo que define un conjunto decidible. Estaba tratando de aislar la prueba clásica de indecidibilidad porque no agrega ninguna información sobre la indecidibilidad, excepto en los casos en que ejecuta HALT en sí mismo.

Antecedentes: Suponiendo que existe una contradicción de que hay una máquina Turing $Q$ que puede decidir sobre la entrada $M$ que es una codificación para una máquina Turing y $X$ , independientemente de si $M(X)$ detiene o no . Luego considere una máquina de Turing $K$ que toma $M$ y $X$ y usa $Q$ para decidir si $M(X)$ detiene o no, y luego hace lo contrario, es decir, $K$ detiene si $M(X)$ no se detiene, y no se detiene si $M(X)$se detiene Entonces $K(K)$ demuestra una contradicción, ya que $K$ debería detenerse si no se detiene, y no se detiene cuando se detiene.

Motivación: un colega está trabajando en la verificación formal de los sistemas de software (especialmente cuando el sistema ya está probado a nivel de código fuente y queremos reprobarlo para su versión compilada, para neutralizar los problemas del compilador), y en su caso se preocupa por un conjunto especial de programas de control integrados para el que sabemos con certeza que no se autoreferenciarán. Un aspecto de la verificación que desea llevar a cabo es si se garantiza que el programa compilado se detendrá si se demuestra que el código fuente de entrada termina.

ACTUALIZAR

En base a los comentarios a continuación, aclaro el significado de las máquinas de Turing sin autorreferencia.

El objetivo es definirlo como el conjunto que no conduce a la contradicción planteada en la prueba (cf. "Antecedentes" arriba). Se podría definir de la siguiente manera:

Suponiendo que hay una máquina Turing que decide el problema de detención para un conjunto de máquinas S de Turing , entonces S no hace referencia a sí mismo con respecto a Q si excluye todas las máquinas que invocan Q en S (directa o indirectamente). (Claramente, eso significa que Q no puede ser miembro de S ).$Q$$S$$S$$Q$$Q$$S$$Q$$S$

Para aclarar qué se entiende al invocar sobre S indirectamente:$Q$$S$

La invocación de en S se denota mediante una máquina Q de Turing con un conjunto de estados y ciertas posibles entradas iniciales en la cinta (correspondientes a cualquier miembro de S ), con el cabezal inicialmente al comienzo de esa entrada. Una máquina W invoca Q en S "indirectamente" si hay una secuencia (finita) de pasos que W tomaría para hacer su configuración "homomórfica" a la configuración inicial de Q ( S ) .$Q$$S$$Q$$S$$W$$Q$$S$$W$$Q(S)$

ACTUALIZACIÓN 2

De una respuesta a continuación que argumenta que hay infinitas máquinas de Turing que realizan la misma tarea, y por lo tanto no es único, cambiamos la definición anterior al decir que Q no es una sola máquina de Turing, sino el conjunto (infinito) de todas las máquinas que computan la misma función (HALT), donde HALT es la función que decide si una máquina de Turing se detiene en una entrada en particular.$Q$$Q$

ACTUALIZACIÓN 3

La definición del homomorfismo de la máquina de Turing:

A TM A es homomórfico a TM B si el gráfico de transición de A es homomórfico al de B, en el sentido estándar de homomorfismos de gráficos con nodos etiquetados Y bordes. Un gráfico de transición (V, E) de una TM es tal que V = estados, E = arcos de transición entre estados. Cada arco está etiquetado con el (S, W, D), S = símbolo leído de la cinta y W = el símbolo que se va a escribir en él, y D = la dirección a la que se mueve el espectáculo.

Creo que tomará un poco más de trabajo llegar a una pregunta "bien definida". En particular, esto es problemático:

La invocación de Q en S se denota mediante una máquina Q de Turing con un conjunto de estados y ciertas posibles entradas iniciales en la cinta (correspondientes a cualquier miembro de S), con el cabezal inicialmente al comienzo de esa entrada. Una máquina W invoca Q en S "indirectamente" si hay una secuencia (finita) de pasos que W tomaría para hacer su configuración "homomórfica" a la configuración inicial de Q (S).

Un problema es que hay infinitas máquinas de Turing que calculan la misma función. En el argumento de diagonalización estándar, puedo reemplazar la subrutina Q con otro decisor para HALT, ya que hay infinitos de ellos. O una función que es computablemente equivalente a HALT. Por lo tanto, no está del todo claro para mí cómo definir su noción de "invocación indirecta".

Una pregunta diferente podría ser: ¿para qué conjuntos de máquinas de Turing es decidible el problema de detención? Aquí hay una gran cantidad de respuestas: TM restringidas de recursos (por ejemplo, use solo espacio f (n), donde f es alguna función computable específica), TM que están operacionalmente restringidas de alguna manera en particular (por ejemplo, el cabezal de lectura solo se mueve en una dirección), etc. Pero, otra pregunta interesante es si la membresía en ese conjunto restringido es decidible, o si tiene que restringirse a "problemas de promesa", donde solo garantiza una respuesta correcta en algún subconjunto de entradas "prometidas", pero no verifica afiliación.

Si entiendo su motivación correctamente, parece que este es un problema de "corrección del compilador" más que un problema de "problema de detención restringida". Tiene una propiedad (terminación) que ha probado para algún programa Prog de nivel de origen que desea extender al código compilado para obtener la misma propiedad de compilado (Prog) . Pero el compilador puede (en general) hacer cosas arbitrariamente tontas como implementar un tiempo de ejecución completo (por ejemplo, JVM), compilar su programa de terminación en un código de bytes JVM y luego descargar un ejecutable que inicie el JVM y lo alimente con su código de bytes compilado.

En la práctica , es probable que sea posible utilizar el conocimiento implícito que tiene sobre cómo funciona su compilador para implementar algún procedimiento de verificación que demuestre que los programas compilados son correctos dados los programas fuente correctos (de hecho, muchas herramientas de verificación automática para programas están utilizando conocimiento implícito del "compilador" de algoritmo a código en los cerebros de los programadores). Sin embargo, en general probablemente estés viendo un problema de corrección del compilador. Según tengo entendido, hay dos formas clásicas de hacerlo.

Una opción es tener un compilador que tome como entrada el programa Prog y la prueba termina (Prog) y las salidas compiladas (Prog) y termina (compiladas (Prog)) ; esta última es una prueba que luego se puede verificar dos veces independientemente de El compilador. El artículo clásico sobre esto es Necula y Lee. El diseño y la implementación de un compilador certificador , creo.

Alternativamente, puede probar un hecho sobre la función compiles () , que cada vez que compiles () está dando una entrada de terminación produce una salida de terminación. Una introducción accesible a esta forma de pensar sobre la corrección del compilador es el artículo CACM de Xavier Leroy, Verificación formal de un compilador realista .

(PD: Espero que esta respuesta sea útil; reconozco que es un poco divergente de la pregunta que hizo, así que avíseme si estoy fuera de lugar y / o repito algo que ya sabe).