Comment gérer les tableaux pendant les épreuves de correction de style Hoare

11

Dans la discussion autour de cette question , Gilles mentionne correctement que toute preuve d'exactitude d'un algorithme qui utilise des tableaux doit prouver qu'il n'y a pas d'accès de tableau hors limites; selon le modèle d'exécution, cela entraînerait une erreur d'exécution ou l'accès à des éléments non-tableau.

Une technique courante pour effectuer de telles preuves d'exactitude (au moins dans les études de premier cycle et probablement dans la vérification automatisée) consiste à utiliser la logique Hoare . Je ne suis pas au courant que l'ensemble de règles standard contient quoi que ce soit concernant les tableaux; ils semblent être limités aux variables monadiques.

Je peux imaginer ajouter des axiomes de la forme

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

Cependant, il est clair pour moi comment vous traitez avec un accès au tableau sur le côté droit, à savoir si elle fait partie d'une expression complexe dans une déclaration . $E$ $x := E$

Comment les accès aux tableaux peuvent-ils être modélisés dans la logique Hoare afin que l'absence d'accès non valide puisse et doit être prouvée pour l'exactitude du programme?

Les réponses peuvent supposer que nous interdisons l'utilisation d'éléments de tableau dans des instructions autres que ou dans le cadre de certains dans car cela ne restreint pas l'expressivité; on peut toujours affecter à une variable temporaire la valeur souhaitée, c'est-à-dire écrire au lieu de $A[i] := E$ $E$ $x := E$ $t := A[i];\ \mathtt{if} ( t > 0 ) \dots$ $\mathtt{if} ( A[i] > 0 )\dots$ .

— Raphael
source

8

Votre axiome n'est pas vraiment un axiome, il manque des hypothèses. Des présentations simples de la logique Hoare manipulent des formules de la forme où et sont des formules logiques et est une commande. Vous devez vous assurer que est bien formé . Dans des langages simples comme ceux souvent utilisés pour une première introduction à la logique Hoare, la bonne forme est syntaxique: il s'agit généralement de vérifier que $\{P\} C \{P'\}$ $P$ $P'$ $C$ $C$ $C$ se conforme à une grammaire sans contexte, et peut-être que les variables libres sont dans un ensemble autorisé. Si le langage comprend des constructions qui ont une exactitude sémantique, telles que les accès aux éléments du tableau, vous devez ajouter des hypothèses pour exprimer cette exactitude sémantique.

Formellement, vous pouvez ajouter des jugements pour exprimer la correction d'expressions et de commandes. Si les expressions n'ont pas d'effets secondaires, elles n'ont pas besoin de post-conditions, seulement de conditions préalables. Par exemple, vous pouvez écrire des règles de bonne forme telles que et n'autorisent que des expressions bien formées dans les commandes:

\frac{{P} E wf}{{P \land 0 \leq E < l e n g t h (A)} A [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\}}$

Une approche différente consiste à traiter toutes les expressions comme bien formées, mais à faire en sorte que toute expression impliquant un calcul mal formé ait une valeur spéciale . Dans les langues avec vérification des limites d'exécution, signifie «ce programme a déclenché une exception fatale». Vous suivriez alors si un programme s'est trompé via un prédicat logique ; un programme n'est valable que si vous pouvez prouver que sa postcondition implique . $\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\}}$

Une autre approche consiste à considérer un triple de Hoare comme valable uniquement si le programme se termine correctement. Il s'agit de l'approche habituelle pour les programmes non terminés: la postcondition se maintient lorsque la commande se termine, ce qui peut ne pas toujours se produire. Si vous traitez les erreurs d'exécution comme non terminées, vous balayez tous les problèmes de correction sous le capot. Vous devrez toujours prouver l'exactitude du programme d'une manière ou d'une autre, mais ce n'est pas nécessairement dans la logique Hoare si vous préférez un autre formalisme pour cette tâche.

Soit dit en passant, noter que l'expression de ce qui se produit lorsqu'une variable composée telle qu'un tableau est modifié est plus complexe que ce que vous avez écrit. Supposons que était, disons, : la substitution ne changerait pas , mais l'affectation pourrait invalider . Même si vous limitez la syntaxe des prédicats pour ne parler que des atomes, considérez l'affectation $P$ $\mathrm{IsSorted}(A)$ $A[i]\leftarrow E$ $P$ $A[i] \leftarrow P$ $P$ sous la condition préalable : vous ne pouvez pas faire une simple substitution pour obtenir la postcondition correcte , vous devez évaluer (ce qui peut être difficile en général, car la précondition peut ne pas spécifier une seule valeur possible pour $A[A[0]-1] := A[0]$ $A[0] = 2 \wedge A[1] = 3$ $A[0] = 1 \wedge A[1] = 1$ $A[0]$ ). Vous devez effectuer la substitution sur le tableau lui-même: . Les notes de cours de Mike Gordonont une bonne logique Hoare de présentation avec des tableaux (mais sans vérification d'erreur). $A[0]$ $A \leftarrow A[i\leftarrow E]$

— Gilles 'SO- arrête d'être méchant'
source

0

Comme mentionné par Gilles, il existe un axiome d'affectation de tableau (voir les notes de Gordon, Sec. 2.1.10 ):

\frac{}{{Q [A \mapsto A . s t o r e (i, e x p r)]} A [i] = 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)

De plus, nous avons besoin de l'axiome d'accès au tableau: A.store(i,v)[i]peut être remplacé par v("si vous accédez $i$ e élément que vous venez de mettre à jour, puis renvoyez la valeur attribuée ").

Je pense que pour prouver qu'un programme avec des tableaux est correct ("pas d'accès hors limites"), les axiomes ci-dessus suffisent. Prenons le programme:

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

Nous annoterions ce programme:

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

où A_lengthest une variable qui spécifie la longueur du tableau. Essayez maintenant de prouver l'annotation - à savoir, travaillez-la à l'envers (de bas en haut, "comme d'habitude" dans les épreuves Hoare). Si vous obtenez en haut {false}, l'accès hors limite peut se produire, sinon l'expression que vous avez est la condition préalable sous laquelle aucun accès hors limite n'est possible. (aussi, nous devons nous assurer que lorsque le tableau est créé comme int A=int[10];alors dans la post-condition que nous avons {A_length==10}).

— Ayrat
source

Vos axiomes ne modélisent pas l'accès hors limites: ils ne mentionnent même pas la longueur! Dans votre programme d' exemple, comment voulez - vous rapportez lengthà A?

— Gilles 'SO- arrête d'être méchant'

À droite, les axiomes ne modélisent pas les accès hors limites. Tout d'abord, pour prouver qu'un programme est correct, j'ajoute des annotations qui nécessitent qu'un accès soit dans les limites. (a lengthété renommé A_length.) Deuxièmement, nous avons besoin d'axiomes de "création" de tableaux comme int[] a = int[length] {a_length==length}. Je pense que cela devrait suffire.

— Ayrat