Autor Tema: *Lab*: El Halting Problem con un enfoque experimental

0 Usuarios y 1 Visitante están viendo este tema.

12 Enero, 2012, 03:44 pm
Leído 22783 veces

Elius

  • $$\Large \color{#5e8d56}\pi\,\pi\,\pi$$
  • Mensajes: 399
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino


Se podría enviar a los departamentos de Labs de Google, Microsoft, Apple, IBM, y cualquier empresa que tenga tales departamentos, postear en las redes sociales, y pasar de boca en boca.

Si se puede encontrar algún sponsor que ofrezca una recompensa apetitosa, bienvenido sea.

1) Se solicita construir un programa que ejecute el código del programa que recibe como input. Debe además funcionar con su propio código como input. Se considerará que funciona si el programa objeto se completa con un estado final, o queda ejecutando un ciclo infinito, pero se considerará que no funciona si produce error por falta de argumentos o se queda indefinidamente esperando el input.

2) Construir asimismo un programa que, dado otro programa que emule una máquina de Turing, decida si puede ser reducido a un autómata finito o no. Se solicita además que funcione con su propio código en las mismas condiciones que en el punto 1, si aplica.

Saludos!

12 Enero, 2012, 05:28 pm
Respuesta #1

feriva

  • $$\Large \color{#a53f54}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 11,339
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
Fíjate en esto, Elius, he hecho unas modificaciones en cuanto al programa que te había puesto en el post anterior. 

10 let A=1
 
 20 if A=1 then goto 40

 30 let A=1; REM pero esto no modifica el programa que está siendo leído, y no hace nada en el programa que ejecuta, pues la variable A del programa que ejecuta ya está cargada con ese valor 1

35 goto 20
 
 40 print: "El programa ha funcionado"; stop

(REM era el comando que se usaba en el Basic antiguo para comentar las líneas de sentencia)

 Como ves, intentaba que, con otro bucle, el programa llegara a ejecutarse entero, sin embargo, para ello -tal y como comento en la línea REM- tendría que reescribir, cambiar el código fuente, del programa pasivo; con lo que ya no sería el mismo programa.

Podría hacerlo, podría cambiarlo, pero ya no sería igual al programa que ejecuta y habría de cambiar también el programa ejecutor; y vuelta a lo mismo sin fin, no tiene salida, ¿lo entiendes ahora?

Saludos.

12 Enero, 2012, 09:03 pm
Respuesta #2

Elius

  • $$\Large \color{#5e8d56}\pi\,\pi\,\pi$$
  • Mensajes: 399
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
@feriva
No sé si entiendo lo que que me dices que tengo que entender. Parece un trabalenguas pero es real.
¿Me preguntas si entiendo que es imposible hacer un programa como el que pido?

Yo pienso lo mismo, pero no puedo demostrarlo de una manera convincente para todos, ya lo intenté en otro hilo sobre el Halting Problem, pero todos me responden con las suposiciones teóricas que hizo Turing, o diciendo que porque yo muestre un programa que no puede ejecutar su input no demuestro que ninguno pueda.

Por otra parte, ¿entiendes tú que diciendo lo que dices estás oponiéndote a las suposiciones que hizo Turing para su famoso teorema? Es decir, él dice que la máquina de Turing del Halting Problem para o no para, no hay tercera posibilidad. Yo creo que si le da a leer su propio código no puede emularlo, verificarlo, intentar ver si para o no para, porque la "versión" de sí misma que leyó a su vez está esperando un input que nunca llega. Y esto no es terminar bien, ni entrar en loop. Es la tercera posibilidad que todos niegan.

Ya sé que es Turing, que luego de 76 años nadie ha podido rebatirlo. Pero bueno, si es así, habrá una explicación oculta que nadie muestra jajaja!

Saludos!


12 Enero, 2012, 09:33 pm
Respuesta #3

Óscar Matzerath

  • $$\Large \color{#c88359}\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 567
  • Karma: +0/-0
  • Sexo: Masculino
Hola,

A ver, varias cosas. Primero, la situación que planteas aquí no es exactamente la misma que la que se planteaba en el primer hilo de la discusión de Turing. Allí Carlos Ivorra estaba usando una definición muy concreta de máquina de Turing, la que aparece en su libro, y según esa definición una máquina de Turing siempre hace algo, no existe la posibilidad "falta un input", porque los inputs en el sentido de esa definición de máquina de Turing no son más que una mera convención de empezar con la cinta escrita con una serie de 1's. Pero da igual que empieces con la cinta en blanco, con la cinta 101010101010, o cualquier combinación que se te ocurra: en cualquier caso, por la propia definición, la máquina hará algo y o bien parará o bien seguirá corriendo para siempre.
Aquí estás planteando una situación bien distinta, con un lenguaje de programación real para el que cabe la posibilidad de que falte un input (esto también puede ocurrir en según qué definiciones de máquina de Turing, puede ser que la máquina pare en el sentido de que deje de computar pero sin embargo no haya llegado al estado final y por tanto no nos dé ningún output: es una situación parecida al "error por falta de input" que propones). Pero esto no es ningún inconveniente para el problema de la parada, pues de hecho se pueden modificar las máquinas de Turing para que siempre paren (en el sentido de llegar al estado final) o entren en bucle (o incluso se pueden probar versiones del problema de la parada en cualquier variante: no existe una máquina que decida si una máquina dada con input dado para, entra en bucle, o da error, etc).

De todas maneras, creo que tu planteamiento es el siguiente (corrígeme si me equivoco). Consideras los programa (con 1 input digamos, para no complicarnos) P(n). Tienes otro programa U(m,n) que ejecuta el programa m con input n. Digamos que el código de U es N. ¿Qué pasa si intentamos ejecutar U(N,N)? U simula la ejecución de U con input N. Pero aquí falla algo: U necesita dos inputs y ahora sólo tiene uno, así que el programa falla por falta de inputs para U.
Bien, esto es cierto, pero no es lo que hace Turing. Te voy a mostrar que lo que hace Turing funciona de verdad, y lo voy a mostrar con un programa que se puede programar en la vida real (yo no lo voy a hacer, pero se puede hacer, y no me extrañaría que alguien lo hubiera hecho). del tipo que pides: un programa que se ejecuta a sí mismo pero sin embargo nunca acaba.

Considera U(m,n) un programa universal para programas con un input: si m es el código de un programa con un input P y n es el input, U(m,n) simula la ejecución de P(n).
Ahora considera el siguiente programa con un sólo input, U'(m). U'(m) primero hace una copia del input m y después ejecuta U(m,m). Bien, ahora sea N el código de U'. ¿Qué pasa si hacemos U'(N)? Veamos: U'(N) hace una copia de N y ejecuta U(N,N): es decir, simula la ejecución de U' con input N. Hemos vuelto al principio: esto es un bucle infinito. Si analizas bien este programa (que como he dicho, puede programarse de verdad) solventa la posible falta de input haciendo contínuamente copais de sí mismo e introduciéndolas como input para sí mismo en el siguiente paso: esa es la salida a la situación del párrafo anterior.

Si te fijas, lo que he hecho es exactamente lo mismo que hace Turing para llegar a la contradicción, sólo que en vez de aplicarlo a un programa que resuelve el problema de la parada (que no existe), lo he aplicado a un programa que sí existe: un programa universal.

Saludos

12 Enero, 2012, 10:22 pm
Respuesta #4

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,739
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Ya que hablamos de programas reales,
asumo que los procesos por lotes son un lenguaje de programación, sencillo, pero tiene su sintaxis y todo.

Un proceso por lotes en DOS/Windows que haría de "máquina universal" U(m, n) sería uno muy sencillo:

universal.bat:


@if '%2'=='' universal.bat %1 %1
%1 %2


_________________

Tiene dos líneas.
El programa acepta dos parámetros.

El primer parámetro tiene que ser necesariamente un proceso ejecutable, digamos P1,
y el segundo parámetro funcionará como "primer parámetro" al invocar el programa P1.

Supongamos que invocamos el editor de textos NOTEPAD.
Se ejecutaría tras invocar:

universal.bat notepad.exe hola.txt

y eso abriría el archivo hola.txt para edición.

O sea que "simularía" perfectamente la ejecución del programa notepad.exe con parámetro hola.txt, tal como si hubiéramos hecho esta llamada:

notepad.exe hola.txt

_________________

Finalmente, como universal.bat es ejecutable, se puede llamar a sí mismo, así:

universal.bat universal.bat universal.bat

Tras la llamada, esto produce:

universal.bat universal.bat

Lo cual llama de nuevo a universal.bat, pero con un sólo parámetro.
Sin embargo, dentro de la misma rutina universal.bat la primer sentencia se encarga de averiguar si hay un solo parámetro o más.
En caso de que haya un solo parámetro, se hace una rellamada con dos parámetros.

________________________

Hacer versiones con lenguajes de programación como C, Java, Pascal, etc., es posible, pero requiere más trabajo, lo cual es innecesario, con tal de entender que esto es posible.


12 Enero, 2012, 10:39 pm
Respuesta #5

feriva

  • $$\Large \color{#a53f54}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 11,339
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino

Por otra parte, ¿entiendes tú que diciendo lo que dices estás oponiéndote a las suposiciones que hizo Turing para su famoso teorema?


No creo, lo que ocurre es que Turing trabaja con una idea muy "humanizada" o primitiva, con una máquina de escribir que "lee" y "escribe". Pero en el fondo se parece no poco al código máquina de hoy -y de siempre- los que no se parecen tanto son los lenguajes de alto nivel que, por comodidad, utilizamos. La idea de fondo, aparte de que se pueda demostrar formalmente -que ahí no me meto, porque doctores tiene la Iglesia, como el obispo Óscar  :laugh: -, es simplemente que un sistema, para poder operar, tiene que cambiar, si cambia, "ya no es el que era", no puede ser al mismo tiempo el que es y el que "era", es una contradicción.

Saludos.

12 Enero, 2012, 11:09 pm
Respuesta #6

Elius

  • $$\Large \color{#5e8d56}\pi\,\pi\,\pi$$
  • Mensajes: 399
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
@feriva
Ja ja ja! Quedastte bien con todo el mundo!

Pero bueno, alguien ya me mostrará la famosa máquina que puede interpretar/emular su propio código (si no ejecutarlo).

Saludos!


13 Enero, 2012, 12:17 am
Respuesta #7

feriva

  • $$\Large \color{#a53f54}\pi\,\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 11,339
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
@feriva
Ja ja ja! Quedastte bien con todo el mundo!




Depende de cómo se haya tomado la broma Óscar (pero no creo que se haya enfadado, porque la hizo él primero  :laugh: )

 He estado buscando a ver si en los ordenadores de hoy se podía seguir "pokeando" en memoria, como sí se podía con los Spectrum. Ese comando -la instrucción POKE- permitía meter códigos en binario directamente; eso era programar directamente sin ningún lenguaje intermediario. Por lo que he visto en algún foro, la gente ya no sabe lo que es o habla de ello como algo de la era de los dinosaurios. Es una pena, hoy no sería útil, pero sería muy ilustrativo; aunque quizá un poco peligroso, dados los hackers que hay por ahí. Se puede hacer algo parecido, según también he leído, con la máquina Java, pero no sé cómo. Te pongo un enlace:

 http://es.wikipedia.org/wiki/POKE

 Saludos.

13 Enero, 2012, 12:39 am
Respuesta #8

Óscar Matzerath

  • $$\Large \color{#c88359}\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 567
  • Karma: +0/-0
  • Sexo: Masculino
Hola,



Depende de cómo se haya tomado la broma Óscar (pero no creo que se haya enfadado, porque la hizo él primero  :laugh: )

¡Qué me voy a enfadar!  ;D


Pero bueno, alguien ya me mostrará la famosa máquina que puede interpretar/emular su propio código (si no ejecutarlo).


No has dado tu opinión sobre la implementación de argentinator del argumento de Turing.

Saludos

13 Enero, 2012, 12:41 am
Respuesta #9

Elius

  • $$\Large \color{#5e8d56}\pi\,\pi\,\pi$$
  • Mensajes: 399
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
@feriva, @Óscar, @argentinator
antes de respónder, les agradezco que se enganchen con mis empecinamientos.
Una de dos, o salgo "curado", y convencido de mi error (aunque ahora no lo veo así), o me canso tanto de responder y responder y responder, que aunque siga con la misma idea, la dejo guardada para siempre en un cajón. Lo que se llama un loco que no se curó pero se amansó y no dice más nada, jajaja!

Más tarde respondo, porque me la han hecho difícil, eh.

Saludos!