Complexité et Preuve des algorithmes A. Mouloudi

Introduction La complexité des algorithmes est l’évaluation du coût d’exécution d’un algorithme en termes de temps (complexité temporelle) ou d’espace mémoire (complexité spatiale). Le coût d’exécution dépend de la machine. Mais nous ferons ici abstraction de ceci, pour nous concentrer sur le coût des actions résultant de l’exécution de l’algorithme, en fonction d’une “taille” n des données traitées. Ceci permet en particulier de comparer deux algorithmes traitant le même calcul. Nous sommes plus intéressés par un comportement asymptotique (que se passe-t-il quand n tend vers l’infini?) que par un calcul exact pour n fixé. Le temps d’exécution dépend de la nature des données. Nous nous intéresserons dans ce qui suit à la complexité en “pire des cas”, qui est une manière, pessimiste, d’ignorer cette dépendance

Exemple 1 Considérons l’exemple 1 suivant: {début} K  0 I  1 {#1} TANT QUE I ≤ N {#2} FAIRE R  R+T[I] {#3} I  I+1 {#4} FINTANTQUE {fin} Le temps d’exécution t(n) de cet algorithme en supposant que: - N=n - t1 est le temps d’exécution entre {début} et {#1} - t2 est le temps d’exécution de la comparaison {#2}

Exemple 1 - t3 est le temps d’exécution de l’action {#3} - t1, t2, t3, t4 sont des constantes (c.à.d. ne dépendent pas de n) Le temps s’écrit: et en définissant le temps tit d’exécution d’une itération (condition comprise), on obtient: tit = (t2 + t3 + t4) d’où t(n) = t1+ t2 + n * tit Ce qui signifie que le temps d’exécution dépend linéairement de la taille n (plus précisément est une fonction affine de n).

Exemple 1 Nous avons dit que nous nous intéressions au comportement asymptotique: que dire de t(n) quand n tend vers l’infini ? On a : Autrement dit t(n) est équivalent à l’infini à (tit * n), ce qui s’écrit: L’algorithme est donc asymptotiquement linéaire en n. Dans cet exemple simple l’évaluation en “pire des cas” est immédiate puisque t(n) ne dépend pas de la nature des données, ce qui n’est pas le cas de l’exemple 2 suivant:

Exemple 2 {début} K  0 I  1 {#1} TANT QUE I ≤ N {#2} FAIRE R  R+T[I] {#3} SI R>1000 {#3’} Alors R 2*R {#3’’} FINSI I  I+1{#4} FINTANTQUE {fin} Ici, le pire des cas (celui qui conduit au temps d’exécution le plus grand) est celui où la condition {#3’} est toujours vraie. En effet dans ce cas là R 2*R {#3’’} est exécutée à chaque itération.

Exemple 2 Ce qui correspond à l’évaluation suivante du temps d’exécution: L’algorithme est asymptotiquement linéaire en n. Un usage courant est d’associer un temps constant à chaque type d’opération ou d’action élémentaire. Ainsi en notant: - taff le temps correspondant à une affectation, - tp, tm, tc les temps associés respectivement à une addition, une multiplication et une comparaison, d’où le temps suivant:

Exemple 2 Pour simplifier encore, on confondra les temps associés à plusieurs opérations différentes (par exemple additions et multiplications seront associées au même temps to). Puisque ce qui nous intéresse est l’ordre de grandeur asymptotique de ce temps, on simplifiera encore en s’intéressant à une catégorie d’opérations ou d’actions. Par exemple, dans le cas ci-dessus on comptera, plutôt que le temps, le nombre de telles opérations, ce qui donne, en notant no, le nombre d’additions et multiplications: no = 3n

Les notations O et Θ Définition Soient f et g deux fonctions de IN dans , On dit que f est en O(g) ( f est asymptotiquement dominée par g) s’il existe un réel c >0 et un entier positif (un rang) n0 tel que : Pour tout n > n0, f(n) ≤ c.g(n) Exemple 1 f(n) = 3n +1 g(n) = n 3n+1 est en O(n) En effet pour n0 = 2, et c = 4 on a bien pour n> n0, l’inégalité 3n +1 ≤ 4n Soient f et g deux fonctions de IN dans , On dit que f est en Θ(g) (f et g sont de même ordre de grandeur asymptotique) si f est en O(g) et g est en O(f).

Les notations O et Θ Exemple 2 f(n) = 3n +1, g(n) = n 3n+1 est en Θ (n) En effet d’une part, 3n+1 est en O(n), d’autre part pour n0 =2, et c = 2 on a bien, pour n> n0, l’inégalité n≤ 2(3n+1) et donc n est en O(3n+1) En pratique f représente une quantité à étudier (temps, nombre d’opérations) et g fait partie d’une échelle de fonctions simples (n, nlog2(n), n2, etc...) destinée à informer sur le comportement asymptotique de f.

Les notations O et Θ 3n+1 est en O(n2) cependant, implicitement, on s’intéresse à dominer (3n+1) par la plus petite fonction possible. C’est ce que permet la notation Θ. n2 n’est pas en O(3n+1), et donc que (3n+1) n’est pas en Θ(n2). En effet c, il n’existe pas de rang à partir duquel on aurait (n2) ≤ c(3n+1): il suffit d’essayer de résoudre (n2 – c(3n+1)=0 et d’observer que le discriminant ((3c)2+ 4c) est toujours positif, et donc qu’à l’extérieur des racines le polynôme est >0, ce qui exclut naturellement de trouver un rang à partir duquel on aurait (n2) ≤c(3n+1).

Les notations O et Θ Propriété 1 f est en Θ(g) si et seulement si: Il existe c, d réels >0 et un rang n0 tels que, pour tout n > n0, on a d. g(n) ≤ f(n) ≤ c.g(n) La notation Θ se ramène donc à un encadrement (à partir d’un certain rang) de la quantité f étudiée.

Les notations O et Θ Propriété 2 1)  f est en Θ(g) 2)  f est en O(g) mais f n' est pas en Θ(g) 3)  f n’ est pas en O(g) et donc f n' est pas en Θ(g) En pratique on cherchera des équivalents à l’infini de f. Exemple 3 f(n) = 3n +1 et donc f est en Θ(n)

Les notations O et Θ Exemple 4 : (deux boucles imbriquées sans dépendance des indices). B  0 I  1 POUR I 1 à N FAIRE B  B+2 POUR J 1 à N FAIRE T[I,J]  (1+T[J,I] )*B FINPOUR

Les notations O et Θ Soit Op(n) le nombre d’additions et multiplications avec N=n,  Op(n) est en Θ(n2)

Les notations O et Θ Exemple 5 : (deux boucles imbriquées avec dépendance des indices) B  0 I  1 POUR I 1 à N FAIRE B  B+2 POUR J 1 à I FAIRE T[I,J]  (1+T[J,I] )*B FINPOUR

Les notations O et Θ

Calcul de la complexité «en pire des cas» Notons TA(n) le temps ou le nombre d’opérations, « en pire des cas » correspondant à la suite d’actions A, ou au calcul de l’expression A. Une suite d’actions est considérée ici comme une action non élémentaire. Règle 1: Enchaînement Soient deux suites d’actions A1 et A2, et A1+A2, la suite « A1 suivi de A2 ». Alors: T(A1+A2)(n) = TA1(n)+ TA2(n)

Calcul de la complexité «en pire des cas» Règle 2: Conditionnelle Soit une action A de la forme « SI C ALORS A1 SINON A2 FINSI » Alors: TA(n) = TC(n) + Max( TA1(n), TA2(n)) En effet, dans le pire des cas, c’est toujours la plus coûteuse des deux actions qui s’exécute.

Calcul de la complexité «en pire des cas» Exemple 6 POUR I 1 à N FAIRE ResX+Y+Z+Res SI T[I] +K < B ALORS {Action1} POUR J 1 à N FAIRE Res  Res +T[J] FINPOUR SINON {Action2} ResRes+T[I] FINSI

Calcul de la complexité «en pire des cas» Soit Op(n) le nombre d’additions, avec N=n. Notons Opc(i,n) le nombre d’additions dans la structure «SI.....SINON...FINSI » à la ième itération de la boucle externe, Op1(i,n) le nombre d’additions dans {Action1} et Op2(i,n) le nombre d’additions dans {Action2}

Calcul de la complexité «en pire des cas» Règle 3: Itération (TANTQUE) Soit une action A de la forme « TANTQUE C FAIRE A1 FINTANTQUE» En notant niter(n) le nombre d’itérations, on a:

Calcul de la complexité «en pire des cas» Exemple 7 { Nous nous intéressons ici au nombre d’opérations (+,-,*), Op(n), avec N=n} { Nous supposons ici que Truc(l,n)<n et que Truc(l,n) nécessite Tt(n)= (n-l) opérations} {on suppose aussi que Tab est de dimension Nmax ≥ N+1} Res  0 L  2 TANTQUE L ≤ Truc(L, N) FAIRE Res  Res+2*Tab[L+1]+Truc(L,N) L  L+2 FINTANTQUE

Calcul de la complexité «en pire des cas» Remarquons d’abord que L augmente de 2 à chaque itération et que dans le pire des cas la condition testée est L≤ N, pour toute valeur de L (puisque Truc(L,N) ≤N). Nous pouvons alors écrire Op(n) de la manière suivante: Pour se ramener à des pas de 1 on pose 2k=l, ce qui permet d’écrire:

Calcul de la complexité «en pire des cas»

Calcul de la complexité «en pire des cas» En ce qui concerne la structure « POUR ....... FAIRE ...... FINPOUR » on procèdera de la manière suivante: on considère la boucle TANTQUE équivalente: POUR I  ideb à ifin FAIRE Action1 FINPOUR est considéré équivalent à

Calcul de la complexité «en pire des cas» I  ideb -1 TANTQUE I < ifin FAIRE I  I+1 Action1 FINTANTQUE C’est à dire que l’on compte en plus des (ifin-ideb+1) itérations, (ifin-ideb+2) affectations, additions, comparaisons. Remarquons qu’une pratique courante consiste à négliger (lorsque cela ne change pas la complexité) ces opérations implicites dans le «POUR..... », comme nous l’avons fait ci-dessus.

Calcul de la complexité «en pire des cas» Exemple 8 POUR I 1 à N FAIRE Res  Res+I FINPOUR Le nombre d’additions est ici N si on néglige ces opérations implicites, et 2N+1 si on les compte (ici ifin-ideb+1 = N).

Calcul de la complexité «en pire des cas» Règle 4 : Fonctions et Procédures non récursives On évalue d’abord les fonctions et rocédures qui ne contiennent pas d’appels à d’autres fonctions et procédures, puis celles qui contiennent des appels aux précédentes, etc.... Exemple 9 Algorithme Truc VAR C: CARACTERE N, R0, R1,I: ENTIER

Calcul de la complexité «en pire des cas» PROCEDUR A (VAR R : ENTIER) VAR I: ENTIER DEBUT POUR I 1 à N FAIRE R  R*I FINPOUR FIN PROCEDUR B (VAR R: ENTIER) VAR I,J: ENTIER J  1 A(J) R  R*J

Calcul de la complexité «en pire des cas» DEBUT LIRE(C) LIRE(N) R0  1 R1  1 {debut #1} SI C =‘#’ ALORS {début ##1} POUR I 1 à N FAIRE R1 2*R1 B(N) FINPOUR {fin ##1} FINSI {Fin #1} {début #2} A(N) {fin #2} FIN

Calcul de la complexité «en pire des cas» Nous calculons ici le nombre de multiplications Op(n) pour N=n. Nous observons d’abord que l’algorithme, dans le pire des cas (ici C=‘#’) où OpA(n) et OpB(n) représentent le nombre de multiplications correspondant à l’exécution de A et de B. De plus on a:

Calcul de la complexité «en pire des cas» Et finalement Le calcul se déroule alors ainsi:

Remarque importante Lors d’un appel d’une fonction, il faut en toute rigueur compter l’appel lui-même comme une opération particulière, mais aussi compter les opérations correspondant au passage de l’argument. Plus précisément: lors d’un passage par valeur, pour chaque argument passé il faut évaluer l’argument (par exemple l'addition pour Factorielle(n+1), et affecter cette valeur à une nouvelle variable (locale à la fonction).

Remarque importante On néglige souvent cette dernière opération, cependant si l’argument passé est un tableau de taille N, alors l’affectation correspond à N affectations élémentaires, et ce coût n’est plus négligeable. C’est en particulier une des raisons pour lesquelles on évite souvent de passer par valeur un tableau même si sa valeur ne doit pas être modifiée par la procédure (ou fonction).

Comparaison de deux algorithmes Considérons le problème suivant: nous disposons d’un tableau T de N entiers (N pair) ayant la propriété suivante: les N/2 premiers éléments de T se retrouvent dans la seconde moitié du tableau mais en ordre inverse (par exemple T=(1,3,5,7,7,5,3,1) ). Nous donnons ci-dessous deux fonctions calculant la somme des éléments du tableau:

Comparaison de deux algorithmes {Const N= 100 } {TYPE Tabentier = Tableau [1..N] : ENTIER} FONCTION Somme1( T:Tabentier): ENTIER VAR I, R: ENTIER DEBUT I  1 R  0 TANTQUE I <= N FAIRE R  R+T[I] I  I+1 FINTANTQUE retourner (R) FIN

Comparaison de deux algorithmes FONCTION Somme2(T:Tabentier) : ENTIER VAR I, R,M: ENTIER DEBUT I  1 R  0 M  N/2 TANTQUE I <= M FAIRE R  R+T[I] I  I+1 FINTANTQUE retourner (R+R) FIN

Comparaison de deux algorithmes Comptons les nombres d’additions Op1(n) et Op2(n) dans les deux fonctions: Op1(n) = 2n, Op2(n) = 2 (n/2) +1= n+1 Si nous comparons ces deux fonctions, les nombres d’additions sont de même ordre de grandeur asymptotique (Tous deux sont en Θ(n)) mais on remarque que:

Comparaison de deux algorithmes Plus précisément : Plus généralement lorsqu’on compare deux algorithmes effectuant la même tâche, on comparera surtout les ordres de grandeur asymptotique (L’un est-il quadratique et l’autre linéaire?) mais aussi plus finement, comme dans le cas ci-dessus, le rapport asymptotique des nombres d’opérations ou des temps d’exécution.

Cas des procédures et fonctions récursives Dans ce cas on obtient, lorsqu’on calcule un temps d’exécution ou un nombre d’opérations, des équations de récurrence. Exemple 1 Considérons le cas de n!, En utilisant les propriétés suivantes: Fact(0) =1 Fact(n) = n*fact(n-1) Si nous intéressons au temps d’exécution, nous obtenons l’équation suivante (où t0 et t1 sont des constantes):

Cas des procédures et fonctions récursives Op(0) = t0 Op(n) = Op(n-1) + t1 Nous résolvons cette équation par substitutions successives: {1} Op(n) = Op(n-1) + t1 {2} Op(n-1) = Op(n-2) + t1 {3} Op(n-2) = Op(n-3) + t1 ....... {k} Op(n-k+1) = Op(n-k) + t1 ........ {n-1} Op(2) = Op(1) + t1 {n} Op(1) = t0 + t1 --------------------------------------------------------- Op(n) = t0+ n*t1 est en Θ(n).

Cas des procédures et fonctions récursives Le cas où il y a plusieurs appels, est souvent plus difficile. Par exemple l’équation de récurrence correspondant à Fib(n) est la suivante: Op(0)= Op(1) = t0 Op(n) = Op(n-1) + Op(n-2) + t1 Cette équation est assez difficile, mais nous reviendrons plus tard sur une majoration. Un cas plus simple est le suivant:

Cas des procédures et fonctions récursives FONCTION Mib(N: ENTIER ; P: ENTIER): ENTIER VAR Res : ENTIER /* on suppose que N≥0 et P≤N */ DEBUT SI N = 0 ALORS Res  P SINON Res  Mib(N-1,P-1) + Mib(N-1,P) +P FINSI RETOURNER(Res) FIN

Cas des procédures et fonctions récursives On obtient les équations de récurrence suivantes, où on remarque que le temps d’exécution ne dépend pas de la valeur de P: Op(0) = t0 Op(n) = 2Op(n-1) +t1 On peut utiliser la méthode précédente, mais pour obtenir les simplifications voulues on double chaque nouvelle équation:

Cas des procédures et fonctions récursives {1} Op(n) = 2Op(n-1) + t1 {2} 2 Op(n-1) = 22 Op(n-2) + 2t1 {3} 22 Op(n-2) = 23 Op(n-3) + 22 t1 .................................................................................. {k} 2k-1Op(n-(k-1)) = 2k Op(n-k) + 2k-1 t1 ................................................................................... {n-1} 2n-2 Op(2) =2n-1 Op(1) +2n-2 t1 {n} 2n-1 Op(1) = 2n t0 + 2n-1 t1 -------------------------------------------------------------------- Op(n) = 2n t0 + ( 1+2 + 22+ ...+2n-1) t1 = 2n t0 + ((2n -1) / (2-1)) t1 Donc Op(n) est en Θ(2n)

Complexité en moyenne En ce qui concerne la complexité moyenne, le point de vue adopté est probabiliste : plutôt que calculer une quantité en considérant la pire situation (c’est à dire la pire configuration des données d’entrée), on considère l’univers de toutes les configurations possibles, chacune associée à une probabilité, et on fait une somme pondérée, par ces probabilités, des valeurs prise par cette quantité dans les différentes configurations. C’est ce qu’on appelle l’espérance mathématique, ou plus communément, la moyenne de cette quantité selon ce modèle de probabilité. Une quantité, considérée dans le cadre probabiliste, s’appelle une variable aléatoire.

Preuve de correction des algorithmes La question principale qui se pose à tout informaticien est : Comment savoir qu’un algorithme donne le résultat espéré ? Voici quelques exemples où il est nécessaire d’avoir des algorithmes corrects Contrôle de pilote automatique Contrôle des commandes d’un avion Centrale nucléaire Robots médicaux Bases de données critiques : Chemins de fer, Banque, etc Circuits électroniques Sécurité des systèmes d’information Sécurité des puces électroniques

Preuve de correction des algorithmes Comment faire en sorte que l’on soit sûr de la correction de l’algorithme ? Générer un ensemble de tests. Mais la plupart du temps, on n’a pas de garantie que l’algorithme est correct. Vérifier que l’algorithme correspond bien aux attentes. Cette opération couvre plusieurs méthodes, parfois compliquées mais très sûr (à condition de ne pas faire d’erreur dans la preuve…)

Preuve de correction des algorithmes Exemple : Recherche du maximum dans un tableau de réels ALGORITHME maximum( n: ENTIER, t [n]: REEL) VAR max: REEL i: ENTIER DEBUT max  t[0] POUR i1 à n-1 FAIRE SI t[i-1] < t[i] ALORS max  t[i] FINSI FINPOUR RETOURNER max FIN L’algorithme donne-t-il bien l’élément maximum du tableau En général les étudiants sont très confiants de leur algorithme

Preuve par invariant de boucle Principe Une preuve d’algorithme par invariant de boucle utilise la démarche suivante. Nous prouvons tout d’abord que l’algorithme s’arrête en montrant qu’une condition d’exécution de boucle finit par ne plus être réalisée. Nous exhibons alors un invariant de boucle, c’est-à-dire une propriété P qui, si elle est valide avant l’exécution d’un tour de boucle, est aussi valide après l’exécution du tour de boucle. Nous vérifions alors que les conditions initiales rendent la propriété P vraie en entrée du premier tour de boucle. Nous en concluons que cette propriété est vraie en sortie du dernier tour de boucle. Un bon choix de la propriété P prouvera qu’on a bien produit l’objet recherché. La difficulté de cette méthode réside dans la détermination de l’invariant de boucle. Quand on le trouve il est en général simple de montrer que c’est bien un invariant de boucle.

Preuve par invariant de boucle Exemple 1: Algorithme de division euclidienne par soustraction B  b R  a Q  0 TANT QUE R >= B FAIRE R  R − B Q  Q + 1 FINTANTQUE Remarquons que les conditions initiales donnent a = B x Q + R.

Preuve par invariant de boucle Montrons que la propriété a = B x Q + R est un invariant de boucle : notons R′, B′, Q′ les nouvelles valeurs en sortie de B, Q et R. Alors R′= R − B et Q′= Q + 1. Ceci prouve que B′ x Q′ + R′= B x Q + R. De plus la quantité entière R-B diminue strictement à chaque tour, donc le programme se termine et après la boucle on a : a = B x Q + R et R < B.

Preuve par invariant de boucle Exemple 2: Version binaire de l’algorithme de division euclidienne On calcule le plus petit entier n ≥ 0 tel que 2nb > a. B  b R  a Q  0 N  n Aux  2NB TANT QUE N > 0 FAIRE Aux  Aux/2 N  N − 1 SI R < Aux ALORS Q  2 x Q SINON Q  2 x Q + 1 R  R − Aux FINSI FINTANTQUE

Preuve par invariant de boucle Montrons que les conditions : constituent un invariant de boucle. Ces conditions sont bien réalisées à l’état initial. Nous noterons Aux′, Q′, R′, N′ les valeurs, en sortie, de Aux, Q, R, N. Si en entrée de boucle les conditions précédentes sont remplies alors dans la boucle on a: Aux′ = Aux/2 et N′ = N - 1 donc Aux′ = 2N′B. De plus :

Preuve par invariant de boucle 1er cas : R < Aux′ Dans ce cas R′= R, Aux est divisé par 2 tandis que Q est multiplié par 2. On a donc bien les conditions indiquées en sortie. 2ème cas : Si R ≥ Aux′ alors on sait que : Aux′≤ R < Aux = 2 x Aux′ On a aussi Aux′= Aux/2, Q′= 2 x Q + 1, R′= R − Aux′ et R′< Aux′. On a donc bien les conditions attendues. De plus N décroît strictement, donc le programme se termine avec N = 0. Quand N = 0 la variable Aux contient b, Q contient q et R contient r.

Preuve par invariant de boucle Exemple 3: Algorithme d’Euclide de calcul du pgcd R0  |a| R1  |b| /* b différent de 0 */ TANT QUE R1 > 0 FAIRE R  Reste_Division(R0,R1) R0  R1 R1  R FINTANTQUE En sortie R1 = 0 et R0 = pgcd(a, b). Les conditions : L’ensemble des diviseurs communs de R0 et R1 est l’ensemble des diviseurs communs de a et b. R1 ≥ 0 constituent un invariant de boucle.

Preuve par invariant de boucle Remarquons qu’initialement l’ensemble des diviseurs communs de R0 et R1 est l’ensemble des diviseurs communs de a et b. Notons R0′, R1′ les nouvelles valeurs de R0, R1 en sortie d’un tour de boucle. Nous avons alors: R0′= R1 et R1′= R0 - QR1 avec 0 ≤ R1′< R1. Donc tout diviseur de R1 et R0 est diviseur de R0′ et R1′, et réciproquement. Cet algorithme se termine car R1 décroît strictement à chaque tour de boucle. A la fin R1 = 0, donc l’ensemble des diviseurs de R0 et de R1 est l’ensemble des diviseurs de R0, et par conséquent R0=pgcd(a,b).

Preuve par invariant de boucle Exemple 4: Algorithme d’Euclide étendu Là encore nous supposerons que a≥0 et b>0. Le cas général s’en déduit. Notons d=pgcd(a, b). Voici un algorithme (algorithme d’Euclide étendu, adaptation de l’algorithme précédent) qui permet de trouver explicitement un couple (u,v) qui vérifie : u x a + v x b = d.

Preuve par invariant de boucle R0  a /* a ≥ 0 */ R1  b /* b > 0 */ U0  1 U1  0 V0  0 V1  1 TANT QUE R1 > 0 FAIRE Q  Quotient_Division(R0,R1) R  Reste_Division(R0,R1) U  U0 − Q x U1 V  V0 − Q x V1 R0  R1 R1  R U0  U1 U1  U V0  V1 V1  V FINTANTQUE

Preuve par invariant de boucle Remarquons qu’il s’agit d’une amélioration de l’algorithme d’Euclide donné précédemment pour le calcul du pgcd. Comme précédemment l’algorithme se termine avec R1 = 0 et R0 = pgcd(a, b). Montrons que les conditions : sont un invariant de boucle. Pour cela notons R0′, R1′, U0′, U1′, V0′, V1′ les nouvelles valeurs de R0, R1, U0, U1, V0, V1 en sortie d’un tour de boucle. On a : R0 = Q x R1 + R U = U0 − Q x U1 V = V0 − Q x V1

Preuve par invariant de boucle Puis R0′= R1 R1′= R = R0 − Q x R1 U0′= U1 U1′= U = U0 − Q x U1 V0′= V1 V1′= V = V0 − Q x V1 Si bien que : U0′a + V0′b = U1a + V1b = R1 = R0′ La première condition est bien réalisée en sortie. De même on a : U1′a + V1′b = U0a + V0b − Q x (U1a + V1b) = R0 − Q x R1 = R′1, donc la deuxième condition est aussi réalisée. Il est facile de voir qu’à l’instant initial ces deux conditions sont bien réalisées. En sortie on a R1 = 0 et R0 = pgcd(a, b) si bien que U0 et V0 contiennent une solution du problème.

Preuve par invariant de boucle Exemple 5: Calcul d’une puissance Soit n ≥ 1 un entier. On veut calculer an (a est par exemple dans Z/nZ ou dans R, C,...). On considère l’algorithme suivant: A  a N  n R  1 TANT QUE N > 0 FAIRE SI N pair ALORS A  A x A N  N/2 SINON R  R x A N  N − 1 FINSI FINTANTQUE

Preuve par invariant de boucle Cet algorithme se termine et en sortie R contient an. Preuve : La valeur de N ≥ 0 décroît strictement à chaque tour de boucle, donc l’algorithme se termine. Au début on a: AN × R = an. Si en entrée de boucle AN × R = an alors il est facile de voir que dans les deux cas N pair ou N impair on a la même égalité en sortie de boucle. Mais à la fin on a N = 0 et par conséquent R = an.