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
Muy bonito, je je.
Pero si nos permitimos redefiniciones de las condiciones iniciales del programa que representa a la MT de Turing, yo podría agregar lo siguiente, para evitar que Turing use el código de la máquina testeadora como input:
@if '%0'=='%1' ( echo Turing: esto no es válido
Compara el input con su propio nombregoto :fin )
@if '%2'=='' universal.bat %1 %1
%1 %2
:fin
Output:
C:\> UNIVERSAL UNIVERSAL UNIVERSAL
Turing: esto no es v?lido
C:\>
También es algo nuevo que si le falta input, bueno, lo arreglo llamándolo al mismo bat con el primer argumento duplicado.
Lo que me parece incomprensible es que para no sacar el simple y humilde mensajito "Falta un argumento", se hace entrar al proceso no ya en un bucle infinito, que sólo consume tiempo, sino a una cadena potencialmente infinita de llamadas que pueden hacer colapsar la memoria de la máquina. Los sistemas operativos tienen defensas para casi todo, pero no para la proliferación de procesos.
En resumen, no llega a terminar normalmente, en el caso "ingenuo" (sin sentencias "ad hoc"), porque se queda sin input; y en el caso "malicioso" (porque sabe que se queda sin input pero trata de ocultarlo), porque se queda leyendo infinitamente su input, o su input es infinito, como prefieras.
En ningún caso le serviría a Turing, me parece.
**************
El caso Ivorra también es "ad hoc": en vez de poner dentro del código una previsión ante la falta de input, pone como hipótesis que ante la cinta en blanco entra en loop o termina "bien". En ese caso siempre hay una respuesta ya predeterminada, y no se puede llegar a la contradicción que necesita Turing. Supongamos que ante la falta de input la máquina interna loopea. La máquina externa para, y siempre es así, no podemos agregar: "y si la máquina interna para, la máquina externa loopea", porque ese caso no se da nunca. Ergo, no hay contradicción.
Eso para el caso de la predicción del loop, el de Turing.
En el caso que planteé yo, de autoaplicación pura sin predicción, en el caso de las MT es una MUT que llama a otra MUT que no tiene máquina objeto que ejecutar.
Considera que no es simplemente que faltan datos en la cinta, en el caso de la MUT si la cinta está en blanco FALTA UNA MÁQUINA COMPLETA.
Sí, se puede decir, "bueno, si no tengo input para pasarle considero que es una máquina con la cinta en blanco", pero en ese caso no le queda otra alternativa que loopear, no puede parar porque NO TIENE MANERA DE "SABER" que TODA la cinta está en blanco. Tiene que seguir leyendo eternamente por si viene algún 0 o un 1. Entonces la máquina extena se queda eternamente esperando a su máquina interna; es decir, no termina nunca de
procesar CARGAR su input.
En las máquinas reales uno podría decir también: se queda esperando eternamente su input, es decir, se detiene. Pero eso es detectable, hay tercer estado que es no terminó de procesar ni loopeó. No tuvo input por timeout. En las MT una combinación de unos y ceros puede indicar "nulo", y mandarla a un estado que no es terminal. Es cuestión de definición, la suposición de Ivorra no es forzosa.
Saludos!
P.D.: Mencionas el primer hilo que abrí sobre esto, y el debate con Ivorra. Allí yo no asumí compromiso alguno con las definiciones que dió él allí o en su libro. De hecho, apenas pude abrir el hilo, y ya nos liamos en una discusión sobre una demostración que dió él, que llevó más de cien mensajes. Creo que no fue inútil, pero nada de lo que dije allí fue para defender mi tesitura, sino para rebatir la de él.
