¿Por qué la prueba de los autores el uso de lenguaje natural, frases para escribir pruebas?

Question

No he leído muchas pruebas. La mayoría de los que he leído, que he leído en mi primer año de las pruebas de los libros de texto. Sin embargo, su primer capítulo expatiates sobre el correcto uso del inglés en las pruebas matemáticas, por lo que sospecho que la mayoría de la prueba de los autores no usar tanto el inglés (u otro lenguaje natural) y la prueba formal de sistemas para la escritura de sus pruebas. Sin embargo, no me puedo imaginar muchas circunstancias donde la notación matemática y una prueba formal del sistema no suficiente para transmitir el autor pertinente de los pensamientos.

Sospecho que la prueba de los autores tienen buenas razones para hacer uso del inglés y expresiones formales en sus pruebas, pero no puedo pensar en cuáles son esas razones. ¿Por qué la prueba de los autores utilizan el inglés y expresiones formales para escribir pruebas? Hay reglas estilísticas (o pautas) que el estado de cómo, y en qué partes de la prueba, un autor debe y no debe utilizar el inglés?

Answer 1

Ordinaria de la prueba matemática¹ es una pieza de prosa expositiva. Su propósito es convencer al lector de que el teorema es verdadero. Obviamente debe ser matemáticamente correcta y lógicamente el sonido, pero también debe ser claro y fácil de seguir. Escrito en (párrafos) de las oraciones y el uso de palabras para el tejido conectivo que da un mapa de ruta para la lógica del argumento, en general, hace que la prosa más legible. Por todos los medios el uso de símbolos cuando sean apropiados: la fórmula cuadrática es mucho más fácil seguir cuando se expresa simbólicamente que cuando escriben en palabras! Pero no caigas en la trampa de pensar que el más simbolismo que utiliza, el más profesional de su argumento se ve.

Por un real (y bastante simple) ejemplo, usted podría mirar a esta pregunta y mi respuesta a la misma.

¹ La palabra prueba también se utiliza para el objeto formal de la lógica matemática. Tratando de seguir una prueba formal es más bien como tratando de averiguar lo que un programa de ordenador examinando el lenguaje de la máquina.

Answer 2

La siguiente es una puramente formal de la prueba de la irracionalidad de $\sqrt 2$, formalizado mediante el HOL teorema de armario de Coq. Es equivalente a la humana-idioma de la prueba:

Si hay un $n$ que $p$, $n^2 = 2p^2$, entonces vamos a tomar el menos positivo, $n$ y el correspondiente positivo de $p$, en este caso tenemos (i) $(2p-n)^2=2(n-p)^2$ y (ii) $(2p-n) < n$, por lo tanto una contradicción.

Su pregunta ahora debe responder de sí mismo.

Require Import ZArith ZArithRing Omega Zwf.
Open Scope Z_scope.

Lemma Zabs_square : forall x, Zabs x ^ 2 = x ^ 2.
intros; case (Zabs_dec x); intros Heq; ring [Heq].
Qed.

Lemma Zabs_st_pos : forall x, x <> 0 -> 0 < Zabs x.
intros; assert (H':= Zabs_pos x); case (Zabs_dec x); intros; omega.
Qed.
Hint Resolve Zabs_pos Zabs_square Zabs_st_pos.

Theorem integer_statement :  ~exists n, exists p, n ^2 = 2* p^2 /\ n <> 0.
intros [n [p [He Hz]]]; pose (q := Zabs n); pose (r :=Zabs p).
assert (H : (0 < q /\ 0 <= r) /\ q ^2 = 2* r ^2).
  assert (F : 0 <= Zabs n /\ 0 <= Zabs p /\ Zabs p ^ 2 = p ^ 2 /\
            Zabs n ^ 2 = n ^ 2) by auto.
  destruct F as [H1 [H2 [H3 H4]]];  unfold q, r; split; auto; ring [H3 H4 He].
generalize r H; elim q using (well_founded_ind (Zwf_well_founded 0)); clear.
assert (fact_sq : forall x, x^2=x*x) by (intros; ring).
intros n IHn p [[Hn Hp] Heq].
assert (Hmain_eq: (2*p-n)^2 = 2*(n-p)^2) by ring [Heq].
assert (Hs: 0 < n^2) by (rewrite fact_sq; apply Zmult_lt_0_compat; auto).
assert (Hpn : p < n).
  apply Znot_ge_lt; intros Habs.
  assert (2*p^2 <= p^2).
    rewrite <- Heq; repeat rewrite fact_sq; 
    apply Zmult_le_compat; auto with zarith.
  omega.
assert (Hn2p: n < 2*p).
  elim (Zle_or_lt (2*p) n); auto; intros Habs'.
  assert (2*n^2 <= n^2).
    replace (2*n^2) with ((2*p)^2) by ring [Heq].
    repeat rewrite fact_sq; apply Zmult_le_compat; auto with zarith.
  omega.
assert (Hzwf : Zwf 0 (2*p-n) n) by (unfold Zwf; omega).
apply (IHn (2*p-n) Hzwf (n-p)); omega.
Qed.

Answer 3

Usted escribió

I can't imagine many circumstances where mathematical 
notation and a formal proof system wouldn't suffice to 
convey the author's pertinent thoughts. 

El caso es, pruebas matemáticas contienen gran cantidad de mano saludando argumento como referencia a la simetría o a la constante de cambio de variables. Los editores están deseosos de aceptar estos argumentos, pero teorema de provers no lo son. La formalización de tales argumentos es un área activa de investigación. Un ejemplo es el nominal de los conjuntos que se desarrolla una completa teoría algebraica de los mencionados cambio de variables. Tiene una aplicación en la que Isabelle teorema de armario de llamada Nominal Isabelle y se requiere un poco de trabajo a utilizar.

Existe una vasta literatura sobre lo que la prueba es, un buen lugar para comenzar es el papel de los Procesos Sociales y las Pruebas de los Teoremas y Programas.

Answer 4

Por qué? Debido a que esta ha sido la forma más eficaz de comunicarse con pruebas, como se muestra por las respuestas de Brian M Scott y Bancas.

Pero que no siempre puede ser así.

Teoremas matemáticos en las revistas científicas, a menudo llegan a decenas o cientos de páginas, por ejemplo, la famosa prueba de Wiles del Teorema, o la Clasificación de Todos los Finitos Simples Grupos (en sí mismo un proyecto en curso con los principales teoremas todavía se está codificada en la prueba de damas). Como el conocimiento se expande, suceden dos cosas: o nuevos campos de la materia, no el anillo conmutativo con invertible multiplicación) son explorados, o la complejidad de las "tecnologías" aumenta. Una prueba de frecuencia, ahora llega la complejidad de un tamaño medio de la clase de la biblioteca; algo parecido a decenas de miles de líneas de alto nivel de código de computadora. En los primeros días de alto nivel de lenguaje de programación, los programadores de corte y prueba sus propios códigos, que, una vez "probado" (por el número suficiente de pruebas) rara vez se disected de nuevo por otras personas, a quienes dichos códigos fueron a menudo incomprensible. Procedimientos y paradigmas evolucionado para manejar más y más software de la complejidad: programación estructurada defendida por tales trabajadores como Niklaus Wirth; más tarde programación orientada a objetos y las diversas teorías de gestión de la calidad del software de control. Una bien documentada pieza de código es muy parecido a un lenguaje natural prueba matemática de muchas maneras: en sus comentarios, el diseño y la estructura debe mostrar al lector exactamente cómo se hace lo que dice hacer y el real declaraciones de alto nivel proporcionan por sí mismas la receta para ser codificada por el compilador.

La complejidad que puede ser manejado en estos nuevos paradigmas es sorprendente: mientras que el desarrollo de Fortran bajo el liderazgo de John Backus (de la Backhus-Naur metalenguaje de la fama) tomó 18 años del equipo, estudiantes de informática ahora escribir su propio compilador como a finales de pregrado o principios de pregrado ejercicios y, con un poco de lectura, los principios de compilador de trabajo son fácilmente entendido por casi cualquier persona con formación (véase, por ejemplo, Appel, Andrew W. (1998),"Moderno Compilador de Implementación en C", Cambridge University Press, Nueva York, Cambridge. ISBN 0-521-58390-X. Ver esp. Capítulo 2.).

Asimismo, la Matemática ha desarrollado su propia complejidad de manejo de paradigmas. Dos grandes ejemplos de esto son Noether la noción de Begriffliche Mathematik, que llevó a gran parte de la moderna enfoque abstracto, estructuras algebraicas y de la categoría de teoría, aunque la lógica, el lenguaje matemático, en sí mismo, también desempeña este papel de dar a una escala muy grande, vista cenital de un problema matemático: tiene una gran semejanza con varios software de modelado de metalenguajes, en la medida en que éstas últimas están dirigidas a la identificación y el estudio de morfismos entre los objetos dentro de las categorías: en el diseño de software más a menudo se describe como algo parecido a la definición formal de "casos de uso" o "procesos" que incluye la "colaboración" entre "actores" o "agentes". El lenguaje de la categoría de la teoría es aún fuertemente prestado en el diseño de software y la arquitectura.

Pero puede ser que el lenguaje natural en las matemáticas, o, de manera equivalente, los lenguajes de alto nivel y lenguajes de modelado en el diseño de software es llegar a los límites de su capacidad. Sugestivamente, la prueba formal de las damas ahora están encontrando su camino en la prueba de la crítica de los sistemas de software. Por ejemplo:

Gerwin Klein, Kevin Elphinstone, Gernot Heiser, junio de Andronick, David Gallo, Felipe Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish1, Thomas Sewell, Harvey Tuch, Simon Winwood, "seL4: Formal Veri cación de un Núcleo del sistema operativo" en la 22º Simposio de ACM en los Sistemas Operativos de Principios (SOSP) (2009)

describe en detalle la prueba de la veracidad de la aplicación (es decir, la igualdad de software, ya que el comportamiento de una especificación formal) en el teorema de armario de Isabelle. Una cosa es segura: formal del teorema de provers se convertirá en más y más importante a medida que el softare de sistemas y pruebas matemáticas, elevarse por encima de la complejidad que puede ser manejado por un ser humano. Uno de los comentarios, también alude a otros como los proyectos:

...por otro lado, si queremos muy alta garantía de la corrección necesitamos utilizar la máquina-verificable pruebas en la programación. Por ejemplo, la totalidad de Windows hipervisor Hyper-V se ha comprobado que el ser libre de ciertos tipos de errores debido a que es una críticos para la seguridad de los componentes. De usuario (usr)

Sólo para cerrar: el uso de un software teorema de armario para "demostrar" la solidez de software puede parecer cuestión de la mendicidad, pero no es verdad. El núcleo del teorema de armario es simplemente un analizador que las pruebas de la conformidad de la prueba pasos con definiciones formales de las reglas de inferencia. Si usted lee el Appel de referencia "Moderno Compilador de Aplicación" que he citado anteriormente, se puede llegar a entender que un analizador en realidad es un programa muy simple de tomar en más de un par de páginas de alto nivel de código y cuyo trabajo ha sido ampliamente descrito en lenguaje de alto nivel y bien entendido por miles de revisores. Por supuesto, algo así como Isabelle es mucho más que esto, pero no importa si hay errores en la prueba de las herramientas de construcción en Isabelle: mientras construido a prueba de sonido (cumple con la correcta reglas de inferencia), pasará la prueba del comprobador. Si un error se levantó en la prueba de las herramientas de construcción que llevó a una incorrecta de la prueba, que sería recogido en la última comprobación de fase.