Notes sur le cours sur les automates - 3° partie, Notes de Applications informatiques
Francine88
Francine8813 January 2014

Notes sur le cours sur les automates - 3° partie, Notes de Applications informatiques

PDF (224.9 KB)
10 pages
209Numéro de visites
Description
Notes d’informatique sur le cours sur les automates - 3° partie. Les principaux thèmes abordés sont les suivants: Le code, les algorithmes linguistiques, l'algorithme de huffmann, l'algorithme de sardinas et patterson.
20points
Points de téléchargement necessaire pour télécharger
ce document
Télécharger le document
Aperçu3 pages / 10
Ceci c'est un aperçu avant impression
Chercher dans l'extrait du document
Ceci c'est un aperçu avant impression
Chercher dans l'extrait du document
Aperçu avant impression terminé
Chercher dans l'extrait du document
Ceci c'est un aperçu avant impression
Chercher dans l'extrait du document
Ceci c'est un aperçu avant impression
Chercher dans l'extrait du document
Aperçu avant impression terminé
Chercher dans l'extrait du document

L'ensemble est un code. Ici, la connaissance du début abababa ne permet

pas encore de savoir si la décomposition commence par ou par . Ce

n'est qu'après la lecture de la lettre suivante (non encore indiquée dans l'exemple) que l'on sait

si la décomposition commence par ab (si la lettre est b) ou par ababa (si la lettre est a)

Définition: Un code est à "délai de déchiffrage fini" s'il existe un entier d tel que, chaque fois

qu'un message wcommence par avec alors la factorisation

complète de w commence par . C'est donc après un "délai" de d mots de code que nous

pouvons affirmer que le premier mot trouvé est le bon.

Exemples:

Le code :

Tableau: 55.2

a un délai de 0.

Le code :

Tableau: 55.3

à un délai de 2.

ALGORITHMES LINGUISTIQUES

Mettons un peu en pratique ce qui a déjà été vu jusqu'ici afin de nous appuyer un peu sur du

concret "utile" ! Nous verrons plus loin une fois les automates introduits, quelques algorithmes

de recherche de sous-chaînes (tel qu'utilisés en génomique).

ALGORITHME DE HUFFMANN

Rappel : en informatique, nous décidons de coder un nombre entier compris entre 0 et 255 par

une séquence de 8 chiffres binaires (binary digits, ou "bits" en anglais, valant 0 ou 1), encore

appelée octet.

A priori, il suffit pour cela de se donner une table de correspondance du genre :

... ...

138 10001010

139 10001011

... ...

Tableau: 4 - Correspondance de code arbitraire

La correspondance peut être quelconque, dictée par notre imagination, du moment qu'à chaque

entier entre 0 et 255 est affecté un code binaire et un seul. Une fois une correspondance fixée,

il suffit de la prendre comme convention.

En pratique, la convention qui a été choisie est celle de la représentation en base 2. Elle a le

mérite d'être naturelle et logique. Dans la table ci dessus, 10001010 est la représentation en

base 2 de 138. C'est la manière de noter les chiffres que nous aurions adoptée si nous n'avions

que deux doigts au lieu de dix.

L'octet défini selon cette convention est l'unité de base de stockage des données. Tout fichier

informatique est une suite d'octets rangés selon un ordre bien défini. La taille du fichier est

simplement le nombre d'octets qui le constituent. Le kilo-octet (Ko) correspond à 1024 ( et non

pas 1000) octets, le méga-octet (Mo) à 1024*1024 octets (convention absurde des

informaticiens)

Il convient de noter que cette convention de représentation en base 2, n'est qu'une

convention. D'autres conventions sont possibles, qui conviendraient tout autant pour peu que

tout le monde s'accorde à employer la même convention.

Le problème que nous nous posons est: y aurait-il une autre manière de coder les chiffres,

peut-être moins logique mais plus judicieuse, de telle manière que la taille du même fichier

récrit selon la nouvelle convention, serait moins grande?

La convention de codage binaire est finalement très démocratique: que vous soyez un Zéro ou

un DeuxCentCinquanteCinq, nous vous allouons 8 bits de toute manière pour pouvoir vous

coder. Autrement dit, chaque entrée possible (un nombre entre 0 et 255) est codée sur 8 bits. Il

s'agit d'un codage à taille fixe.

Du point de vue de notre problème (la compression de données), cela ne nous importerait pas

si chacune des valeurs possibles (0 ... 255) était représentée aussi fréquemment que les autres.

Mais en général c'est n'est pas le cas.

A titre d'exemple, voir l'analyse des octets du fichier Wordpad.exe (cf. dans votre dossier

Accessoires...). Dans ce tableau, en abscisse comme en ordonnée sont portées les valeurs

possibles d'un octet donné (donc 0 ... 255). Sur la diagonale, à l'abscisse et ordonnée

correspondante la taille du cercle est proportionnelle au nombre d'octets ayant cette valeur

dans le fichier :

(38)

Nous voyons clairement que les valeurs 0, 128 et 255 sont nettement plus fréquentes que les

autres!

A titre indicatif, voici quelques valeurs:

Valeur Nombre Fréquence

0 71891 34.4%

2 1119 0.53%

128 1968 0.94%

130 79 0.038%

255 10422 4.99%

Tableau: 5 - Correspondance valeurs/fréquences

Nous allons maintenant décider d'une convention de codage à taille variable, qui représente une

valeur fréquente par un petit nombre de bits, et une valeur peu fréquente par un grand nombre

de bits.

Par exemple, 0 sera maintenant représenté par la séquence "11" (anciennement "00000000"),

128 par "1011010" (anciennement "10000000"), 255 par "0100" (anciennement "11111111"),

etc...

Etant donné que 0 représente à lui seul un tiers du fichier, nous avons gagné une place

considérable en le codant sur deux bits au lieu de huit! Et idem pour les autres valeurs

fréquentes...

L'algorithme de Huffman est une recette pour générer un code-préfixe à taille variable, à partir

de la table des fréquences d'une suite de valeurs. Donc, si vous nous avez bien suivi dans la

théorie jusqu'ici, c'est une solution à notre problème.

Supposons que notre fichier soit extrêmement simple, et constitué d'un mot unique :

anticonstitutionnellement

Il y a 25 caractères dans ce fichier; chaque caractère étant codé par un octet de 8 bits (codage

ASCII) cela signifie donc 25 octets, ou encore 200 bits. Voyons ce que nous pouvons faire de

cela.

Table des fréquences:

Clé Fréquence

' a ' 1

' c ' 1

' s ' 1

' u ' 1

' m ' 1

' o ' 2

' l ' 2

' i ' 3

' e ' 3

' n ' 5

' t ' 5

Tableau: 6 - Fréquence des lettres dans un mot

Tous les autres octets ont une fréquence nulle: ils ne sont pas représentés dans le fichier.

Première étape, nous créons maintenant un "noeud terminal" pour chaque entrée du tableau :

(39)

Ce qui nous fait pour l'instant 11 arbres contenant un seul noeud chacun.

Nous commençons maintenant une itération : à chaque fois nous supprimons les deux arbres

de gauche et les remplaçons par un "arbre somme". Le nouvel arbre est inséré dans la liste en

respectant l'ordre croissant, et on recommence jusqu'à ce qu'il ne reste plus qu'un seul arbre:

Itération 1:

(40)

Itération 2:

(41)

Itération 3 :

(42)

Itération 4 :

(43)

etc ...

L'arbre final:

(44)

Et voilà le travail!

Maintenant, le code associé à chaque Clé n'est autre que le chemin d'accès au noeud terminal

correspondant, depuis la racine, en notant 0 la branche de gauche et 1 la branche de droite.

Finalement :

Clé Code binaire

n 00

t 01

i 100

e 101

a 11000

c 11001

o 1101

l 1110

m 11110

s 111110

u 111111

Tableau: 7 - Correspondance lettre/code binaire

Et voici maintenant, transcrit avec notre nouveau code, le mot de départ :

110000001100110011101001111100110001111111011001101000010111101110101111101010001

ce qui nous fait 81 bits, au lieu de 200 au départ! Cela correspond à un taux de compression

de 60 %.

Le fait d'avoir généré un code en se servant d'un arbre binaire assure qu'aucun code ne peut

être le préfixe d'un autre. Vous pouvez vérifier qu'à l'aide de la table de codage, il n'y a aucune

ambiguïté possible pour décoder notre mot compressé!

En pratique, la table de codage étant spécifique à chaque fichier, il est indispensable de

l'incorporer au fichier compressé, de manière à ce que le décryptage soit possible. Ce qui

signifie que la taille du fichier compressé doit être augmentée d'autant. Dans le cas de notre

fichier exemple, il faudrait incorporer au minimum de 22 octets de plus pour insérer la table de

codage, et le taux de compression n'est plus aussi bon.

Toutefois, pour des fichiers suffisamment larges (à partir de quelques kilo-octets) le surplus de

taille généré par la table de codage devient négligeable par rapport à l'ensemble du fichier.

Concrètement, l'algorithme de Huffman permet d'obtenir des taux de compression typiques

compris entre 30% et 60%. Sans être aussi bien que ce que réalise Winzip (en moyenne 20 % de

mieux), c'est déjà pas mal!

ALGORITHME DE SARDINAS ET PATTERSON

Face à de longs codes, la difficulté rester à vérifier si un code en est vraiment un... Pour cela,

nous pouvons utiliser l'algorithme de Sardinas et Patterson (la démonstration de cet algorithme

se fera lors de la prochaine mise à jour de ce chapitre).

Pour ce faire, nous construisons un graphe , où P est l'ensemble des préfixes

non vides (selon la définition des "préfixes" donnée plus haut) de mots de X, et U l'ensemble

des couples (u, v) tels que :

1. (en éliminant les couples doubles au besoin)

2. et il existe tel que

Exemple:

Pour , l'ensemble P contient, en plus de X (qui sont préfixes de ), les

mots (respectivement préfixes

de )

D'abord nous voyons de suite que l'ensemble n'est pas un code parce

que :

(45)

Maintenant, les couples (1) U sont et

pour (2) les couples sont (pour lesquels x vaut

respectivement ).

Le graphique de Sardinas et Patterson sera :

(46)

Légende : les sommets correspondant aux mots de X sont doublement cerclés. L'étiquette de

chaque arc est un mot de l'ensemble X. Les "arcs croisés" sont tracés en pointillés et les "arcs

avant" en trait plein. Si l'arc est croisé, alors l'étiquette est uv, sinon c'est le mot x tel

que ux=v.

Dans notre exemple, il y a un chemin qui part de a et arrive en a. En vertu du théorème de

Sardinas et Patterson (que nous démontrerons lors de la prochaine mise à jour de ce chapitre),

l'ensemble X n'est pas un code (il aurait suffit d'un seul et unique chemin entre deux sommets

quelconques de X).

Théorème : L'ensemble X est un code si et seulement si il n'y a pas de chemin non trivial

dans , d'un sommet de X à un sommet de X (en d'autres termes, un ensemble X est un

code si et seulement si il n'y qu'un seul et unique chemin menant d'un sommet de à X à un

autre - ce sommet pouvant être le même comme dans l'exemple précédant)

commentaires (0)
Aucun commentaire n'a été pas fait
Écrire ton premier commentaire
Ceci c'est un aperçu avant impression
Chercher dans l'extrait du document
Docsity n'est pas optimisée pour le navigateur que vous utilisez. Passez à Google Chrome, Firefox, Internet Explorer ou Safari 9+! Téléchargez Google Chrome