Aborder les automates et les expressions regulieres par le code source, c’est encore prendre l’informatique par le bout du bricolage. Au mieux, on deviendra bricoleur, mais, en tant que tel, on ne sera jamais capable de construire l’equivalent logiciel d’un barrage. Pour passer a l’echelle, pour abstraire de nouveaux problemes, il faut de la theorie, et les automates sont la voie royale pour demontrer en quoi la theorie est efficiente.

Dans mon cours de compilation en anglais je presente la compilation des expressions regulieres vers les automates asynchrones (epsilon-NFA), et leur transformation en NFA puis DFA. Mais attention, en pratique, ce n’est peut-etre pas comme ca qu’il faut proceder, a cause de l’explosion possible du nombre d’etat (la determinisation est exponentielle dans le pire des cas, comme je le montre dans le cours Information Retrieval).

Quant a l’interet d’utiliser un langage fonctionnel pour implanter des automates, tout depend du type d’automate, du type d’application et du type de langage, ce n’est pas si simple. Evidemment, C est tres rapide. Mais si l’efficacite etait le seul critere, on pondrait de l’assembleur soi-meme, comme tu dis, et il y a de vraies bonnes raisons de ne pas faire cela (pas tout le temps). Si le type d’application est la recherche d’occurrences de chaines dans des chaines, et si les automates sont des DFAs, alors C est une bonne idee. Mais si les automates sont des automates a pile tres compliques pour generer des analyseurs syntaxiques, j’y reflechirais a deux fois avant d’envisager C (meme si ca se fait, par exemple Yacc).

L’inconvenient d’Erlang est l’absence de typage strict et fort a la compilation. Mais cette option a ses fans, comme pour Scheme et LISP. Moi j’accepte de ceder un peu de liberte contre une aide sans faille (d’aucuns diraient faciste:-) du compilateur.

On peut traduire pattern matching par filtrage de motifs.

L’interet d’une presentation algebriciste (osons) des automates et autre est qu’elle permet de s’abstraire d’un modele de machine ou de calcul particulier. Pas de memoire, pas de temps. Comme en maths. Tu deroules une equation jusqu’a trouver le resultat. Ca permet de comprendre le concept. Apres, et seulement apres, tu codes, et, la, tu fais autrement si tu juges que c’est plus efficace, par exemple, ou parce que tu n’as pas le choix (contraintes exterieures). Alors, evidemment, tu ne fais pas comme ca pour programmer un menu ou des widgets, attention, ce n’est pas de la religion, il faut etre pragmatique sans etre ignorant (donc connaitre la theorie et, eventuellement, ne pas s’en servir expres).

A mon avis, si on est bon en grammaire et en linguistique, comme toi, on n’a pas de mal a piger l’algebre des langages fonctionnels et la compilation (le calcul symbolique, en somme). Ca demande “seulement” d’oublier tout ce qu’on croit savoir sur la programmation et de lire les bons livres.

Et apres les langages fonctionnels, il faudrait jeter un petit coup d’oeil a la programmation a logiques, comme Prolog. C’est vraiment puissant et deconcertant. Tellement de belles choses a decouvrir…

En fait, c’est la faute de mes profs [ce ne peut pas être de ma faute, voyons !] : il n’ont jamais sû répondre à une question simple, que je leur posais souvent, du moins avant de décrocher. À quoi ça sert ? Désarmant n’est-ce-pas ?

Je suis passionné entre autres par les expressions régulières [?], les regex quoi, et j’ai toujours voulu en savoir plus sur “comment ça marche”. Mais la plupart du temps, les implémentations sont du type PCRE/NFA, et j’ai eu du mal à trouver de la doc abordable [du code source quoi ] sur les DFA. Mais si j’avais été à P6 au lieu de P7 j’en saurais plus à l’heure qu’il est…

Je vois bien comment un automate pourrait être plus facile/moins difficile à écrire en langage fonctionnel [enfin je n’en connais qu’un et si peu…]. Ce ne serait pas forcément plus rapide/efficace – difficile de faire mieux qu’en pur C je pense, enfin si y’aurait bien l’assembleur, mais je chipote nostalgiquement, là – avec du pattern matching [désolé pour les anglicismes, tout mon vocabulaire me vient de “là-bas”] à ne plus quoi savoir en faire.

Encore merci pour tout !

http://www-igm.univ-mlv.fr/~berstel/Elements/Elements.html

Berstel et Chretienne etaient mes profs a Paris VI, au siecle dernier. J’adore leur style, c’est rare de lire un textbook aussi bien redige, pas d’anglicisme, un francais impeccable qui ne prend pas le lecteur pour un lecteur de “Metro”, une structure logique, des definitions pour tous les concepts, une composition en LaTeX et des figures vraiment claires (attention, un automate est faux, ceci dit), en particulier le chapitre sur les arbres.

Quant aux automates finis, j’ai fait pas mal de redites entre mon cours de compilation (en anglais) et celui de recherche d’information, avec quelques differences dans le focus.

Ma presentation, comme toutes mes presentations, a volontairement un cachet algebrique, meme si ce n’est pas une veritable theorie algebrique des automates (c-a-d. j’utilise des ensembles, mais aussi des fonctions), car cela permet de s’abstraire des boucles et des pointeurs. Apres, libre a chacun d’implanter tout cela comme il veut ou peut (avec un langage fonctionnel, une presentation algebrique facilite toujours la tache, meme s’il faut parfois renoncer au tout fonctionnel pour des raisons d’efficacite). En tout cas, c’est la base de la base que tu as la, et j’ai bosse tres dur pour la rendre accessible (toutes les figures sont codees en LaTeX, en plus).

Si tu veux en savoir plus, ou plus sur un sujet particulier, n’hesite pas a me le demander ici ou par courrier.

Par exemple, si tu prevois d’appliquer la theorie des automates a la recherche efficate de texte dans du texte, il y a un excellent bouquin en francais la-dessus (les chercheurs francais sont tres bons dans ce domaines) que je peux te recommander.

En pensant a toi, j’ai mis en ligne quelques supports de plus. Il manque les sources, car je dois comprendre comment les integrer dans ma moulinette perso qui met automatiquement a jour mon site a partir de ma base Subversion de documents LaTeX.

Amuse-toi bien!

Le lien escamote vers le bouquin d’algo est Elements d’algorithmique. Quant a mon cours Information Retrieval, il contient quelques infos utiles sur les arbres digitaux (pour les dictionnaires). Au passage, si tu t’interesses a la recherche de chaines de caracteres dans du texte, ma presentation de l’algo de (Knuth,)Morris et Pratt est meilleure que celle de ce bouquin (une boucle en moins, non mais).

Pour les clefs, je comprends l’histoire de la dispersion de mes entiers – mais je n’ai pas ce souci, a priori. Et je n’aurai pas de collision, bikoze le logiciel qui produit se fichier se sert de ses clefs pour y retrouver ses cochons. Donc clefs uniques. Et mon approche Vikingesque de la collision de clefs serait l’écrasement des données précédentes Sans blague !

Tu es très clair, merci pour toutes ces explications… Que de choses à apprendre…

Si tes clefs sont uniques, ca n’implique pas que la table de hachage soit indiquee: si les clefs sont trop dispersees (sur l’ensemble des entiers), tu dois allouer (enfin, la lib qui te fourni la table) un tableau, donc un bout de memoire contigue, qui va etre sous-utilisee, car trouee… En fait, comme le paradoxe des anniversaires le suggere, les collisions de clefs sont rapidement tres probables, meme si les clefs sont dispersees uniformement. La gestion des elements dont les clefs sont en collisions peuvent etre simplement chaines (et donc accedes sous une meme clef, puis recherche dans cet arbre de collisions) ou, fin du fin, stockes dans un arbre de recherche equilibre (ceinture et bretelles).

Je ne sais pas si je suis clair…

arbres de recherche : hmmmm. Donc je pourrais mettre mes nœuds dans l’arbre dans l’ordre où ils arrivent, donc. La difficulté serait de bien balancer les branches, de façon à ne pas avoir un arbre qui penche tout du côté gauche… Hmmm… Partir de 1, et chaque fois que l’on descend, multiplier cet accumulateur par 2 et vérifier que l’on a stocké (accumulateur) nœuds à ce niveau avant de descendre d’un niveau. Mouais mouais mouais…

La table de hash marcherait bien dans mon cas je pense, car j’ai des clefs uniques pour chaque nœud – un bête numéro à la con. C’est d’ailleurs ce que j’utilisais dans la première version de mon parseur, avant de changer pour une bdd sqlite3 en mémoire [beaucoup plus rapide].

L’espagnol ne fait pas encore partie de mon paquetage… ça viendra peut-être un jour !

Il n’est pas besoin qu’il existe une “relation arborescente” naturelle entre elements d’un ensemble pour pouvoir les placer dans un arbre de recherche, il suffit juste d’avoir un ordre total sur l’ensemble (tu peux comparer toute paire d’elements). C’est toi qui choisi la relation d’ordre.

Les dictionnaires sont souvent implantes a base de tries, en francais arbres digitaux. Je cause un poil de ca dans mon cours Information Retrieval (le mot anglais trie provient de la troncature de retrieval). Les tables de hachages ne sont pas indiquees dans le cas des dictionnaires humains, me semble-t-il, a cause de la faible dispersion des codes de hachages (beaucoup de mots sont proches, par exemples partagent des prefixes a la pelle et une fonction a du mal a les disperser dans la table). Une table de hachage n’est efficace qu’en moyenne (par rapport au pire des cas), et a la condition d’avoir une bonne (dans un sens statistique) fonction de hachage — sinon gare au paradoxe des anniversaires (la probabilite d’avoir deux personnes au moins ayant meme date anniversaire est superieure a 50% des que le groupe compte plus de 23 personnes), et pourtant elles sont toutes independantes!

Je connais un dictionnaire de sanscrit par Gerard Huet, une grosse pointure… en logique formelle et programmation fonctionnelle, qui emploie la technique du trie (optimisee pour partager les suffixes). Cf. la page de G. Huet ainsi que ses publis de linguistiques informatique. Tu vas adorer ce qu’il fait!

Malheureusement, je ne comprends pas le jargon linguistique… J’aimerais comprendre la linguistique, vraiment. Je sens qu’il a encore matiere a croiser l’info et la linguistique de facon innovante. Bon, mais je comprends les langages fonctionnels, c’est deja ca. Je te felicite de vouloir comprendre les deux!

Ah, oui, interpreteur, quelle horreur. J’aime les langues. (Si tu lis l’espagnol, tu peux toujours acheter ma traduction de Pablo Neruda chez Gallimard, qui est bilingue.)

Allez, hop! Je retourne a mon probleme (J’essaie de faire accepter a Yacc une grammaire d’un langage vraiment abominable depuis deux semaines. En fait j’utilise un generateur d’analyseurs syntaxique plus puissant (LR(1)) mais c’est dur dur quand meme.) L’idee est de traduire ce langage vers les schemas XML.

Bon courage! [Et rassure-toi a propos de ton cerveau…]