58 votos

¿Cómo verifican un verificador de pruebas formalizadas?

En un hilo sin relación de Sam Nead me ha intrigado por mencionar un formalizado la prueba de la Jordania de la curva de teorema. Luego encontré que hay al menos dos, en dos sistemas diferentes. Esto es todo un logro, pero es de ningún uso para un matemático como yo? (No, esto no es lo que yo estoy pidiendo, la pregunta es en el final).

Me gustaría confiar en los teoremas que yo uso. Para este fin, puedo leer una prueba a mí mismo (de la mejor forma, pero a veces difícil de hacer) o creen expertos (un camino resbaladizo). Si yo sabía muy poco acerca de la topología, pero ocasionalmente, es necesario el teorema de Jordan, una máquina verificado la prueba me podría dar una mejor opción (e incluso si estoy dispuesto a confiar en los expertos, podría asegurarse de que no hay suposiciones ocultas evidente para los expertos, pero desconocido para mí).

Pero, ¿cómo asegurarse de que una máquina verificado la prueba correctamente? La verificación de programa es demasiado complejo para ser de confianza. Una solución es, por supuesto, que este programa inteligente genera un largo, ilegible prueba de que puede ser verificado por un tonto programa (tan tonto que un programador amateur podría escribir o comprobar). Me refiero a un programa que realiza sólo primitiva de la sintaxis de las operaciones como "plug afirmaciones 15 y 28 en el esquema 9". Este "tonto" de la parte debe ser independiente de los "inteligentes" de parte.

Dado un sistema, pude comprobar los axiomas, las definiciones y la declaración del teorema, alimentar a los mudos programa (cuyo funcionamiento se que puedo comprender) con estas formulaciones y el tiempo de prueba y ver si tiene éxito. Que me convencen de que la prueba es de hecho verificado.

Sin embargo no encontré rastros de este "tonto" parte del sistema. Y entiendo que el diseño de uno puede ser duro. Porque el lenguaje utilizado por el sistema debe ser fácil de usar (por lo que un ser humano puede comprobar que las definiciones son correctas) y usar el ordenador (para que un tonto programa puede analizar). Y las definiciones deben ser elegidos con cuidado - no quiero cavar a través de una construcción particular de los reales de racionales para asegurarse de que este es, de hecho, los reales, que yo sepa.

Lo siento por esta filosofía, aquí está la pregunta en el pasado. Hay un "tonto" sistema alrededor? Si sí, ¿formalización de los proyectos de uso? Si no, reconocen la necesidad y poner el esfuerzo en su desarrollo? O tienen otros medios para hacer que sus sistemas de fiar?

ACTUALIZACIÓN: Gracias a todos por respuestas interesantes. Permítanme aclarar que el enfoque principal es la interoperabilidad con un humano matemático (que no es necesariamente un experto en lógica). Parece que esto está cerca de la interoperabilidad entre sistemas - si formales de los lenguajes aceptados por los básicos a los inspectores de hecho simple, es que debe ser fácil de traducir automáticamente entre ellos.

Por ejemplo, supongamos que uno quiere permanecer dentro de la lógica simbólica se basa en simples sustituciones y los axiomas de la lógica libro. Parece fácil escribir estas lógicas de los axiomas más ZF axiomas, propiedades básicas (axiomas) de los reales y el avión, algunas de las definiciones de la topología, y, finalmente, la declaración de la Jordania de la curva de teorema. Si la sintaxis es razonable, no debe ser fácil escribir un programa que verifica que otra secuencia de bytes que representa una deducción del teorema de la lista de axiomas. Puede, como los sistemas de Mizar, Coq, etc, generar datos de entrada para un programa de este tipo? Pueden producir pruebas verificables por los núcleos de otros sistemas?

31voto

Sekhat Puntos 2555

Hay un "tonto" sistema alrededor? Si sí, ¿formalización de los proyectos de uso? Si no, reconocen la necesidad y poner el esfuerzo en su desarrollo? O tienen otros medios para hacer que sus sistemas de fiar?

Este es el llamado "de Bruijn criterio" para una prueba de asistente, así como ustedes dicen, queremos una prueba simple corrector, que debe ser independiente de las otras máquinas. El teorema de provers que más directamente encarnan esta metodología son los de la LCF tradición, como Isabelle y HOL/Luz. Realmente funcionan mediante la generación de prueba de los objetos a través de cualquier programa de atención a la escritura, y que el envío de un pequeño núcleo de verificación. Los sistemas basados en dependiente de la teoría tipo (tales como el Coq) tienden a tener más complejo de núcleos lógicos (debido a la mayor flexibilidad de la lógica subyacente), pero incluso aquí un núcleo typechecker puede caber en un par de miles de líneas de código, que fácilmente pueden ser (y han sido) entiende y reimplantado.

28voto

Jonah Katz Puntos 128

Usted está pidiendo una gran cantidad de preguntas:

[Son equipo a prueba de asistentes] cualquier uso de un matemático como yo?

Sí. Aquí es cómo estos sistemas pueden ayudar:

  • En un nivel muy básico, estos sistemas evitar que cometa errores. Posteriormente, las piezas de repuesto de uno de los proceso de revisión de pares. Una de las pruebas de Jordania Curva teorema fue llevado a cabo por Thomas Hales, como parte de su intenta verificar la exactitud de la Conjetura de Kepler. Hales es básicamente recurrir al teorema automatizado demostrando porque siente que su prueba, lo que implica el establecimiento de 50.000 problemas de programación lineal son inviable (la última vez que revisé) no puede ser verificado por el ser humano de revisión por pares.

  • La mayoría de los sistemas (Coq, Isabelle, HOL-Luz) construido en la automatización. Esto ayuda a informar a los el sector informal de la noción de que los matemáticos han por lo que constituye un trivial, mecánica derivación y lo que es trivial - mi regla de oro es, si un equipo no puede automáticamente derivar una cierta, que es probablemente algo que me debe ilustrar de forma explícita.

  • Isabelle/HOL le permite utilizar el teorema automatizado provers E, SPASS y Vampiro automáticamente probar las proposiciones, el empleo de la totalidad de Isabelle/HOL s De la biblioteca a su disposición. Como Isabelle biblioteca crece, esto adquiere más y más poder.

Pero, ¿cómo asegurarse de que una máquina verificada la prueba correctamente?

Como Neel Krishnaswami se mencionó anteriormente, una forma en la que uno puede estar convencido de que es para aprender a programar en estado puro, funcional lenguajes de programación tales como OCAML o SML y leer el código fuente de los sistemas como HOL-luz o Isabelle. En ambos de estos sistemas que he mencionado, hay un archivo thm.ml que contiene las declaraciones del teorema de constructores. Estos sistemas también tienen instalaciones para declarar nuevos tipos. HOL-la Luz tiene, junto con las reglas básicas y los constructores de tipos, tres axiomas: extensionality (Leibniz de la Ley), el axioma de infinitud y el axioma de elección.

Por otra parte, HOL-la Luz ha sido diseñado por el autor John Harrison a la exposición relativa a la auto-consistencia de las pruebas, al igual que en la teoría de conjuntos. Usted puede leer acerca de ellos aquí: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.2210&rep=rep1&type=pdf

Aquí Harrison muestra HOL-Luz$-$Infinity tiene un modelo en el HOL-Luz, y HOL-la Luz tiene un modelo en el HOL-Luz+Grothendiek Cardenal.

Las definiciones deben ser elegidos cuidadosamente - no quiero cavar a través de una construcción particular de los reales de racionales para asegurarse de que que este es, de hecho, los reales de los que me saber.

Supongo que eres consciente de que todo completo ordenó campos son isomorfo a uno con el otro? Isabelle/HOL sucede para construir en ellos el uso de secuencias de Cauchy, y tiene en su biblioteca hay otra formulación que el uso de Dedekind Cortes. HOL-Luz formula la positiva reales mediante la limitación de las pendientes de las funciones de $f:\mathbb{N}\to\mathbb{N}$ y, a continuación, construye el total de reales utilizando un semi-anillo de finalización. Desde algebraicamente todas estas formulaciones seguramente son isomorfos, en la práctica, los detalles de su construcción están ocultos de los usuarios.

Hay un "tonto" sistema alrededor? Si sí, ¿formalización de los proyectos de uso que? Si no, reconocen la necesidad y poner el esfuerzo en su desarrollo? O tienen otros medios para hacer sus sistemas de fiar?

Todos ellos requieren de capacitación para aprender. Sin embargo, para la LCF estilo, como los sistemas de Coq, Isabelle, y HOL-Luz, es como lenguajes de programación: una vez que aprende uno, usted ha aprendido los principios necesarios para entender todos ellos.

Isabelle, y Mizar contar con instalaciones especiales para hacer pruebas más "humanos". El sistema de Isabelle se llama Isar. Estos sistemas no son para dummies, tristemente; lo que uno realmente necesita un poco de entrenamiento especial para dominarlas. Por otro lado, son mucho mejor que la de "aplicar" al estilo de las pruebas que se emplean comúnmente, ya que se ajustan mucho mejor a la intuición humana. Hay sistemas para Coq llamado César que en su infancia, pero espero que en última instancia hará que la Coq mucho más fácil de usar.

Si la sintaxis es razonable, se debe ser fácil escribir un programa que verifica que otra secuencia de bytes representa una deducción de la indicada teorema de la lista de axiomas. Puede como los sistemas de Mizar, Coq, etc, generar de entrada para un programa de este tipo? Puede que producir pruebas verificables por los núcleos de otros sistemas?

La respuesta corta es , el tiempo de respuesta es SÍ, pero es complicado. No todos los sistemas deductivos tienen el mismo poder expresivo. Establece en ZFC son un tipo especial de objeto que no se puede construir en la Lógica de Orden Superior. Para formular la teoría de conjuntos en Isabelle/HOL y HOL-el uso de la Luz, uno necesita postular que un tipo de objeto que cumple los axiomas de Zermelo Fraenkel de la teoría de conjuntos existe (esta es la ruta que Isabelle/HOLZF toma). Por otro lado, uno puede incrustar HOL en ZFC sin tanta dificultad - aquí es un papel donde un sistema de traducción de Isabelle/HOL en ZFC es dado usando el teorema de armario de LF: http://kwarc.info/frabe/Research/RI_isabelle_10.pdf

Chantal Keller ha importado HOL-Luz en Coq en su MSc tesis aquí: http://perso.ens-lyon.fr/chantal.keller/Documents-recherche/Stage09/itp10.pdf

La importación de vuelta de Coq es difícil. Coq mucho más expresivo tipo de sistema de HOL.

HOL-Luz y Isabelle/HOL puede ser inter-traducido, sin embargo:

Uno no se puede convertir Mizar pruebas a cualquier otro sistema, ya que es de código cerrado, y no tiene un núcleo pequeño se puede utilizar para producir la prueba de código legible por otros motores :(

15voto

x-way Puntos 196

Esta respuesta es realmente un aumento de la Neel s (pero demasiado largo para caber en un comentario). El "de Bruijn criterio" fue llamado así por su colega Henk Barendregt en el papel Autárquico, Cálculos en la Prueba Formal (con Erik Barendsen) a partir de 1997. Sin embargo, esto realmente está implícito en el de Bruijn del trabajo, véase, por ejemplo, El Lenguaje Matemático AUTOMATH, su Uso, y Algunas de sus Extensiones de 1968. El AUTOMATH archivo debe ser realmente necesaria lectura para cualquier persona interesada en ayuda de computadora de la deducción (como muchas personas todavía están re-descubriendo lo que de Bruijn ya se sabía de hace 40 años).

Por supuesto, la Barendregt/Barendsen artículo es interesante por derecho propio, ya que aboga por el uso de cálculos como legítimas a las partes de las pruebas, algo que los matemáticos hacen de forma rutinaria, pero la prueba de los sistemas basados en el "de Bruijn criterio" y la LCF enfoque tímido lejos -- hasta hace poco. Se dub este el Principio de Poincaré (que ciertamente se adhieren a). Ambos Coq y Isabelle han empezado a hacer más y más cálculos. Los puristas de los teoremas de la comunidad en PVS y antes de que PIM para hacer `demasiado" computación!

14voto

Bart B Puntos 147

Creo que la pregunta que usted está pidiendo - acerca de cómo podemos confiar en una prueba formal - es una pregunta muy importante. He dedicado mucho esfuerzo en el desarrollo de software específicamente para abordar esta cuestión. De tocar en varias cosas que me han concentrado en.

Es cierto que los diferentes sistemas prominente en la formalización de las matemáticas - incluyendo el HOL sistemas (HOL4, ProofPower HOL, HOL Luz), Isabelle y Coq - se construyen de acuerdo a la "LCF estilo", lo que significa que todos deducción debe ir a través de un relativamente pequeño núcleo de confianza de código fuente (la implementación de las primitivas reglas de inferencia), y que esto reduce considerablemente los riesgos de la precariedad de la producción de las pruebas en estos sistemas. También sería de no ser una exageración decir que casi todos los que trabajan en la prueba formal está feliz con esta situación. De hecho, probablemente la mayoría de (pero no de aquellos que trabajan en los sistemas anteriores) siento que recurrir a la LCF estilo es una exageración y un consumo innecesario de usuario de tiempo de ejecución y en el esfuerzo de desarrollo.

Sin embargo, hay 3 problemas principales con este status quo:

A) la Mayoría de los "LCF estilo" de los sistemas no implementar la LCF estilo núcleo idea de como puramente como se puede esperar. Algunos sistemas tienen de nuevo las puertas a la creación de "demostraron teoremas", tales como la importación de las declaraciones (pero no la pruebas) previamente comprobados resultados desde el disco, y la confianza que el usuario no abusar de esta. También, para reducir el tiempo de ejecución, la mayoría de los sistemas a implementar diversas que se pueden derivar reglas de inferencia como primitivas, multiplicando el tamaño de la confianza de código fuente. También, los núcleos de la mayoría de los sistemas suelen incorporar grandes cantidades de soporte de código (por ejemplo, para la organización de teorías) y no son particularmente claramente implementado, y así son difíciles de revisar. Cabe señalar que HOL Luz no sufre de cualquiera de estos problemas.

B) La confianza de los aspectos de la LCF-estilo del sistema NO está limitado a, el diseño/implementación de su LCF-estilo del núcleo. Como en todos los sistemas, de lo que se incluye también el diseño de la sintaxis concreta y la aplicación de la bonita de la impresora, ya que, en la práctica, el usuario sólo la vista de los resultados que se muestran en la sintaxis concreta a través de la bonita de la impresora. Sin embargo, cada sistema tiene problemas con su sintaxis concreta y/o bonitos de la impresora que permite que la información engañosa para ser visualizada por el usuario (por ejemplo, mediante el uso irregular de las variables de los nombres, o los nombres que están sobrecargados). He encontrado muchas maneras de aparecer a probar "false" en estos sistemas! Además, dependiendo de cómo se usa el sistema, el analizador es, posiblemente, también de confianza componente.

C) La importancia del proceso de comprobación de que el resultado esperado de hecho ha sido demostrado (yo llamo a esto "evidencia de auditoría") es generalmente muy subestimado, y en la práctica, a menudo ni siquiera se realiza. Como señalan acertadamente, los axiomas y las definiciones utilizadas en una prueba formal deben ser cuidadosamente controlada, así como la declaración del teorema de sí mismo. He conocido sutiles errores en las definiciones de procesamiento real de pruebas en proyectos reales completamente inválida.

He desarrollado una fuente abierta teorema de la demostrador denominado HOL Cero, que se ocupa de cuestiones A-C por encima y está diseñado para su uso en la prueba de auditoría y, en general, ser tan fiable como sea posible. Tiene un estanco de inferencia núcleo, un bien diseñado sintaxis concreta y bastante de la impresora, y el código fuente tiene el objetivo de ser lo más clara y bien-comentó como sea posible. Sin embargo, cabe señalar que no tiene la automática avanzada y/o interactivo prueba de las instalaciones de los sistemas existentes se menciono anteriormente, y no es adecuada para el desarrollo de grandes pruebas. HOL Cero puede ser descargado desde aquí (necesita OCaml y un sistema operativo de tipo Unix):

http://www.proof-technologies.com/holzero

El concepto de la comprobación de un sistema usando otra es no sólo filosóficamente tranquilizador, pero también de la urgente necesidad (debido a los problemas anteriores, A-C). Como usted dice, lo que se necesita es la capacidad de puerto de prueba de los objetos entre los sistemas (los llamados "de Bruijn criterio"). Estrictamente hablando, el de Bruijn criterio es usted el estado de su requerimiento - la capacidad de capturar una prueba de como un objeto (por ejemplo, un archivo de texto) - en lugar de la LCF estilo (pero no vamos a conseguir demasiado filosófico acerca de la equivalencia de estos enfoques). De todos modos, hay algunas cuestiones prácticas aquí:

  1. El "mudo" programa que se refieren a las necesidades a ser sorprendentemente sofisticado, de lo contrario, se pierde gran parte de su propósito. Si es sólo una LCF-estilo del núcleo, los datos de las salidas será demasiado lento para la revisión de proyectos de gran envergadura. Como dices, debe ser fácil de usar - una bastante decente impresora es una necesidad práctica. También, para hacer la prueba de la exportación (véase el siguiente punto) el trabajo en la práctica, que necesita para funcionar al menos en un nivel ligeramente más alto que el núcleo, y por lo que algunos apoyan la teoría es necesaria para ser construido. Eso sí, un tonto programa es necesario, que debería ser tan fácil de entender como sea posible, pero es más difícil de construir que un par de líneas de código.

  2. La captura de la prueba de los objetos en una adecuada forma eficiente es no trivial de ejercicio. El trabajo que otros mencionan anteriormente con éxito el puerto de cosas como el sistema de base de HOL Luz, pero son totalmente incapaces de controlar algo la escala de Hale el HOL la Luz de la prueba del Jordán Curva Teorema de, digamos Hale del Flyspeck Proyecto (mediante HOL Luz para comprobar su no-formal de la prueba de la Conjetura de Kepler).

  3. Algún tipo de limpio y trivial de la correspondencia de la teoría equivalente entre los sistemas es útil. Esto es mejor que la importación de instrucciones del lenguaje como un enorme expresiones, en términos de algunos de alta complejidad de la incrustación de una notación dentro de otra, que podrían aumentar significativamente la complejidad del sistema de verificación o hace uso humano difícil.

HOL Cero está dirigido principalmente a los "tontos" del programa de prueba comprobador de papel. La idea es que la importación y reproducción de pruebas que han sido exportados de otros HOL sistemas. He implementado una prueba de la exportación de mecanismo que, a diferencia de otros mecanismos, maneja con soltura las grandes pruebas tales como Hale Jordan Curva de la prueba y la (casi completo) Flyspeck Proyecto. Actualmente estoy trabajando en una prueba de la importación de mecanismo para HOL Cero. (Nota de que un ex la prueba de la importación de mecanismo que he desarrollado trabajado en una versión antigua de HOL Cero y transferido con éxito Hale Jordan Curva de la prueba y Harrison la prueba de la consistencia de la HOL Luz del núcleo.)

11voto

Marcio Aguiar Puntos 6715

Podría decirse que Metamath de Norman Megill http://metamath.org/ no es un verificador de pruebas convencional. Pero varios terceros han escrito programas cortos para verificar sus deducciones, comenzando con el programa mmverify de Ralph Lieven, que es 300 líneas de Python; seguramente lo suficientemente corto para que un espectador interesado pueda encuestarlo.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X