Résultats

Pour des calculs d'un ordre de grandeur plus réaliste, nous avons utilisé 42 villes de France (figure B.11).

  

Figure: Résultat d'une exécution sur 42 villes de France (longueur du chemin : 2751,21).

    

Figure: Statistiques sur 1000 exécutions pour 42 villes.

Pour obtenir des statistiques valables, nous avons lancé 1000 fois le système sur ces données. La figure B.12(a) donne le nombre de fois où le programme a obtenu une longueur de chemin comprise, par exemple, entre 3000 et 3100 (133 fois, soit 13,3% des exécutions).

Ces résultats pourraient encore être améliorés, entre autres en utilisant un agent d'optimisation (malgré un bon résultat relatif à ceux fournis dans la figure B.12(a), le chemin de la figure B.11 reste optimisable facilement, notamment en supprimant les routes qui se croisent). Ceci serait, il est vrai, au détriment du nombre pour l'instant réduit d'agents exécutés. On pourrait aussi régler plus finement tous les paramètres de BASCET (tels la normalisation des valeurs d'urgence des agents, le nombre d'agents exécutés à chaque étape, etc.).

La complexité de l'algorithme (en terme d'agents exécutés, figure B.12(b)) est grosso modo linéaire (taille du problème : 42, nombre d'agents : de 52 à 85 -pour 500 exécutions). Les résultats étant en contrepartie non optimaux mais raisonnables, alors que le problème est NP-complet .

Les résultats obtenus sont satisfaisants dans la mesure où le but n'était pas une recherche de la solution optimale, mais bien une démonstration de la possibilité de traiter ce problème grâce à BASCET.

L'implantation de ce premier prototype en C++ nous a permis d'une part d'apprendre ce langage, et d'autre part d'exhiber quelques problèmes techniques et des améliorations. Certaines d'entre elles concernent l'apprentissage que la structure du modèle, proche des réseaux de Hopfield, devrait permettre (par exemple, par l'augmentation des proximités des liens fournis lors de bonnes résolutions du problème). De même, les algorithmes génétiques devraient permettre de régler plus automatiquement les paramètres de BASCET, au prix toutefois d'un grand nombre d'exécutions.

dilib    dilib est une plate-forme pour l'Ingénierie du Document et de l'Information Scientifiques et Techniques. Nous l'avons utilisé intensivement pour construire automatiquement le Réseau de Conceptsdu système (cf. page ) Cette plate-forme a été plus particulièrement conçue pour trois types d'applications :

• l'investigation documentaire ;
• la construction de Systèmes de Recherche d'information ;
• la constitution de plate-forme d'exploitation (avec des mises à jour) de l'information (dans ce dernier cas elle est principalement utilisée pour accompagner des logiciels plus traditionnels tels que les Systèmes de Gestion de bibliothèques).

Du point de vue technique, elle repose sur l'utilisation du standard SGML, ce qui permet de bénéficier des outils utilisables dans cet environnement, ainsi que de nombreux outils plus classiques du génie logiciel (par exemple les éditeurs lexicaux ou les analyseurs syntaxiques).

Elle tient également compte des contraintes introduites par la manipulation de gros volumes de données. Les solutions retenues utilisent fortement la philosophie Unix.

Dilib contient les éléments suivants:

• une bibliothèque de fonctions en langage C (manipulation de structures SGML par exemple) ;
• des commandes de manipulation de documents SGML ;
• des composants pour développer des systèmes d'information ;
• des exemples ;
• des interfaces avec logiciels « du marché ».

La figure C.1 montre le format que peut avoir une référence bibliographique de la base. La première étape est sa transformation, par un outil de la dilib, en sgml. La figure C.2 donne le résultat de cette transformation.

  

Figure: Exemple de référence en BIBTEX, de type article.

  

Figure: Référence BIBTEXtransformée en sgml.