Come gestire le matrici durante le prove di correttezza in stile Hoare

11

Nella discussione intorno a questa domanda , Gilles menziona correttamente che qualsiasi prova di correttezza di un algoritmo che utilizza array deve dimostrare che non vi sono accessi fuori campo fuori campo; a seconda del modello di runtime, ciò provocherebbe un errore di runtime o l'accesso a elementi non array.

Una tecnica comune per eseguire tali prove di correttezza (almeno negli studi universitari e probabilmente nella verifica automatizzata) è utilizzando la logica Hoare . Non sono a conoscenza del fatto che l'insieme standard di regole contenga qualsiasi elemento relativo alle matrici; sembrano essere limitati alle variabili monadiche.

Posso immaginare di aggiungere assiomi del modulo

$\qquad \displaystyle \frac{}{\{0 \leq i \lt A.\mathrm{length} \land {P[A[i]/E]} \}\ A[i] := E;\ \{P\}}$

Tuttavia, non mi è chiaro come si dovrebbe fare con un accesso agli array sul lato destro della strada, vale a dire se è parte di un complesso di espressione in qualche dichiarazione . $E$ $x := E$

Come si possono modellare gli accessi agli array nella logica Hoare in modo che l'assenza di accessi non validi possa e debba essere dimostrata per la correttezza del programma?

Le risposte possono supporre che non consentiamo l'uso di elementi dell'array in istruzioni diverse da o come parte di alcune in poiché ciò non limita l'espressività; possiamo sempre assegnare a una variabile temporanea il valore desiderato, ovvero scrivere anziché . $A[i] := E$ $E$ $x := E$ $t := A[i];\ \mathtt{if} ( t > 0 ) \dots$ $\mathtt{if} ( A[i] > 0 )\dots$

— Raffaello
fonte

8

Il tuo assioma non è in realtà un assioma, manca di ipotesi. Presentazioni semplici della logica Hoare manipolano le formule della forma dove e sono formule logiche e è un comando. È necessario assicurarsi che sia ben formato . In linguaggi semplici come quelli spesso usati per una prima introduzione alla logica di Hoare, la buona formazione è sintattica: in genere si tratta di verificare che $\{P\} C \{P'\}$ $P$ $P'$ $C$ $C$ $C$ è conforme a una grammatica senza contesto e, possibilmente, che le variabili libere si trovano all'interno di un insieme consentito. Se il linguaggio include costrutti che hanno una correttezza semantica, come gli accessi agli elementi dell'array, è necessario aggiungere ipotesi per esprimere questa correttezza semantica.

Formalmente, puoi aggiungere giudizi per esprimere la correzione di espressioni e comandi. Se le espressioni non hanno effetti collaterali, non hanno bisogno di postcondizioni, solo di precondizioni. Ad esempio, puoi scrivere regole di buona formazione come e consenti solo espressioni ben nei comandi:

\frac{{P} E wf}{{P \land 0 \leq E < l e n g t h (UN)} UN [E] wf} \frac{{P} E_{1} wf {P} E_{2} wf}{{P} E_{1} + E_{2} wf}

$\dfrac{\{P\} \;\; E \text{ wf}} {\{P \wedge 0 \le E < \mathrm{length}(A)\} \;\; A[E] \text{ wf}} \qquad \dfrac{\{P\} \;\; E_1 \text{ wf} \qquad \{P\} \;\; E_2 \text{ wf}} {\{P\} \;\; E_1 + E_2 \text{ wf}}$

\frac{{P [X \leftarrow E]} E wf}{{P [X \leftarrow E]} X : = E {P}}

$\dfrac{\{P[x\leftarrow E]\} \;\; E \text{ wf}} {\{P[x\leftarrow E]\} \;\; x := E \{P\}}$

Un approccio diverso consiste nel considerare tutte le espressioni come ben formate, ma fare in modo che qualsiasi espressione che coinvolge un calcolo mal formato abbia un valore speciale . Nelle lingue con controllo dei limiti di runtime, significa "questo programma ha sollevato un'eccezione fatale". Tieni quindi traccia se un programma ha commesso un un predicato logico ; un programma è valido solo se si può dimostrare che la sua postcondizione implica . $\mathbf{error}$ $\mathbf{error}$ $\mathbf{Error}$ $\neg\mathbf{Error}$

\frac{}{{P [x \leftarrow E]} x := E {P \lor E r r o r}} \frac{P [X \leftarrow E] ⟹ E ↛ e r r o r}{{P [X \leftarrow E]} X : = E {P}}

$\dfrac{} {\{P[x\leftarrow E]\} \;\; x := E \;\; \{P \vee \mathbf{Error}\}} \qquad \dfrac{P[x\leftarrow E] \implies E \not\rightarrow \mathbf{error}} {\{P[x\leftarrow E]\} \;\; x := E \;\; \{P\}}$

Ancora un altro approccio è considerare una tripla Hoare da tenere solo se il programma termina correttamente. Questo è il solito approccio per i programmi non terminali: la postcondizione vale quando termina il comando, il che potrebbe non accadere sempre. Se trattate gli errori di runtime come non terminazione, spazzate via tutti i problemi di correttezza. Dovrai comunque dimostrare la correttezza del programma in qualche modo, ma non è necessario che sia nella logica Hoare se preferisci un altro formalismo per quel compito.

A proposito, nota che esprimere ciò che accade quando una variabile composta come una matrice viene modificata è più coinvolto di ciò che hai scritto. Supponiamo era, diciamo, : la sostituzione non cambierebbe , ma l'assegnazione potrebbe invalidare . Anche se si limita la sintassi dei predicati per parlare solo di atomi, considerare l'assegnazione sotto la condizione preliminare : non è possibile effettuare una semplice sostituzione per ottenere la postcondizione corretta , è necessario valutare $P$ $\mathrm{IsSorted}(A)$ $A[i]\leftarrow E$ $P$ $A[i] \leftarrow P$ $P$ $A[A[0]-1] := A[0]$ $A[0] = 2 \wedge A[1] = 3$ $A[0] = 1 \wedge A[1] = 1$ $A[0]$ (che può essere difficile in generale, poiché la condizione preliminare potrebbe non specificare un singolo valore possibile per ). È necessario eseguire la sostituzione sull'array stesso: . Gli appunti delle lezioni di Mike Gordon hanno una buona presentazione Logica Hoare con array (ma senza controllo degli errori). $A[0]$ $A \leftarrow A[i\leftarrow E]$

— Gilles 'SO- smetti di essere malvagio'
fonte

0

Come menzionato da Gilles, esiste un assioma di assegnazione di array (vedi le note di Gordon, Sez. 2.1.10 ): In parole, se si dispone di un'assegnazione di array, sostituire l'array originale con l'array che ha in posizione il valore . Nota che se hai già sul post e assegna , allora dovresti ottenere come pre (sì, in questo ordine - l'aggiornamento recente viene eseguito per primo!).

\frac{}{{Q [UN \mapsto UN . S t o r e (io, e X p r)]} UN [io] = e X p r {Q}}

$\dfrac{} {\{Q[A \mapsto A.store(i,expr) ] \} \;\; A[i] = expr \;\;\{ Q \}}$ A.store(i,expr)iexprA.store(i,vi)A[j]=vjA.store(j,vj).store(i,vi)

Inoltre, abbiamo bisogno l'assioma di accesso agli array: A.store(i,v)[i]può essere sostituito da v( "se si accede -esimo elemento che appena aggiornato, quindi restituire il valore assegnato"). $i$

Penso che per dimostrare che un programma con array sia corretto ("nessun accesso fuori limite"), gli assiomi sopra sono sufficienti. Consideriamo il programma:

...
A[i] = 12
...

Annotiamo questo programma:

...
@ {0<i<A_length}
A[i] = 12
...

dove A_lengthè una variabile che specifica la lunghezza dell'array. Ora prova a provare l'annotazione - vale a dire, elaborala all'indietro (dal basso verso l'alto, "come al solito" nelle prove Hoare). Se in cima ottieni {false}, allora può succedere l'accesso fuori limite, altrimenti l'espressione che hai è la condizione preliminare in base alla quale non sono possibili accessi fuori limite. (inoltre, dobbiamo assicurarci che quando l'array viene creato come int A=int[10];allora nella post-condizione che abbiamo {A_length==10}).

— Ayrat
fonte

I tuoi assiomi non modellano l'accesso fuori limite: non menzionano nemmeno la lunghezza! Nel programma di esempio, come ti rapporti lengtha A?

— Gilles 'SO- smetti di essere malvagio' il

Giusto, gli assiomi non modellano da accessi limitati. Innanzitutto, per dimostrare che un programma è corretto, aggiungo annotazioni che richiedono che un accesso sia all'interno dei limiti. (è lengthstato rinominato A_length.) In secondo luogo, abbiamo bisogno di assiomi di "creazione" simili int[] a = int[length] {a_length==length}. Penso che questo dovrebbe essere abbastanza.

— Ayrat,