Qual è l'obiettivo dietro l'interpretazione astratta nei linguaggi di programmazione?

Ora sto cercando di capire meglio quale sia "l'interpretazione astratta" nei linguaggi di programmazione. Ho trovato un buon capitolo del libro che spiega l'idea di estendere il dominio con un elemento meno fisso, i quattro assiomi che danno un punto fisso per una funzione continua e così via. Comprendo questi dettagli tecnici (anche se non sono del tutto sicuro di cosa si riferisca esattamente a "interpretazione astratta" in tutto questo schema).

Ciò di cui non sono sicuro è ciò che motiva l'uso dell'interpretazione astratta? Identifica solo punti fissi per funzioni calcolabili? La motivazione principale deriva dalla ricorsione nella maggior parte dei linguaggi di programmazione?

Sarebbe anche felice di avere una panoramica di alto livello che va abbastanza tecnicamente abbastanza profonda per qualcuno che ha una laurea in informatica. Trovo la pagina di Wikipedia piuttosto inquietante.

L'interpretazione astratta è un concetto molto generale e, a seconda di chi chiedi, riceverai spiegazioni diverse perché concetti versatili ammettono molteplici prospettive. Il punto di vista in questa risposta è mio e non credo che sia generale.

Durezza computazionale come motivazione

Cominciamo con problemi di decisione, le cui soluzioni hanno una struttura come questa:

C'è spesso un limite inferiore NP-duro sulla procedura. Il controllo delle proprietà semantiche dei programmi è persino indecidibile. Cosa possiamo fare?

Facciamo due osservazioni. Innanzitutto, a volte possiamo risolvere istanze specifiche del problema anche se non possiamo risolvere il problema generale. In secondo luogo, applicazioni come l'ottimizzazione del compilatore tollerano l'approssimazione in quanto è utile un compilatore che elimini alcune ma non tutte le fonti di inefficienza. Per rendere precisa questa intuizione, dobbiamo rispondere:

1. Cosa significa formalmente risolvere alcune, ma non tutte le istanze problematiche?
2. Qual è una soluzione approssimativa a un problema decisionale?

Idea di interpretazione astratta 1: modifica la dichiarazione del problema

Per me, una visione fondamentale dell'interpretazione astratta è quella di cambiare la formulazione del problema in modo che invece di chiedere una risposta Sì / No , chiediamo una risposta Sì / No / Forse .

Di conseguenza, ogni problema ha una soluzione temporale banale e costante (output Forse ). Ora possiamo spostare la nostra attenzione sulla derivazione di una procedura che non sempre produce Forse . Per tornare alle domande precedenti, una soluzione che funziona per alcune istanze problematiche è quella che ritorna Forse su problemi che non può risolvere. Inoltre, Forse è un'approssimazione di Sì e No perché non siamo certi di quale sia la risposta.

Questa idea non è limitata ai problemi di decisione. Considera questi problemi relativi ai programmi.

1. Quali righe di codice nel programma sono morte (non verranno mai eseguite)?
2. Quali variabili nel programma hanno valori costanti?
3. Quali affermazioni nel programma sono state violate?

In tutte queste situazioni, possiamo passare da una soluzione esatta a una approssimativa considerando soluzioni che presentano alcune incertezze.

1. Che cos'è un insieme di righe di codice che è morto?
2. Che cos'è un insieme di variabili nel programma che hanno valori costanti?
3. Qual è una serie di affermazioni nel programma che non sono state violate?

I set prodotti non devono necessariamente essere i più grandi. Questa idea è estremamente generale e si applica a problemi che hanno poco a che fare con l'analisi del programma.

1. $m$$n$$[a,b]$
2. $m$$n$$k$
3. Invece di chiedere gli incarichi soddisfacenti a una formula, possiamo chiedere un set che contenga gli incarichi soddisfacenti.

Si noti che non solo abbiamo modificato il problema, ma lo abbiamo anche rigorosamente generalizzato perché una soluzione al problema originale è ancora una soluzione al problema modificato. La grande domanda senza risposta ora è: come possiamo trovare una soluzione approssimativa?

Idea interpretativa astratta 2: caratterizzazione a virgola fissa delle soluzioni originali

$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 caratterizzazione a virgola fissa è una decisione di progettazione. Esistono molte diverse caratterizzazioni di un insieme di soluzioni. Ognuno di essi può avere diversi vantaggi. Nel caso dei linguaggi di programmazione, abbiamo più struttura che limitarci a gestire un grafico. Le equazioni in punti fissi a cui teniamo possono essere definite mediante induzione sulla struttura del programma di input. Questa idea non è specifica per i programmi. Quando si applica l'interpretazione astratta ad elementi di un linguaggio strutturato come grammatica, formula logica, programma, espressione aritmetica, ecc., Possiamo definire punti fissi mediante induzione sulla struttura di un oggetto sintattico.

Dando questa caratterizzazione a virgola fissa, ci stiamo impegnando per un modo specifico di soluzioni informatiche. In realtà non calcoleremo questo punto fisso perché è difficile almeno quanto risolvere il problema originale, il che ci porta al passaggio successivo.

Idea di interpretazione astratta 3: approssimazione a punto fisso

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

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

L'intuizione alla base del trasferimento a virgola fissa potrebbe essere penetrante. Possiamo pensare a un punto fisso come al limite di una catena (possibilmente transfinita) di elementi. Il calcolo di soluzioni approssimative equivale ad approssimare questo limite, cosa che possiamo fare approssimando elementi della catena.

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

Idea di interpretazione astratta 4: algoritmi di approssimazione a punto fisso

Tutto ciò che è stato visto finora è stato un risultato di esistenza matematica. Il passaggio finale consiste nel calcolare l'approssimazione. Quando il reticolo delle approssimazioni è finito (o se la condizione della catena ascendente / discendente è soddisfatta), possiamo usare una semplice procedura iterativa. Se il reticolo è infinito, una procedura iterativa potrebbe non essere sufficiente, sebbene il calcolo di un punto fisso possa essere comunque decidibile. In questa situazione, vengono utilizzate molte tecniche per approssimare ulteriormente la soluzione o per passare a una soluzione esatta più velocemente di un algoritmo di iterazione ingenuo. Nel contesto del calcolo di una soluzione, senti termini come ampliamento , restringimento , iterazione della strategia , accelerazione , ecc.

Sommario

A mio avviso, l'interpretazione astratta fornisce una base matematica per la nozione di astrazione nello stesso modo in cui la logica matematica fornisce una base matematica per il ragionamento. Le soluzioni a molti problemi a cui teniamo hanno caratterizzazioni come punti fissi. Questa osservazione non si limita ai problemi del linguaggio di programmazione e nemmeno all'informatica. Le soluzioni approssimative possono essere caratterizzate come approssimazioni di punti fissi e sono calcolate con algoritmi specializzati. Queste caratterizzazioni e algoritmi sfrutteranno la struttura dell'istanza del problema. Nel caso dei programmi, questa struttura è data dalla sintassi della lingua.

Calcolare approssimazioni a problemi che non hanno una metrica naturale è un'arte costantemente sviluppata e raffinata dai professionisti. L'interpretazione astratta è una teoria matematica per la scienza dietro questa arte.

Riferimenti Ci sono molti buoni tutorial sull'interpretazione astratta che puoi leggere.

1. Un'introduzione casuale a Abstract Interpretation , Patrick Cousot (lavoro congiunto con Radhia Cousot), Workshop on Systems Biology and Formals Methods (SBFM'12)
2. Una dolce introduzione alla verifica formale dei sistemi informatici mediante interpretazione astratta , Patrick e Radhia Cousot, Marktoberdorf Summer School 2010.
3. Lezione 13: Astrazione Parte I , Patrick Cousot, Interpretazione astratta, Corso MIT.
4. Introduzione all'interpretazione astratta , Samson Abramsky e Chris Hankin, Interpretazione astratta delle lingue dichiarative, 1987.
5. Interpretazione astratta e applicazione ai programmi logici , Patrick e Radhia Cousot, 1992. Le prime due sezioni hanno una panoramica generale di alto livello con diversi esempi.

Concordo sul fatto che spesso è difficile estrarre il punto principale da tutti questi dettagli. (In effetti, il mio grosso problema con ogni trattamento di interpretazione astratta che ho visto è che presentano così tanti macchinari senza motivarli.)

Ecco come ci penso:

L'interpretazione astratta sta eseguendo i programmi, approssimativamente, su grandi insiemi di input contemporaneamente.

Questo non copre tutto, ma regge bene in generale.

L'esempio canonico sta valutando le espressioni aritmetiche per determinare il segno del risultato. Puoi immaginare una macchina ipotetica, infinitamente veloce, in grado di valutare un'espressione su ogni input positivo e restituire l'insieme dei risultati. Se ne avessi uno di questi, in linea di principio potresti determinare cose come "questo programma restituisce numeri positivi quando ti vengono dati numeri positivi".

Ma ovviamente non hai quella macchina. Sei bloccato nella vita reale, quindi devi fare la stessa cosa simbolicamente , il che può dare risposte esatte a volte ma spesso fallisce, o approssimativamente , in un modo che restituisce sempre risposte ma potrebbero non essere esatte. Quest'ultimo è ciò che fa l'interpretazione astratta.

$\{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$

Quando vuoi dimostrare che la tua interpretazione astratta è il più stretta possibile, vorrai una connessione Galois per formalizzare questa corrispondenza. Il solo fatto di averne uno assicura che, per ogni dato set concreto, esista un insieme astratto più stretto.

$\bot$

IOW, ciò che hai identificato come motivazione per l'interpretazione astratta è in realtà la motivazione per il meccanismo necessario per fare l'interpretazione astratta su linguaggi equivalenti a Turing. La motivazione effettiva sta utilmente riassumendo il comportamento dei programmi eseguendoli su più input contemporaneamente.