Autor Tema: Comentarios a El teorema de Gödel (en Z)

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

23 Abril, 2018, 10:40 am
Leído 8934 veces

Carlos Ivorra

  • Administrador
  • Mensajes: 11,112
  • País: es
  • Karma: +0/-0
  • Sexo: Masculino
    • Página web personal
Abro este hilo para recoger los comentarios, dudas, observaciones, etc. que pueda suscitar el hilo

El teorema de Gödel (en Z)

sin interrumpir la exposición.

23 Abril, 2018, 01:36 pm
Respuesta #1

sugata

  • $$\Large \color{#9c57a6}\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 3,612
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
Pregunta muy básica.
¿Que es ZFC?

23 Abril, 2018, 01:54 pm
Respuesta #2

Carlos Ivorra

  • Administrador
  • Mensajes: 11,112
  • País: es
  • Karma: +0/-0
  • Sexo: Masculino
    • Página web personal
Es la teoría de conjuntos de Zermelo-Fraenkel con el axioma de elección (Choice). En un mensaje posterior presentaré sus axiomas, pero tienes este hilo de argentinator mucho más detallado.

De todos modos, los detalles técnicos sobre lo que es ZFC no son relevantes para la prueba del teorema de Gödel (más allá de lo poco que diré al respecto en su momento). En la práctica, basta tener claro que "demostrar en ZFC" es ni más ni menos que lo que los matemáticos entienden por "demostrar". Cualquier argumento (correcto) que leas en este foro como respuesta a una pregunta es un teorema de ZFC. De hecho, en muchas ocasiones no son necesarios todos los axiomas de ZFC, sino que, por ejemplo, el axioma de elección es prescindible a menudo.

23 Abril, 2018, 01:58 pm
Respuesta #3

sugata

  • $$\Large \color{#9c57a6}\pi\,\pi\,\pi\,\pi\,\pi\,\pi$$
  • Mensajes: 3,612
  • País: es
  • Karma: +1/-0
  • Sexo: Masculino
Perfecto, gracias.
Estos días leeré detenidamente la entrada y, si estoy al nivel de entenderlo, te iré preguntando dudas.

24 Abril, 2018, 10:29 pm
Respuesta #4

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,738
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
En primer lugar necesitamos una sucesión infinita de signos a los que llamaremos variables:

\( x_0, x_1, x_2,\ldots \)

Pedimos que sea infinita porque un matemático, después de haber llenado 20 pizarras con una demostración, siempre tiene que tener derecho a escribir una línea más en la que aparezca una variable nueva que no haya aparecido hasta entonces. Un matemático nunca usará más de una cantidad finita de variables, pero siempre puede ir añadiendo más según le vaya haciendo falta.


Poniéndolo de ese modo, la verdad es que las pizarras están hechas de átomos, y ningún matemático puede escribir más variables que el número de átomos del Universo.

Si el Universo fuese finito en número de átomos (hasta ahora sólo hay evidencia empírica que apoye la finitud),
basta considerar N variables, con N igual al número de partículas del Universo.

La cuestión es si el Teorema de Godel depende o no del hecho de disponer de una cantidad fija N de variables.
Es decir, si para poder probarlo hacen falta infinitas variables.
No lo recuerdo ahora, pero me parece que no, siempre que haya un número de variables bastante grande como para expresar las sentencias de Godel.

Citar

Además de las variables necesitamos dos conectores lógicos \( \lnot \) y \( \rightarrow \) y un cuantificador universal \( \forall \).


Se puede ser aún más económico, usando un único signo para representar operaciones tipo NAND o NOR.

Citar
Por último, necesitaremos dos signos que llamaremos relatores: \( = \) y \( \in \).

En este caso se puede pensar en hacer un poco de economía también,
aunque de una manera poco ortodoxa, introduciendo un símbolo \( \underline\in \),
con el sentido de: "pertenece o es igual a".

De modo que si \( X \underline\in Y \) y \( Y \underline\in X \) entonces \( X= Y \).

Este deseo de ahorrar en signos seguramente repercutirá con costos en alguna otra parte.

Citar
En resumen, los signos del lenguaje de la teoría de conjuntos son

\( \begin{array}{ccccccccc}
\lnot&\rightarrow&\forall&=&\in&x_0&x_1&x_2&\cdots
\end{array}
 \)

y ninguno más.
\( \begin{array}{ccccccccc}
\bar\vee&\forall&\underline\in&x_0&x_1&x_2&\cdots& x_N
\end{array}
 \)  :P

Citar
Adoptamos el convenio de que los relatores van delante de las variables,

Sabio convenio.
No sólo por el teorema "fundamental de la aritmética (de fórmulas)" que enunciás luego,
sino que también es más simple el trabajo de una computadora al reconocer fórmulas de un tipo u otro,
al evitarse todo el trabajo de analizar paréntesis bien nivelados.

Citar

Ahora definimos una sucesión generadora de fórmulas como una sucesión finita de cadenas de signos, digamos \( \alpha_1,\ldots, \alpha_n \), con la propiedad de que cada término de la sucesión esté en uno de los casos siguientes:

  • Sea una fórmula atómica.
  • Sea de la forma \( \lnot\alpha \), donde \( \alpha \) es una cadena previa en la sucesión.
  • Sea de la forma \( \rightarrow \alpha\beta \), donde \( \alpha \) y \( \beta \) son cadenas previas en la sucesión.
    En la práctica, en lugar de \( \rightarrow\alpha\beta \) escribiremos \( \alpha\rightarrow \beta \).
  • Sea de la forma \( \forall x \alpha \), donde \( x \) es una variable y \( \alpha \) es una cadena previa en la sucesión.

Usando NOR, se acorta la lista anterior en un ítem,
lo cual presumo que también reducirá la complejidad al programar un reconocer de fórmulas.

Citar
Podemos pensar que la notación de "alto nivel" es como un lenguaje de programación (tipo C o Java, etc.) mientras que la notación de "bajo nivel" es el lenguaje máquina que, en último extremo, no es más que una sucesión de ceros y unos, que es lo que realmente se guarda en la memoria del ordenador. Cualquier afirmación de un lenguaje de programación sólo es aceptable en la medida en que el ordenador sepa transformarla en instrucciones de lenguaje máquina, que es lo único que realmente tiene sentido para él y sabe ejecutar. Del mismo modo, somos libres de nombrar a las fórmulas con los convenios que juzguemos convenientes siempre y cuando esté claro en todo momento a qué cadena de signos estamos haciendo referencia con nuestros criterios de notación.

Aquí se habla de un "ordenador" como algo capaz de interpretar el lenguaje de máquina.
Ocurre que el lenguaje de máquina es, simplemente, un lenguaje como cualquier otro.
Lo que hace distintivo a la máquina es su "capacidad de ejecución de tareas".

Aunque en el contexto de lenguajes formales matemáticos se introduce la semántica aparte del lenguaje,
en la especificación del lenguaje C, por ejemplo, no se hace alusión alguna al lenguaje de máquina,
sino al "comportamiento esperado" en un entorno de ejecución determinado.
O sea que si una computadora pudiera, de alguna forma, "leer C", sin pasar por un lenguaje de máquina intermedio, el mismo C sería el lenguaje de esa computadora, y así sería de "bajo nivel".

En realidad, lo que me llama la atención acá es el hecho de que el "lenguaje C" no sólo se especifica en términos sintácticos, sino también en términos de una máquina abstracta subyacente junto con los lineamientos esperados del comportamiento observable de un programa. Por ejemplo, se describe en la especificación del lenguaje cómo ha de ser la representación de datos de tipo entero sin signo en forma interna en la computadora.

En otro lenguaje de programación cualquiera, dicha representación interna de los enteros no tendría por qué especificarse, y los números representarse internamente con un criterio cualquiera.





24 Abril, 2018, 11:28 pm
Respuesta #5

Carlos Ivorra

  • Administrador
  • Mensajes: 11,112
  • País: es
  • Karma: +0/-0
  • Sexo: Masculino
    • Página web personal
Poniéndolo de ese modo, la verdad es que las pizarras están hechas de átomos, y ningún matemático puede escribir más variables que el número de átomos del Universo.

Si el Universo fuese finito en número de átomos (hasta ahora sólo hay evidencia empírica que apoye la finitud),
basta considerar N variables, con N igual al número de partículas del Universo.

La cuestión es si el Teorema de Godel depende o no del hecho de disponer de una cantidad fija N de variables.
Es decir, si para poder probarlo hacen falta infinitas variables.
No lo recuerdo ahora, pero me parece que no, siempre que haya un número de variables bastante grande como para expresar las sentencias de Godel.

No, en realidad la cuestión no es si el teorema de Gödel depende de eso. Si admites infinitas variables el teorema de Gödel afirma algo más fuerte que si no las admites. Estamos diciendo que la sentencia de Gödel es indemostrable incluso si admitimos infinitas variables. Si sólo admitiéramos N, cabría preguntarse si la sentencia de Gödel sería demostrable con N+1 variables, pero la respuesta es que no, que ni con infinitas sería posible.

Así pues, lo de las infinitas variables no es una hipótesis cuestionable, sino todo lo contrario, es la ausencia de una restricción cuestionable.

Citar
Además de las variables necesitamos dos conectores lógicos \( \lnot \) y \( \rightarrow \) y un cuantificador universal \( \forall \).

Se puede ser aún más económico, usando un único signo para representar operaciones tipo NAND o NOR.

Citar
Por último, necesitaremos dos signos que llamaremos relatores: \( = \) y \( \in \).

En este caso se puede pensar en hacer un poco de economía también,
aunque de una manera poco ortodoxa, introduciendo un símbolo \( \underline\in \),
con el sentido de: "pertenece o es igual a".

De modo que si \( X \underline\in Y \) y \( Y \underline\in X \) entonces \( X= Y \).

Este deseo de ahorrar en signos seguramente repercutirá con costos en alguna otra parte.

Lo del "pertenece o es igual a" no acabo de verlo, pero, respecto a todo lo demás, no sucede que el ahorrar en signos provoca costos en otra parte. El ahorro en signos se compensa inmediatamente en la práctica en cuanto se definen los demás signos a partir de ellos, con lo que desde casi el primer momento cuentas ya con todos los signos lógicos usuales. Sin embargo, el hecho de que en teoría sólo haya dos conectores y un cuantificador, se traduce en que si en una demostración tienes que distinguir un caso por cada signo lógico, en lugar de tener que distinguir siete casos (negador, implicador, disyuntor, conjuntor, coimplicador, generalizador, particularizador) sólo tengas que distinguir tres.

Por otra parte, si introduces, por ejemplo, el disyuntor como signo básico, tienes que añadir axiomas lógicos que lo "definan", es decir, que lo relacionen con los demás signos lógicos, con lo que aumenta el número de axiomas lógicos imprescindibles.

Lo de economizar aún más reduciendo los signos lógicos a uno solo, ya no sé si sería rentable. Es posible que sí, pero no tengo claro que las pruebas que resultan naturales cuando se reducen a chequear el negador, el implicador y el generalizador también lo serían si hubiera que reducirlas a NAND y el generalizador. Tal vez en el contexto que nos ocupa sí lo serían, pero en otros contextos distintos ya no me atrevería a segurarlo.

Citar
En resumen, los signos del lenguaje de la teoría de conjuntos son

\( \begin{array}{ccccccccc}
\lnot&\rightarrow&\forall&=&\in&x_0&x_1&x_2&\cdots
\end{array}
 \)

y ninguno más.
\( \begin{array}{ccccccccc}
\bar\vee&\forall&\underline\in&x_0&x_1&x_2&\cdots& x_N
\end{array}
 \)  :P

Alguien se ha levantado hoy tiquismiquis...

Citar
Adoptamos el convenio de que los relatores van delante de las variables,

Sabio convenio.
No sólo por el teorema "fundamental de la aritmética (de fórmulas)" que enunciás luego,
sino que también es más simple el trabajo de una computadora al reconocer fórmulas de un tipo u otro,
al evitarse todo el trabajo de analizar paréntesis bien nivelados.

En efecto, ésa es su utilidad principal: simplifica enormemente determinar si una cadena de signos dados es o no una fórmula y, en caso de que lo sea, deteminar su estructura.

Citar
Ahora definimos una sucesión generadora de fórmulas como una sucesión finita de cadenas de signos, digamos \( \alpha_1,\ldots, \alpha_n \), con la propiedad de que cada término de la sucesión esté en uno de los casos siguientes:

  • Sea una fórmula atómica.
  • Sea de la forma \( \lnot\alpha \), donde \( \alpha \) es una cadena previa en la sucesión.
  • Sea de la forma \( \rightarrow \alpha\beta \), donde \( \alpha \) y \( \beta \) son cadenas previas en la sucesión.
    En la práctica, en lugar de \( \rightarrow\alpha\beta \) escribiremos \( \alpha\rightarrow \beta \).
  • Sea de la forma \( \forall x \alpha \), donde \( x \) es una variable y \( \alpha \) es una cadena previa en la sucesión.

Usando NOR, se acorta la lista anterior en un ítem,
lo cual presumo que también reducirá la complejidad al programar un reconocer de fórmulas.

Cierto.

Citar
Podemos pensar que la notación de "alto nivel" es como un lenguaje de programación (tipo C o Java, etc.) mientras que la notación de "bajo nivel" es el lenguaje máquina que, en último extremo, no es más que una sucesión de ceros y unos, que es lo que realmente se guarda en la memoria del ordenador. Cualquier afirmación de un lenguaje de programación sólo es aceptable en la medida en que el ordenador sepa transformarla en instrucciones de lenguaje máquina, que es lo único que realmente tiene sentido para él y sabe ejecutar. Del mismo modo, somos libres de nombrar a las fórmulas con los convenios que juzguemos convenientes siempre y cuando esté claro en todo momento a qué cadena de signos estamos haciendo referencia con nuestros criterios de notación.

Aquí se habla de un "ordenador" como algo capaz de interpretar el lenguaje de máquina.
Ocurre que el lenguaje de máquina es, simplemente, un lenguaje como cualquier otro.
Lo que hace distintivo a la máquina es su "capacidad de ejecución de tareas".

Seguro que tú sabes mucho más de ordenadores que yo (entre otras cosas porque apenas sé nada), pero tengo algunas dudas sobre lo que afirmas. Al fin y al cabo (por lo menos en los ordenadores de la época en la que yo me interesé algo por ellos) los microprocesadores apenas sabían hacer otra cosa que sumar bytes y unas pocas operaciones más (eso sí, muy rápidamente), y el lenguaje máquina se ajustaba a lo poco que un microprocesador sabía hacer (leer direcciones de memoria, guardar información en unos pocos registros, hacer unas pocas operaciones con ellos y ya está). Por eso es un lenguaje muy sencillo con muy pocas instrucciones disponibles.

Aunque en el contexto de lenguajes formales matemáticos se introduce la semántica aparte del lenguaje,
en la especificación del lenguaje C, por ejemplo, no se hace alusión alguna al lenguaje de máquina,
sino al "comportamiento esperado" en un entorno de ejecución determinado.
O sea que si una computadora pudiera, de alguna forma, "leer C", sin pasar por un lenguaje de máquina intermedio, el mismo C sería el lenguaje de esa computadora, y así sería de "bajo nivel".

Sí, pero yo sólo estaba estableciendo un símil basado en lo que sucede ¿realmente? con los ordenadores, que tienen microprocesadores muy rápidos, pero que sólo saben sumar y poco más, de modo que cualquier otro lenguaje de programación, como el C, tiene que ser transformado en un lenguaje de bajo nivel que no hable de bucles, ni de números reales, ni de imprimir, ni de leer el teclado, etc., sino meramente de leer y escribir en ciertas direcciones de memoria y de hacer operaciones elementales con las lecturas.

El símil era para visualizar que una demostración matemática reducida a los signos "originales" y a los axiomas lógicos y las reglas de inferencia "originales" sería algo ilegible, igual que lo es un programa en código máquina adaptado a las capacidades de un microprocesador (por lo menos de uno de los de mis tiempos).

En realidad, lo que me llama la atención acá es el hecho de que el "lenguaje C" no sólo se especifica en términos sintácticos, sino también en términos de una máquina abstracta subyacente junto con los lineamientos esperados del comportamiento observable de un programa. Por ejemplo, se describe en la especificación del lenguaje cómo ha de ser la representación de datos de tipo entero sin signo en forma interna en la computadora.

En otro lenguaje de programación cualquiera, dicha representación interna de los enteros no tendría por qué especificarse, y los números representarse internamente con un criterio cualquiera.

Sí, pero, al final, un intérprete de C tiene que ocuparse de transformar una cadena de instrucciones que sigue esa sintaxis más o menos despreocupada del funcionamiento interno del ordenador en una cadena de instrucciones que sepa interpretar un microprocesador que apenas sabe leer y escribir en la memoria y contar con los dedos. En cualquier caso, si eso ya no es así con los microprocesadores modernos, mi ejemplo tiene que trasladarse a otra época, para que la comparación con el caso de los lenguajes formales sea válida.

24 Abril, 2018, 11:51 pm
Respuesta #6

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,738
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
Pues en realidad lamento haberte hecho perder tiempo leyendo sobre eso.
Aún cuando podría ssguir insistiendo un poco más. Pero no agregaría nada útil.

Mejor te comento luego sobre otras cosas más matemáticas

25 Abril, 2018, 12:08 am
Respuesta #7

Carlos Ivorra

  • Administrador
  • Mensajes: 11,112
  • País: es
  • Karma: +0/-0
  • Sexo: Masculino
    • Página web personal
Pues en realidad lamento haberte hecho perder tiempo leyendo sobre eso.
Aún cuando podría ssguir insistiendo un poco más. Pero no agregaría nada útil.

Mejor te comento luego sobre otras cosas más matemáticas

Hombre, no es eso. Insisto en que no sé gran cosa de ordenadores. Seguro que, ante cualquier discrepancia al respecto, tienes razón tú. Lo que digo es que, en caso de que lo que digo no se ajuste realmente a la realidad de cómo van los ordenadores, para que el ejemplo cumpla su misión hay que entenderlo como si las cosas fueran como yo creía que eran.

25 Abril, 2018, 12:32 am
Respuesta #8

Carlos Ivorra

  • Administrador
  • Mensajes: 11,112
  • País: es
  • Karma: +0/-0
  • Sexo: Masculino
    • Página web personal
Aún cuando podría ssguir insistiendo un poco más. Pero no agregaría nada útil.

Pues me has dejado pensativo. Aunque sea desviarnos del hilo, no me resisto a hacerte una pregunta: imagina que coges un CD en el que esté guardado una aplicación comercial, digamos Microsoft Word. Prescindamos de que en realidad lo que hay ahí es un programa instalador que distribuye archivos por varios puntos del ordenador y centrémonos en lo que es el núcleo principal del programa, lo que quedará guardado en un directorio reservado al Word y no en directorios del sistema operativo. Supongamos que tampoco hay ninguna compresión de datos para ahorrar espacio en el CD. Si uno se pone a analizar tal cual lo que hay escrito en el CD, ¿qué puede sacar en claro a partir de ahí? Si, por ejemplo, el Word estuviera programado en C (que no tengo ni idea), ¿analizando lo que hay en el disco se podría recuperar el código C usado para programarlo? Yo creo que ni en sueños, pero no sé si lo que estabas argumentando antes contradice mi creencia.

25 Abril, 2018, 02:26 pm
Respuesta #9

argentinator

  • Consultar la FIRMAPEDIA
  • Administrador
  • Mensajes: 7,738
  • País: ar
  • Karma: +0/-0
  • Sexo: Masculino
  • Vean mis posts activos en mi página personal
    • Mis posts activos (click aquí)
No. La compilación no es reversible.
Pero diría que es más bien por el hecho de que dos programas fuente distintos pueden llevar a un mismo ejecutable.

Lo que digo es que entiendo las máquinas más bien por especificación de funcionamiento y no por el lenguaje máquina que usan.
Es como la discusión que teníamos de inteligencia artificial. Si vuela, ¿es un ave?
El C define en su especificación el comportamiento observable esperado, no especifica nada más.

Un programa Java ejecuta en una máquina virtual Java.
Si la MV traduce luego a código máquina es su problema.
Si es sostenida por unos pitufos que ejecutan las tareas,  la MV no se entera.
El Java se traduce a un código máquina de la máquina virtual.

Y además, si yo leo un programa en C y sigo paso a paso las líneas, escribiendo en una pizarra los valores de variables,  archivos y mensajes en pantalla,  estoy ejecutando C sin usar un compilador.
Un poco lento eso sí.