Quel est l'objectif derrière l'interprétation abstraite dans les langages de programmation?

9

J'essaie maintenant de mieux comprendre ce qu'est "l'interprétation abstraite" dans les langages de programmation. J'ai trouvé un bon chapitre de livre qui explique l'idée d'étendre le domaine avec un élément le moins fixe, les quatre axiomes qui donnent un point fixe pour une fonction continue, etc. Je comprends ces détails techniques (bien que je ne sois pas tout à fait sûr de ce à quoi "l'interprétation abstraite" se réfère exactement dans tout ce schéma).

Ce dont je ne suis pas sûr, c'est ce qui motive l'utilisation de l'interprétation abstraite? S'agit-il simplement d'identifier des points fixes pour les fonctions calculables? La principale motivation vient-elle de la récursivité dans la plupart des langages de programmation?

Serait également heureux d'obtenir une vue d'ensemble de haut niveau qui va techniquement assez profondément pour quelqu'un qui a un diplôme en informatique. Je trouve la page Wikipedia plutôt troublante.

newToPL
la source
citer le livre plz. wikipedia abstract interpretation
vzn
Pourriez-vous s'il vous plaît mentionner le chapitre du livre que vous lisez?
Vijay D
Wikipédia n'est pas toujours le meilleur endroit pour un tutoriel sur des sujets plus techniques.
Vijay D
@Vijay et vzn C'est une chose que j'ai regardée: cs.berkeley.edu/~necula/cs263/handouts/AbramskiAI.pdf
newToPL

Réponses:

16

L'interprétation abstraite est un concept très général et selon qui vous demandez, vous recevrez différentes explications car les concepts polyvalents admettent de multiples perspectives. Le point de vue dans cette réponse est le mien et je ne suppose pas qu'il est général.

La dureté informatique comme motivation

Commençons par les problèmes de décision, dont les solutions ont une structure comme celle-ci:

problème de décision

Il y a souvent une limite inférieure NP-dure sur la procédure. La vérification des propriétés sémantiques des programmes est même indécidable. Que pouvons-nous faire?

Faisons deux observations. Premièrement, nous pouvons parfois résoudre des instances de problème spécifiques même si nous ne pouvons pas résoudre le problème général. Deuxièmement, des applications comme l'optimisation du compilateur tolèrent l'approximation dans la mesure où un compilateur qui élimine certaines mais pas toutes les sources d'inefficacité est utile. Pour préciser cette intuition, il faut répondre:

  1. Que signifie formellement résoudre certains cas, mais pas tous les cas problématiques?
  2. Quelle est une solution approximative à un problème de décision?

Idée d'interprétation abstraite 1: Modifier l'énoncé du problème

Pour moi, un aperçu majeur de l'interprétation abstraite est de changer la formulation du problème afin qu'au lieu de demander une réponse Oui / Non , nous demandions une réponse Oui / Non / Peut-être .

Oui Non peut-être

Par conséquent, chaque problème a une solution triviale à temps constant (sortie Peut-être ). Nous pouvons maintenant porter notre attention sur la dérivation d'une procédure qui ne produit pas toujours Peut-être . Pour revenir aux questions ci-dessus, une solution qui fonctionne pour certaines instances de problème est celle qui renvoie Peut-être sur des problèmes qu'elle ne peut pas résoudre. De plus, Peut - être est une approximation de Oui et Non parce que nous ne sommes pas certains de la réponse.

Cette idée ne se limite pas aux problèmes de décision. Considérez ces problèmes concernant les programmes.

  1. Quelles lignes de code du programme sont mortes (ne seront jamais exécutées)?
  2. Quelles variables du programme ont des valeurs constantes?
  3. Quelles affirmations du programme sont violées?

Dans toutes ces situations, nous pouvons passer d'une solution exacte à une solution approximative en considérant des solutions présentant une certaine incertitude.

  1. Qu'est-ce qu'un ensemble de lignes de code mort?
  2. Qu'est-ce qu'un ensemble de variables dans le programme qui ont des valeurs constantes?
  3. Qu'est-ce qu'un ensemble d'assertions dans le programme qui n'est pas violé?

Les ensembles produits n'ont pas besoin d'être les plus grands. Cette idée est extrêmement générale et s'applique aux problèmes qui ont peu à voir avec l'analyse de programme.

  1. mn[a,b]
  2. mnk
  3. Au lieu de demander les affectations satisfaisantes à une formule, nous pouvons demander un ensemble qui contient les affectations satisfaisantes.

Notez que nous avons non seulement changé le problème, mais nous l'avons également strictement généralisé car une solution au problème d'origine est toujours une solution au problème modifié. La grande question sans réponse est maintenant: comment pouvons-nous trouver une solution approximative?

Interprétation abstraite Idée 2: Caractérisation à point fixe des solutions originales

tsReach(s)stReach(s)

X={s}{w | v is in X and (v,w) is an edge}

nns

La caractérisation du point fixe est une décision de conception. Il existe de nombreuses caractérisations différentes d'un ensemble de solutions. Chacun d'eux peut avoir des avantages différents. Dans le cas des langages de programmation, nous avons plus de structure que de simplement traiter avec un graphe. Les équations à virgule fixe qui nous intéressent peuvent être définies par induction sur la structure du programme d'entrée. Cette idée n'est pas spécifique aux programmes. Lors de l'application d'une interprétation abstraite à des éléments d'un langage structuré tels qu'une grammaire, une formule logique, un programme, une expression arithmétique, etc., nous pouvons définir des points fixes par induction sur la structure d'un objet syntaxique.

En donnant cette caractérisation à virgule fixe, nous nous engageons sur un mode spécifique de calcul des solutions. Nous ne calculerons pas réellement ce point fixe car il est au moins aussi difficile que de résoudre le problème d'origine, ce qui nous amène à l'étape suivante.

Interprétation abstraite Idée 3: approximation du point fixe

FLGMMLML

LMFG

Vous pouvez trouver l'intuition derrière le transfert à virgule fixe perspicace. Nous pouvons considérer un point fixe comme la limite d'une chaîne d'éléments (éventuellement transfinis). Calculer des solutions approximatives revient à approximer cette limite, ce que nous pouvons faire en approximant des éléments de la chaîne.

stst

Idée d'interprétation abstraite 4: Algorithmes d'approximation à point fixe

Tout ce qui a été vu jusqu'à présent est un résultat d'existence mathématique. La dernière étape consiste à calculer l'approximation. Lorsque le réseau d'approximations est fini (ou si la condition de chaîne ascendante / descendante est remplie), nous pouvons utiliser une procédure itérative simple. Si le réseau est infini, une procédure itérative peut ne pas suffire, bien que le calcul d'un point fixe puisse toujours être décidable. Dans cette situation, de nombreuses techniques sont utilisées pour rapprocher davantage la solution ou pour passer à une solution exacte plus rapidement qu'un algorithme d'itération naïf. Dans le contexte du calcul d'une solution, vous entendez des termes comme élargissement , rétrécissement , itération de stratégie , accélération , etc.

Sommaire

À mon avis, l'interprétation abstraite fournit une base mathématique à la notion d'abstraction de la même manière que la logique mathématique fournit une base mathématique pour le raisonnement. Les solutions à de nombreux problèmes qui nous intéressent sont caractérisées comme des points fixes. Cette observation ne se limite pas aux problèmes de langage de programmation et même à l'informatique. Les solutions approximatives peuvent être caractérisées comme des approximations de points fixes et sont calculées avec des algorithmes spécialisés. Ces caractérisations et algorithmes exploiteront la structure de l'instance à problème. Dans le cas des programmes, cette structure est donnée par la syntaxe du langage.

Calculer des approximations de problèmes qui n'ont pas de métrique naturelle est un art constamment développé et raffiné par les praticiens. L'interprétation abstraite est une théorie mathématique pour la science derrière cet art.

Références Il existe plusieurs bons didacticiels sur l'interprétation abstraite que vous pouvez lire.

  1. Une introduction occasionnelle à l'interprétation abstraite , Patrick Cousot (Travail conjoint avec Radhia Cousot), Atelier sur la biologie des systèmes et les méthodes formelles (SBFM'12)
  2. Une introduction douce à la vérification formelle des systèmes informatiques par interprétation abstraite , Patrick et Radhia Cousot, Marktoberdorf Summer School 2010.
  3. Conférence 13: Abstraction Part I , Patrick Cousot, Interprétation abstraite, Cours MIT.
  4. Introduction to Abstract Interpretation , Samson Abramsky et Chris Hankin, Abstract Interpretation of Declarative Languages, 1987.
  5. Interprétation abstraite et application aux programmes logiques , Patrick et Radhia Cousot, 1992. Les deux premières sections présentent un aperçu général de haut niveau avec plusieurs exemples.
Vijay D
la source
7

Je suis d'accord qu'il est souvent difficile d'extraire le point principal de tous ces détails. (En fait, mon gros problème avec chaque traitement d'interprétation abstraite que j'ai vu est qu'ils présentent tellement de machines sans les motiver.)

Voici comment j'y pense:

L'interprétation abstraite exécute des programmes, approximativement, sur de grands ensembles d'entrées à la fois.

Cela ne couvre pas tout, mais ça résiste bien en général.

L'exemple canonique évalue des expressions arithmétiques pour déterminer le signe du résultat. Vous pouvez imaginer une machine hypothétique et infiniment rapide qui peut évaluer une expression sur chaque entrée positive et renvoyer l'ensemble des résultats. Si vous en aviez un, vous pourriez en principe déterminer des choses comme «ce programme renvoie des nombres positifs lorsqu'il reçoit des nombres positifs».

Mais bien sûr, vous n'avez pas vraiment cette machine. Vous êtes coincé dans la vraie vie, vous devez donc soit faire la même chose symboliquement , ce qui peut donner des réponses exactes parfois mais souvent échouer, ou approximativement , d'une manière qui renvoie toujours des réponses mais elles peuvent ne pas être exactes. C'est ce que fait l'interprétation abstraite.

{neg,zero,pos}{{...,2,1},{0},{1,2,...}}

add:pos×pospos

add:pos×posposadd(a,b)abpos×neg(poszeroneg)

Lorsque vous voulez prouver que votre interprétation abstraite est aussi serrée que possible, vous aurez besoin d'une connexion Galois pour formaliser cette correspondance. Le simple fait d'en avoir un garantit que, pour tout ensemble concret donné, un ensemble abstrait le plus serré existe.

IOW, ce que vous avez identifié comme la motivation de l'interprétation abstraite est vraiment la motivation du mécanisme requis pour faire de l'interprétation abstraite sur des langues équivalentes à Turing. La motivation réelle résume utilement le comportement des programmes en les exécutant sur plusieurs entrées à la fois.

Neil Toronto
la source