Problema de detención sin autorreferencia: ¿por qué este argumento no es suficiente (o sí)?


8

Estoy tratando de encontrar una manera de explicar la idea de la prueba del problema de detención de la manera más accesible posible (para estudiantes universitarios de CS). El argumento más simple que he encontrado es este ; este es precisamente el estilo de tratamiento que busco. Sin embargo, la autorreferencia (en particular, verificar si un programa se detiene) no es la más didáctica.

Lo que me pregunto, como un bosquejo de prueba, es por qué no podríamos simplificar aún más y decir: si asumimos un programa H(P,I)para el Problema de detención que se detiene con verdadero si se P(I)detiene y se detiene con falso de lo contrario, entonces podríamos crear un programa de la forma:

def Q(J):
  if H(Q,J) then loop forever
  else halt

... que es un programa válido si y solo si el Problema de detención es un programa válido. Entonces podemos preguntar: ¿para qué debería H(Q,J)devolver cualquier valor arbitrario J? Vemos una contradicción en ambas posibilidades, y concluimos que, dado que la existencia de Hnos permite construir el programa contradictorio Q, Hno puede existir un programa de la forma .

Todavía hay alguna referencia propia aquí en que el programa Qverifica si se detiene o no en la entrada actual (y hace lo contrario), pero para mí, esto parece mucho más intuitivo que configurar una situación en la que necesitamos una llamada del forma P(P)o H(P,P), etc. Sin embargo, no he visto este argumento más simple utilizado, y creo que habría sido si fuera válido. Por eso mis preguntas son:

  • ¿Es suficiente el argumento anterior como prueba (bosquejo) del problema de detención?
    • Si es así, ¿por qué tantos argumentos van con un paso confuso de la forma P(P)o H(P,P)? (¿Es solo para eliminar la "entrada" sin importancia de la ecuación?)
    • Si no, ¿qué falta?

Hay una variedad de preguntas relacionadas con este tema, como:

También encontré mención de la prueba basada en la paradoja de Berry, que es bastante atractiva. Aún así, todavía no he logrado convencerme de si el argumento específico anterior funciona o no (aunque sea solo por mi propia comprensión; siento que tal vez me estoy perdiendo algo estúpido y me gustaría saber de qué se trata).


2
¿Conoces este video ? Es la explicación más intuitiva del problema de detención que he visto.
Polygnome

¡Gracias por la anotación! Sí, @DW lo vincula en su respuesta.
badroit

Respuestas:


20

No creo que esta sea una buena manera de presentar el problema de detención, porque barre un tema crítico bajo las sábanas de una manera furtiva. Sugiero seguir con una presentación más estándar, como la que vinculó. Si desea encontrar una manera de explicarlo de una manera que minimice el contenido técnico, la presentación en este video es sorprendentemente accesible y se mantiene fiel a la lógica de la prueba estándar.

A las dificultades con su propuesta. En su propuesta, no es trivial escribir el código para tal Q. Piensa en lo que significa tener la línea

  if H(Q,J) then loop forever 

Recuerde que el primer argumento Hes una cadena de bits que contiene el código / algoritmo / máquina de Turing: no es un puntero a la función, sino una cadena. Ingenuamente, esto parece significar que incluimos una cadena codificada que contiene el código fuente para Q, dentro del código de Q. Pero eso no es posible. Supongamos que el código para Qtoma 100 caracteres. Luego, necesitamos codificar una constante de cadena de 100 caracteres dentro de la definición de Q, además de que necesitamos más caracteres para el resto de la lógica, y eso suma más de 100 caracteres. Si lo piensas, es obvio que no podemos tener una cadena constante dentro del código de Qese es el código de Q, porque sería demasiado largo.

Tal vez estás pensando que eso no es lo que tenías en mente. Tal vez estaba pensando que el lenguaje de programación tendrá una API incorporada para obtener el código de la función actual, por lo que en realidad el código en el que estaba pensando es algo así como:

def Q(J):
  if H(get_source_code_of_current_function(),J) then loop forever
  else halt

Está bien. Esto demuestra que el problema de detención no se puede resolver para el código escrito en ningún lenguaje de programación que tenga una get_source_code_of_current_function()API. Sin embargo, mi lenguaje de programación favorito no tiene esa API. Entonces, esta prueba no prueba nada acerca de mi lenguaje de programación favorito; quizás el problema de detención sea solucionable para mi lenguaje, ¿quién sabe? Del mismo modo, las máquinas de Turing no tienen una API de este tipo, por lo que esto no prueba que el problema de detención para las máquinas de Turing sea indecidible.

Y esa es una falla importante en su prueba. Y es un defecto sutil y nada evidente. No creo que sea pedagógicamente una buena idea presentar una prueba que "parezca válida" en la superficie, pero en realidad, una vez que profundizas en ella, es más defectuosa.

Ahora, es posible rescatar su prueba propuesta. En realidad, es posible construir una función Qque funcione de la manera que usted dijo; básicamente necesitas que sea una quine . Supongo que, en principio, podría explicar la idea de quines, luego presentar su prueba y explicar cómo implementar una función Q utilizando esas ideas. Pero eso me parece una mala idea, desde una perspectiva pedagógica. Las quines son alucinantes, misteriosas y terriblemente difíciles de entender. Un estudiante que no entiende quines no entenderá su prueba. Y hace que la prueba de indecidibilidad para el problema de detención parezca mucho más misteriosa de lo que debe ser. Así que esto no me parece una forma más accesible de entender el problema de detención.


Excelente respuesta, muchas gracias! Creo que quizás ir con una presentación más estándar es el camino a seguir (en lugar de introducir quines, por ejemplo).
badroit

"básicamente necesita que sea una quine", o defina Q como una constante en un programa más grande y luego evalúelo utilizando una máquina universal de turing o equivalente. Siempre y cuando acepte que la máquina universal de turing se comporta de la misma manera que la máquina en la que se está ejecutando en todas las circunstancias, ¿ese debería ser un enfoque más fácil de entender?
Julio

@Jules, lo siento, no entiendo tu prueba propuesta, así que no puedo comentar sobre ella.
DW

¿Le importaría explicar por qué considera que las quines son difíciles de entender? En mi experiencia, las líneas de la forma "escriba esto y luego la misma cita" son bastante sencillas de construir.
Dmitri Urbanowicz

@DmitriUrbanowicz, tal vez solo soy yo y estoy atascado en eso. Encuentro las quines mágicas y difíciles de entender. Tal vez solo soy yo; o tal vez aún no he visto la explicación correcta; o tal vez no lo he intentado lo suficiente. ¡Quizás otros tendrían una experiencia diferente!
DW

1

No veo cómo la autorreferencia es pedagógicamente difícil. La paradoja de Barber es bastante fácil de entender. Y su argumento tiene una autorreferencia implícita, y creo que es más difícil de entender que la simple autorreferencia. Además de eso, es incoherente. Para definir H (Q, J), primero necesita saber qué es Q, y para definir Q, primero necesita saber qué es H (Q, J). Eso no funciona En el mejor de los casos, puede afirmar que Q es un punto fijo de esta definición autorreferencial, pero si intenta derivar algo de la naturaleza contradictoria de Q, simplemente está mostrando que H no existe O que no existe tal punto fijo ; ahora tiene que demostrar que si H existiera, el punto fijo tendría que existir.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.