Cosa sappiamo dei programmi dimostrabilmente corretti?

La sempre crescente complessità dei programmi per computer e la posizione sempre più cruciale che i computer hanno nella nostra società mi lascia chiedermi perché non utilizziamo ancora collettivamente linguaggi di programmazione in cui è necessario fornire una prova formale del corretto funzionamento del codice.

Credo che il termine sia un "compilatore di certificazione" (l'ho trovato qui ): un compilatore che compila un linguaggio di programmazione in cui non solo è necessario scrivere il codice, ma anche specificare le specifiche del codice e dimostrare che il codice aderisce al specifica (o utilizzare un prover automatizzato per farlo).

Durante la ricerca in Internet, ho trovato solo progetti che utilizzano un linguaggio di programmazione molto semplice o progetti falliti che cercano di adattare i linguaggi di programmazione moderni. Questo mi porta alla mia domanda:

Esistono compilatori di certificazione che implementano un linguaggio di programmazione completo o è molto difficile / teoricamente impossibile?

Inoltre, devo ancora vedere qualsiasi classe di complessità che coinvolga programmi dimostrabili, come "la classe di tutte le lingue decidibile da una macchina di Turing per la quale esiste una prova che questa macchina di Turing si ferma", che chiamerò , come analogo a , l'insieme delle lingue ricorsive.$ProvableR$$R$

Vedo i vantaggi di studiare una tale classe di complessità: per esempio, per il problema di Halting è decidibile (ho anche ipotizzato che definito in modo ovvio sarebbe la più grande classe di lingue per cui è decidibile). Inoltre, dubito che escluderemmo qualsiasi programma praticamente utile: chi userebbe un programma quando non puoi provare che termina?$ProvableR$$ProvableRE$

Quindi la mia seconda domanda è:

Cosa sappiamo delle classi di complessità che richiedono che le loro lingue di contenimento abbiano determinate proprietà?

"Certificatore di compilazione" di solito significa qualcosa di leggermente diverso: significa che hai un compilatore che può dimostrare che il codice macchina che emette implementa correttamente la semantica di alto livello. Cioè, questa è una prova che non ci sono bug del compilatore. I programmi che le persone danno al compilatore possono ancora essere sbagliati, ma il compilatore genererà una versione corretta del codice macchina del programma sbagliato. La più grande storia di successo in questo senso è il compilatore verificato CompCert , che è un compilatore per un ampio sottoinsieme di C.

Il compilatore Compcert stesso è un programma con una prova di correttezza (eseguita in Coq), che garantisce che se genera codice per un programma, sarà corretto (rispetto alla semantica operativa di assembly & C utilizzata dai progettisti di CompCert). Lo sforzo di controllare automaticamente queste cose è piuttosto grande; in genere la prova di correttezza sarà compresa tra 1 e 100 volte la dimensione del programma che si sta verificando. Scrivere programmi e prove controllati automaticamente è una nuova abilità che devi imparare - non è matematica o programmazione come al solito, anche se dipende dalla capacità di fare entrambe le cose bene. Sembra che tu stia ricominciando da capo, come essere di nuovo un programmatore alle prime armi.

Non ci sono barriere teoriche speciali a questo, però. L'unica cosa su questa linea è il teorema di Blum Size che per qualsiasi lingua in cui tutti i programmi sono totali, puoi trovare un programma in una lingua ricorsiva generale che sarà almeno esponenzialmente più grande quando programmato nella lingua totale. Il modo per comprendere questo risultato è che una lingua totale codifica non solo un programma, ma anche una prova di terminazione. Quindi puoi avere programmi brevi con prove di terminazione lunghe. Tuttavia, questo non ha molta importanza in pratica, dato che scriveremo solo programmi con prove di terminazione gestibili.

EDIT: Dai Le ha chiesto qualche elaborazione dell'ultimo punto.

Questa è principalmente un'affermazione pragmatica, basata sul fatto che se riesci a capire perché un programma funziona, è improbabile che la ragione sia lunga milioni di pagine invarianti. (Gli invarianti più lunghi che ho usato sono lunghi poche pagine, e ragazzi fanno brontolare i recensori! Comprensibilmente, anche perché l'invariante è la ragione per cui il programma funziona spogliato di tutta la narrazione che aiuta le persone a capirlo.)

Ma ci sono anche alcune ragioni teoriche. Fondamentalmente, non conosciamo molti modi per inventare sistematicamente programmi le cui prove di correttezza sono molto lunghe. Il metodo principale è (1) prendere la logica in cui si dimostra la correttezza, (2) trovare una proprietà che non può essere direttamente espressa in quella logica (le prove di coerenza sono la fonte tipica) e (3) trovare un programma il cui la prova di correttezza si basa su una famiglia di conseguenze espressibili della proprietà indicibile. Poiché (2) è inesprimibile, ciò significa che la prova di ogni conseguenza esprimibile deve essere eseguita in modo indipendente, il che consente di far esplodere la dimensione della prova di correttezza. Come semplice esempio, si noti che nella logica del primo ordine con una relazione principale, non è possibile esprimere la relazione antenata.$k$$k$) è espressibile, per ogni fisso . Quindi, dando un programma che utilizza alcune proprietà degli antenati fino a una certa profondità (diciamo, 100), puoi forzare una prova di correttezza in FOL per contenere prove di tali proprietà centinaia di volte.$k$

La sofisticata interpretazione di questa materia si chiama "matematica inversa" ed è lo studio di quali assiomi sono necessari per dimostrare dati teoremi. Non ne so molto, ma se pubblichi una domanda sulla sua applicazione a CS, e sono sicuro che almeno Timothy Chow, e probabilmente molte altre persone, saranno in grado di dirti cose interessanti.

Penso che la risposta alla prima domanda sia che in genere è troppo lavoro con gli strumenti attuali. Per avere la sensazione, suggerisco di provare a dimostrare la correttezza di Bubble Sort in Coq (o se preferisci un po 'più di sfida, usa Quick Sort). Non penso che sia ragionevole aspettarsi che i programmatori scrivano programmi verificati purché dimostrare la correttezza di tali algoritmi di base sia così difficile e dispendioso in termini di tempo.

Questa domanda è simile alla domanda sul perché i matematici non scrivono prove formali verificabili da correttori di prove? Scrivere un programma con una prova formale di correttezza significa dimostrare un teorema matematico sul codice scritto e la risposta a quella domanda si applica anche alla tua domanda.

Ciò non significa che non si siano verificati casi di successo di programmi verificati. So che ci sono gruppi che stanno dimostrando la correttezza di sistemi come l'hypervisor di Microsoft . Un caso correlato è il compilatore C verificato di Microsoft . Ma in generale gli strumenti attuali richiedono molto sviluppo (compresi i loro aspetti SE e HCI) prima di diventare utili per programmatori generali (e matematici).

Per quanto riguarda l'ultimo paragrafo della risposta di Neel sulla crescita delle dimensioni del programma per le lingue con solo funzioni totali, in realtà è facile dimostrarlo ancora di più (se l'ho capito correttamente). È ragionevole aspettarsi che la sintassi di qualsiasi linguaggio di programmazione sia ce e l'insieme delle funzioni calcolabili totali non sia ce, quindi per qualsiasi linguaggio di programmazione in cui tutti i programmi sono totali esiste una funzione calcolabile totale che non può essere calcolata da nessun programma ( di qualsiasi dimensione) in quella lingua.

Per la seconda domanda, ho risposto a una domanda simile sul blog di Scott qualche tempo fa. Fondamentalmente se la classe di complessità ha una bella caratterizzazione ed è computabilmente rappresentabile (cioè è ce), allora possiamo dimostrare che alcune rappresentazioni dei problemi nella classe di complessità sono dimostrabili totalmente in teorie molto deboli corrispondenti alla classe di complessità. L'idea di base è che le funzioni dimostrabilmente totali della teoria contengano tutte le funzioni e un problema che sia A C $AC^0$$AC^0$-completo per la classe di complessità, quindi contiene tutti i problemi nella classe di complessità e può dimostrare la totalità di tali programmi. La relazione tra prove e teoria della complessità è studiata nella complessità delle prove, vedi il recente libro di SA Cook e P. Nguyen " Fondamenti logici della complessità della prova " se sei interessato. (È disponibile una bozza del 2008). Quindi la risposta di base è quella per molte classi "Provvidibilmente C = C".

Questo non è vero in generale poiché ci sono classi di complessità semantica che non hanno caratterizzazione sintattica, ad esempio funzioni calcolabili totali. Se per ricorsivo intendi le funzioni ricorsive totali, allora le due non sono uguali e l'insieme di funzioni calcolabili che sono dimostrabili totalmente in una teoria è ben studiato nella letteratura della teoria delle prove e sono chiamate funzioni dimostrabili totali della teoria. Ad esempio: le funzioni dimostrabilmente totali di sono funzioni ricorsive ϵ 0 (o equivalentemente funzioni nel sistema T di Godel ), le funzioni provabili totali di P A 2 sono funzioni nel sistema F di Girard , le funzioni provabili totali di$PA$$\epsilon_0$$T$$PA^2$$F$ sono funzioni ricorsive primitive, ....$I\Sigma_1$

Ma non mi sembra che ciò significhi molto nel contesto della verifica dei programmi, dal momento che ci sono anche programmi che calcolano estensivamente la stessa funzione, ma non possiamo dimostrare che i due programmi stiano calcolando la stessa funzione, vale a dire che i programmi sono estensivamente uguali ma non intenzionalmente. (Questo è simile alla Morning Star e alla Evening Star.) Inoltre è facile modificare un dato programma totalmente dimostrabile per ottenerne uno che la teoria non è in grado di dimostrare la sua totalità.

Penso che le due domande siano correlate. L'obiettivo è ottenere un programma verificato. Un programma verificato significa che il programma soddisfa una descrizione, che è una dichiarazione matematica. Un modo è scrivere un programma in un linguaggio di programmazione e quindi dimostrare le sue proprietà come se soddisfacesse la descrizione, che è la pratica più comune. Un'altra opzione è quella di provare a dimostrare l'affermazione matematica che descrive il problema usando mezzi limitati e quindi estrarre un programma verificato da esso. Ad esempio, se dimostriamo nella teoria corrispondente a che per ogni dato numero n c'è una sequenza di numeri primi che il loro prodotto è uguale a n , allora possiamo estrarre una $P$$n$$n$$P$algoritmo per la fattorizzazione dalla prova. (Ci sono anche ricercatori che cercano di automatizzare il primo approccio il più possibile, ma controllare interessanti proprietà non banali dei programmi è computazionalmente difficile e non può essere completamente verificato senza falsi positivi e negativi.)

Quello che ti stai chiedendo nella prima domanda è talvolta chiamato "compilatore di verifica", e qualche anno fa Tony Hoare lo ha offerto come una grande sfida per la ricerca informatica . In una certa misura questo esiste già ed è in uso attivo in strumenti come il prover del teorema di Coq , che organizza il problema attraverso la teoria dei tipi e il principio delle proposizioni come tipi (" Curry-Howard ").

EDIT: volevo solo aggiungere enfasi su "in una certa misura". Questo è ben lungi dall'essere un problema risolto, ma il successo di Coq fa sperare che non sia un sogno irrealizzabile.

Uno strumento che controlla se un programma è corretto a volte viene chiamato un programma di verifica. In questo contesto, "corretto" di solito significa due cose: che il programma non produce mai determinati output (pensa a errore di segmentazione, NullPointerException, ecc.) E che il programma concorda con una specifica.

Il codice e le specifiche possono essere d'accordo e comunque essere percepiti come errati. In un certo senso, chiedere agli sviluppatori di scrivere specifiche è come chiedere a due sviluppatori di risolvere il problema. Se le due implementazioni concordano, allora hai maggiore sicurezza che siano OK. In un altro senso, tuttavia, le specifiche sono migliori di una seconda implementazione. Poiché la specifica non deve essere efficiente o nemmeno eseguibile, può essere molto più concisa e quindi più difficile sbagliare.

Con questi avvertimenti in mente, ti consiglio di guardare il verificatore del programma Spec # .

Nel caso generale, è impossibile creare un algoritmo che confermi se un algoritmo è equivalente a una specifica. Questa è una prova informale:

Quasi tutti i linguaggi di programmazione sono completi di Turing. Pertanto, qualsiasi lingua decisa da una TM può essere decisa anche da un programma scritto in questa lingua.

$Equivalence/TM$

$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$è anche inaccettabile. Pertanto è possibile utilizzare un algoritmo indipendentemente dal fatto che due macchine non siano equivalenti, ma non si può essere sicuri che siano equivalenti o se non si è concesso abbastanza tempo al proprio algoritmo.

Tuttavia, questo è solo per il caso generale. È possibile decidere se le specifiche sono equivalenti o meno al programma, risolvendo una versione più rilassata del problema. Ad esempio, potresti esaminare solo un numero di input o dire che i due programmi sono equivalenti con qualche incertezza. Questo è il test del software.

Per il resto delle tue domande:

Nota: questa parte è stata modificata per chiarimenti. Si scopre che ho fatto l'errore che stavo cercando di evitare, scusa.

$TrueR$$TrueR \subseteq R$

$ProvableR = TrueR$$ProvableR \subset TrueR$$TrueR \subset ProvableR$$A \epsilon TrueR$$A$$A$$A \epsilon ProvableR$

Informalmente, questo può essere sintetizzato come: Non sai che una lingua è decidibile fino a quando non ne avrai provato. Quindi se in un sistema formale hai la consapevolezza che una lingua è decidibile, questa conoscenza può anche servire da prova per questo. Pertanto, non è possibile avere contemporaneamente la consapevolezza che una lingua è sia decidibile che non può essere dimostrata in tal modo, queste due affermazioni si escludono a vicenda.

$R$$ProvableR$$ProvableR \subset R$$R$

@Kaveh lo riassume al meglio: Provable significa sempre dimostrabile in qualche sistema / teoria e non coincide con la verità in generale.

Lo stesso vale per qualsiasi altra classe di complessità: per determinare l'appartenenza è necessario prima una prova. Questo è il motivo per cui credo che la tua seconda domanda sia troppo generica, poiché contiene non solo la teoria della complessità, ma anche la teoria del calcolo, a seconda della proprietà che desideri che il linguaggio abbia.

La seguente monografia classica studia quasi esattamente la tua seconda domanda:

Hartmanis, J. Calcoli fattibili e comprovabili proprietà di complessità , Serie di conferenze regionali CBMS-NSF in Matematica applicata, 30. Società per la matematica industriale e applicata (SIAM), Filadelfia, Pennsylvania, 1978.

$\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$$M_i$$T_i(n)$$M_i$$n$

$T(n) \geq n \log(n)$$g(n) \geq 1$$F$$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$

$T(n)$$F$$TIME[T(n)] \neq TIME[T(n)]$

$T(n) \geq n \log(n)$, $TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$.

For space, however, the situation is better controlled:

Theorem 6.9: (1) If $s(n) \geq n$ is space-constructible, then $SPACE[s(n)] = F$-$SPACE[s(n)]$.

(2) If $SPACE[S(n)]=F$-$SPACE[S(n)]$ ($S(n) \geq n$) then there is a space-constructible $s(n)$ such that $SPACE[S(n)]=SPACE[s(n)]$.

The question has to be posed correctly. For example, nobody ever wants to know whether an actual program would complete given infinite memory and some means of accessing it (maybe an operation to move the base address by some number). Turing's theorem is irrelevant to program correctness in any concrete sense and people who cite it as a barrier to program verification are confusing two quite different things. When engineers/programmers talk of program correctness they want to know about finite properties. This is also pretty much true for mathematicians who are interested in whether something is provable. Godel's letter http://vyodaiken.com/2009/08/28/godels-lost-letter/ explains this in some detail.

Namely, it would obviously mean that in spite of the undecidability of the Entscheidungsproblem, the mental work of a mathematician concerning Yes-or-No questions could be completely replaced by a machine. After all, one would simply have to choose the natural number n so large that when the machine does not deliver a result, it makes no sense to think more about the problem.

It may well be infeasible to examine the immense state set of a program executing on an actual computer and detect bad states, there is no theoretical reason why it can't be done. In fact, there has been a lot of progress in this field - for example see http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf (thanks to Neil Immerman for telling me about this)

A different and more difficult problem is specifying exactly what properties one wants a program to have in order to be correct.