¿Cuál es el objetivo detrás de la interpretación abstracta en lenguajes de programación?

Ahora estoy tratando de entender mejor qué es la "interpretación abstracta" en los lenguajes de programación. Encontré un buen capítulo de libro que explica la idea de extender el dominio con un elemento menos fijo, los cuatro axiomas que producen un punto fijo para una función continua, y así sucesivamente. Entiendo estos detalles técnicos (aunque no estoy muy seguro de a qué se refiere exactamente "interpretación abstracta" en todo este esquema).

De lo que no estoy seguro es qué motiva el uso de la interpretación abstracta. ¿Es solo identificar puntos fijos para funciones computables? ¿La principal motivación proviene de tener recurrencia en la mayoría de los lenguajes de programación?

También me complacería obtener una visión general de alto nivel que sea lo suficientemente técnica para alguien que tenga un título en ciencias de la computación. La página de Wikipedia me parece bastante inquietante.

La interpretación abstracta es un concepto muy general y, dependiendo de a quién le pregunte, recibirá diferentes explicaciones porque los conceptos versátiles admiten múltiples perspectivas. La opinión en esta respuesta es mía y no asumiría que es general.

La dureza computacional como motivación.

Comencemos con los problemas de decisión, cuyas soluciones tienen una estructura como esta:

A menudo hay un límite inferior NP-duro en el procedimiento. Comprobar las propiedades semánticas de los programas es incluso indecidible. ¿Qué podemos hacer?

Hagamos dos observaciones. Primero, a veces podemos resolver casos específicos de problemas, incluso si no podemos resolver el problema general. En segundo lugar, las aplicaciones como la optimización del compilador toleran la aproximación en que un compilador que elimina algunas pero no todas las fuentes de ineficiencia es útil. Para hacer esta intuición precisa, debemos responder:

1. ¿Qué significa formalmente resolver algunas, pero no todas las instancias problemáticas?
2. ¿Cuál es una solución aproximada a un problema de decisión?

Idea de interpretación abstracta 1: Cambiar la declaración del problema

Para mí, una idea importante de la interpretación abstracta es cambiar la formulación del problema para que, en lugar de pedir una respuesta Sí / No , solicitemos una respuesta Sí / No / Quizás .

Como consecuencia, cada problema tiene una solución trivial y de tiempo constante (salida Quizás ). Ahora podemos cambiar nuestra atención a derivar un procedimiento que no siempre produce Quizás . Para volver a las preguntas anteriores, una solución que funciona para algunas instancias problemáticas es la que devuelve Quizás en problemas que no puede resolver. Además, Quizás es una aproximación de Sí y No porque no estamos seguros de cuál es la respuesta.

Esta idea no está restringida a problemas de decisión. Considere estos problemas relacionados con los programas.

1. ¿Qué líneas de código en el programa están muertas (nunca se ejecutarán)?
2. ¿Qué variables en el programa tienen valores constantes?
3. ¿Qué afirmaciones en el programa son violadas?

En todas estas situaciones, podemos pasar de una solución exacta a una aproximada al considerar soluciones que tienen cierta incertidumbre.

1. ¿Qué es un conjunto de líneas de código que está muerto?
2. ¿Qué es un conjunto de variables en el programa que tienen valores constantes?
3. ¿Qué es un conjunto de afirmaciones en el programa que no se viola?

Los sets producidos no necesitan ser los más grandes. Esta idea es extremadamente general y se aplica a problemas que tienen poco que ver con el análisis del programa.

1. $m$$n$$[a,b]$
2. $m$$n$$k$
3. En lugar de pedir las asignaciones satisfactorias a una fórmula, podemos pedir un conjunto que contenga las asignaciones satisfactorias.

Tenga en cuenta que no solo hemos cambiado el problema, sino que también lo hemos generalizado estrictamente porque una solución al problema original sigue siendo una solución al problema modificado. La gran pregunta sin respuesta ahora es: ¿Cómo podemos encontrar una solución aproximada?

Idea de interpretación abstracta 2: Caracterización de punto fijo de las soluciones originales

$t$$s$$\mathit{Reach}(s)$$s$$t$$\mathit{Reach}(s)$

$X = \{s\} \cup \{ w ~|~ v \text{ is in } X \text{ and } (v,w) \text{ is an edge}\}$

$n$$n$$s$

La caracterización de punto fijo es una decisión de diseño. Hay muchas caracterizaciones diferentes de un conjunto de soluciones. Cada uno de ellos puede tener diferentes ventajas. En el caso de los lenguajes de programación, tenemos más estructura que solo tratar con un gráfico. Las ecuaciones de punto fijo que nos interesan pueden definirse por inducción en la estructura del programa de entrada. Esta idea no es específica de los programas. Al aplicar la interpretación abstracta a elementos de un lenguaje estructurado, como una gramática, una fórmula lógica, un programa, una expresión aritmética, etc., podemos definir puntos fijos por inducción en la estructura de algún objeto sintáctico.

Al dar esta caracterización de punto fijo, nos comprometemos a una forma específica de soluciones informáticas. En realidad, no calcularemos este punto fijo porque es al menos tan difícil como resolver el problema original, lo que nos lleva al siguiente paso.

Idea de interpretación abstracta 3: aproximación de punto fijo

$F$$L$$G$$M$$M$$L$$M$$L$

$L$$M$$F$$G$

Puede encontrar perspicaz la intuición detrás de la transferencia de punto fijo. Podemos pensar en un punto fijo como el límite de una cadena de elementos (posiblemente transfinita). Calcular soluciones aproximadas equivale a aproximar este límite, lo que podemos hacer al aproximar elementos de la cadena.

$s$$t$$s$$t$

Idea de interpretación abstracta 4: Algoritmos de aproximación de punto fijo

Todo lo visto hasta ahora ha sido un resultado de existencia matemática. El último paso es calcular la aproximación. Cuando la red de aproximaciones es finita (o si se cumple la condición de cadena ascendente / descendente), podemos usar un procedimiento iterativo simple. Si la red es infinita, un procedimiento iterativo puede no ser suficiente, aunque calcular un punto fijo aún puede ser decidible. En esta situación, se utilizan muchas técnicas para aproximar aún más la solución, o para saltar a una solución exacta más rápido que un algoritmo de iteración ingenuo. En el contexto de la computación de una solución, escuchas términos como ensanchamiento , estrechamiento , iteración de estrategia , aceleración , etc.

Resumen

En mi opinión, la interpretación abstracta proporciona una base matemática para la noción de abstracción de la misma manera que la lógica matemática proporciona una base matemática para el razonamiento. Las soluciones a muchos problemas que nos interesan tienen caracterizaciones como puntos fijos. Esta observación no se limita a los problemas del lenguaje de programación e incluso a la informática. Las soluciones aproximadas pueden caracterizarse como aproximaciones de puntos fijos y se calculan con algoritmos especializados. Estas caracterizaciones y algoritmos explotarán la estructura de la instancia del problema. En el caso de los programas, esta estructura viene dada por la sintaxis del lenguaje.

Calcular aproximaciones a problemas que no tienen una métrica natural es un arte constantemente desarrollado y refinado por los profesionales. La interpretación abstracta es una teoría matemática para la ciencia detrás de este arte.

Referencias Hay varios buenos tutoriales sobre interpretación abstracta que puede leer.

1. Una introducción informal a la interpretación abstracta , Patrick Cousot (trabajo conjunto con Radhia Cousot), Taller sobre biología de sistemas y métodos formales (SBFM'12)
2. Una introducción suave a la verificación formal de los sistemas informáticos por interpretación abstracta , Patrick y Radhia Cousot, Marktoberdorf Summer School 2010.
3. Lección 13: Abstracción Parte I , Patrick Cousot, Interpretación abstracta, Curso MIT.
4. Introducción a la interpretación abstracta , Samson Abramsky y Chris Hankin, Interpretación abstracta de lenguajes declarativos, 1987.
5. Interpretación abstracta y aplicación a programas lógicos , Patrick y Radhia Cousot, 1992. Las dos primeras secciones tienen una visión general de alto nivel con varios ejemplos.

Estoy de acuerdo en que a menudo es difícil extraer el punto principal de todos esos detalles. (De hecho, mi gran problema con cada tratamiento de interpretación abstracta que he visto es que presentan tanta maquinaria sin motivarla).

Así es como lo pienso:

La interpretación abstracta está ejecutando programas, aproximadamente, en grandes conjuntos de entradas, todo a la vez.

Esto no cubre todo, pero se mantiene bien en general.

El ejemplo canónico es evaluar expresiones aritméticas para determinar el signo del resultado. Puede imaginar una máquina hipotética e infinitamente rápida que puede evaluar una expresión en cada entrada positiva y devolver el conjunto de resultados. Si tuviera uno de esos, en principio podría determinar cosas como "este programa devuelve números positivos cuando se le dan números positivos".

Pero, por supuesto, en realidad no tienes esa máquina. Estás atrapado en la vida real, por lo que debes hacer lo mismo simbólicamente , lo que puede dar respuestas exactas a veces, pero a menudo fallan, o aproximadamente , de una manera que siempre devuelve respuestas, pero pueden no ser exactas. Esto último es lo que hace la interpretación abstracta.

$\{neg,zero,pos\}$$\{\{...,-2,-1\},\{0\},\{1,2,...\}\}$

$add : pos \times pos \to pos$

$add : pos \times pos \to pos$$add(a,b)$$a$$b$$pos \times neg \to (pos \sqcup zero \sqcup neg)$$\sqcup$

$\sqcap$$\sqsubseteq$

Cuando quiera probar que su interpretación abstracta es lo más ajustada posible, querrá una conexión de Galois para formalizar esta correspondencia. Solo tener uno garantiza que, para cualquier conjunto concreto, exista un conjunto abstracto más ajustado.

$\bot$

IOW, lo que ha identificado como la motivación para la interpretación abstracta es realmente la motivación para la maquinaria requerida para hacer la interpretación abstracta en lenguajes equivalentes a Turing. La motivación real es resumir útilmente el comportamiento de los programas ejecutándolos en muchas entradas a la vez.