Experimenter
Sommaire
5.1 Introduction
L’environnement Weka Experiment Environment permet à l’utilisateur de créer, faire fonctionner, modifier et analyser les essais d’une manière plus aisée que s’il fallait traiter les projets individuellement. Par exemple, l’utilisateur peut créer un essai pour faire fonctionner plusieurs projets à partir d’une série d’ensembles de données et analyser ensuite les résultats pour déterminer si l’un des projets est (statistiquement) meilleur que les autres.
L’Experiment Environment peut être mis en route à partir de la ligne de commandes en utilisant Simple CLI pour faire fonctionner le projet OneR sur l’ensemble de données Iris à l’aide d’un simple processus de train et de test. (Notez que les commandes doivent être écrites en une ligne dans le CLI).
java weka.filtres.supervised.attribut.AttributSelection \
-E “weka.attributSelection.CfsSubsetEval ” \
-S “weka.attributSelection.BestFirst -D 1 -N 5″ \
-b \
-i <input1.arff> \
-o <output1.arff> \
-r <input2.arff> \
-s <output2.arff>
Alors que les commandes peuvent être écrites directement dans le CLI, cette technique ne s’avère pas particulièrement pratique et les essais ne sont pas facilement modifiables. L’Experimenter se présente de deux manières possibles, soit avec une interface simple qui fournit la plupart des fonctionnalités nécessaires pour les essais, soit avec une interface donnant un accès complet aux fonctionnalités de l’Experimenter. Vous pouvez choisir l’une ou l’autre de ces configurations avec les boutons « Simple » et « Advanced » de l’Experiment Configuration Mode. Toutes deux vous permettent de mettre en place des essais standards, capables de fonctionner localement sur une seule machine, ou contrôler des essais réparties entre plusieurs ordinateurs. La répartition des essais permet de réduire le temps nécessaire à leur exécution. En revanche, la mise en place demande plus de temps.
La section suivante couvre les essais standards (« simple » et « Advanced », puis les essais contrôlés à distance et pour finir l’analyse des résultats.
5.2 Expériences standards
5.2.1 Simple
5.2.1.1 Nouvelle expérience
Après avoir cliqué New, des paramètres par défaut sont définis pour ce nouvel essai.
5.2.1.2 Finalité des résultats
Par défaut, les résultats en sortie sont adressés à un fichier ARFF. Néanmoins, il vous est possible de choisir entre :
• ARFF file
• _____CSV file
• JDBC database
Les fichiers ARFF et base de données JDBC sont traités plus loin dans les sections suivantes. CSV est comparable à ERFF mais peut être utilisé pour être chargé dans une application extérieure de tableur.
Fichier ARFF
Si le nom de fichier est vide, un fichier temporaire sera créé dans le répertoire TEMP du système. Si l’on veut spécifier un fichier de résultats de manière précise, il suffit de cliquer sur Browse et de choisir un nom de fichier (par exemple Experiment1.arff).
Cliquez sur Save et le nom apparaître dans le champ d’édition à côté du fichier ARFF.
L’avantage des fichiers ARFF ou CSV, c’est qu’ils peuvent être créés sans aucune classe supplémentaire à côté de celles de WEKA. L’inconvénient est qu’il est impossible de reprendre un essai qui a été interrompu, par exemple suite à une erreur, ou l’addition d’un ensemble de données ou d’algorithmes. Pour les essais demandant un laps de temps important, ceci peut s’avérer très ennuyeux.
Base de données JDBC
Avec JDBC, il est facile de stocker les résultats dans une base de données. Les archives jar nécessaires doivent se trouver dans le CLASSPATH pour permettre l’accès aux fonctionnalités spécifiques d’une base de données.
Après avoir changé le fichier ARFF en base de données JDBC, cliquez sur User… afin de spécifier l’URL JDBC ainsi que les paramètres de confidentialité pour l’accès à la base de données.
Après avoir fourni les données nécessaires et cliqué sur OK, l’URL de la fenêtre principale est mise à jour.
Note : à cette étape, la connexion à la base de données n’a pas été testée. Ceci n’est effectué que lorsque l’essai est lancé.
L’avantage d’une base de données JDBC est qu’il est possible de reprendre un essai qui a été interrompu ou étendu. Au lieu de faire fonctionner de nouveau toutes les autres combinaisons d’algorithmes et d’ensemble de données, seules les combinaisons manquantes sont calculées.
5.2.1.3 Type d’expérience
L’utilisateur peut choisir entres les trois types suivants :
- Cross validation (par défaut) effectue une validation croisée stratifiée à partir du nombre de dimensions.
- Train/Test Percentage Split (données randomisées) partage un ensemble de données en fonction du pourcentage donné dans un fichier de train et de test (on ne peut spécifier aucun fichier explicite de training et de test dans l’Experimenter) après que l’ordre des données ait été randomisé et stratifié.
- Train/Test Percentage Split (ordre préservé) car il est impossible de spécifier la moindre paire explicite de fichier s Train/Test, on peut abuser de ce type pour défaire la combinaison d’un fichier combiné de train et de test pour récupérer les deux fichiers originels (il ne suffit que de trouver le pourcentage correct).
- De plus, on peut choisir entre Classification et Régression en fonction des ensembles de données et des classifiers utilisés. Pour les arborescences de décisions comme J48 (L’implémentation Weka du C4.5 de Quinlan et l’ensemble de données IRIS, Classification est nécessaire, tandis que pour un classifier numérique comme M5P, Régression est nécessaire. Classification est choisi par défaut. Note : Si les splits de pourcentage sont utilisés, il faut s’assurer que la paire T-Tester continue de produire des résultats sensibles avec le taux donné.
5.2.1.4 Datasets
Il est possible d’ajouter des fichiers d’ensemble de données avec un chemin d’accès absolu ou relatif. Ce dernier rend bien souvent plus facile le contrôle d’expériences sur des machines différentes, et il est donc nécessaire de cocher Use relative paths, avant de cliquer sur Add new….
Dans ce cas, ouvrir le répertoire de données data et choisir l’ensemble de données iris.arff.
Après avoir cliqué sur Open, le fichier sera réparti dans la liste des ensembles de données. Si on sélectionne un répertoire et que l’on clique ensuite sur Open, alors tous les fichiers ARFF vont être ajoutés de manière récurrente. Les fichiers peuvent être effacés de la liste en les sélectionnant et en cliquant ensuite sur Delete selected.
Les fichiers ARFF ne sont pas le seul format que l’on puisse charger, mais tous les fichiers que l’on puisse convertir avec les « Core converters » de Weka. Les formats suivants sont actuellement supportés :
• ARFF (+ compressed)
• C4.5
• CSV
• libsvm
• binary serialized instances
• XRFF (+ compressed)
Par défaut, l’attribut de classe est censé être le dernier attribut. Cependant, si un format de données contient les informations relatives à l’attribut de classe, comme XRFF ou C4.5, cet attribut sera utilisé à la place.
5.2.1.5 Contrôle des itérations
- Number of repetitions : Afin d’obtenir des résultats pertinents sur un projet statistiques, le nombre par défaut d’itérations est 10. Dans le cas d’une validation croisée de plus de 10 dimensions, cela signifie qu’il y aura 100 sollicitations d’un classifier contenant les données de training et de test.
- Data sets first/Algorithms first : Dès que l’on a plus d’un ensemble de données et d’un algorithme, il peut être utile d’échanger l’ordre des algorithmes et des ensembles de données à itérer. C’est notamment le cas lorsque l’on stocke les résultats dans un ensemble de données et que l’on souhaite compléter les résultats pour tous les ensemble de données et pour l’algorithme, dès que possible.
5.2.1.6 Algorithmes
De nouveaux algorithmes peuvent être ajoutés grâce au bouton Add new… Ouvrir cette boîte de dialogue pour la première fois permet de faire apparaître une présentation de ZeroR, ou bien, celle qui a été sélectionnée en dernier.
Avec le bouton Choose, on peut ouvrir le GenericObjectEditor et choisir un autre classifier.
Le bouton Filter… permet de souligner les classifiers capable de gérer certains types d’attributs et de classes. Avec le bouton Remove filter, toutes fonctionnalités sélectionnées vont être supprimées et le surlignage va de nouveau disparaître.
Des algorithmes supplémentaires peuvent être ajoutés de nouveau avec le bouton Add new…. Par exemple, une arborescence J48.
Après avoir spécifié les paramètres du classifier, on clique sur OK pour l’ajouter à la liste des algorithmes.
Avec les boutons Load options… et Save options… on peut charger et sauvegarder le paramétrage d’un classifier sélectionné à partir ou vers un XML. Cette possibilité s’avère particulièrement utile pour les classifiers hautement configurés (par exemple, les meta-classifiers imbriqués), là où une configuration manuelle nécessite un certain temps, et pour des classifiers utilisés régulièrement.
Il est également possible de copier-coller les options en cliquant-droit (ou Alt-Shift- Clic-gauche) et en sélectionnant le point de menu approprié à partir du popup, afin soit d’additionner un nouveau classifier, soit de remplacer le classifier sélectionné avec une nouvelle configuration. Cette opération est utile pour transférer le paramétrage d’un classifier de l’Explorer Weka vers l’Experimenter sans avoir à reprendre l’installation depuis le tout début.
5.2.1.7 Sauvegarder les paramètres
Pour une future utilisation, il est possible de sauvegarder le paramétrage actuel d’une expérience dans un fichier en cliquant sur Save… en haut de la fenêtre.
Par défaut, le format des fichiers d’expérience est le format binaire que la publication en série de Java propose. L’inconvénient de ce format est l’éventuelle incompatibilité entre les différentes versions de Weka. Le format XML est une alternative plus fiable au format binaire.
Les expériences antérieures sauvegardées peuvent être chargées à nouveau par le biais du bouton Open…
5.2.1.8 Mener une expérience
Pour mener l’expérience actuelle, cliquez sur la touche Run en haut de la fenêtre Experiment Environment. L’expérience actuelle est en mesure d’effectuer 10 tentatives de validation-croisée de 10 dimensions stratifie sur l’ensemble de données Iris en utilisant la combinaison ZeroR et J48.
Cliquez sur Start pour démarrer l’expérience.
Si l’expérience a été définie correctement, les trois messages ci-dessus vont apparaître dans le panneau Log. Les résultats de l’expérience sont sauvegardés dans l’ensemble de données Experiment1.arff.
5.2.2 Avancé
5.2.2.1 Définir une expérience
Quand l’Experimenter est lancé en mode avancé (Advanced Mode), le bouton Setup apparaît. Cliquez sur New pour initialiser une expérience. Ceci va permettre de définir les paramètres par défaut de l’expérience.
Pour définir les ensembles de données à traiter dans un projet, d’abord sélectionner Use relative paths dans le panneau Dataset de la touche Setup et cliquer ensuite sur Add new… afin d’ouvrir une fenêtre de dialogue.
Double cliquer sur le folder de données pour visualiser les ensembles de données disponibles ou naviguer vers un autre emplacement. Sélectionner iris.arff et cliquer sur Open pour sélectionner l’ensemble de données Iris.
Le nom de l’ensemble de données est maintenant affiché dans le panneau Datasets de l’onglet Setup.
Sauvegarder les résultats de l’expérience
Pour identifier un ensemble de données vers qui envoyer les résultats, cliquer sur l’entrée InstancesResultListener dans le panneau Destination. Le paramètre de fichier en sortie se situe vers le bas de la fenêtre, à côté du texte outputFile. Cliquer sur ce paramètre pour afficher une fenêtre de sélection de fichier.
Taper le nom du fichier en sortie et cliquer Select. Le nom du fichier est présenté dans le panneau outputFile. Cliquer sur OK pour fermer la fenêtre.
Le nom de l’ensemble de données est présenté dans le panneau Destination de l’onglet Setup.
Sauvegarder la définition de l’expérience (Experiment Definition)
La définition de l’expérience peut être sauvegardée à n’importe quel moment. Sélectionner Save… en haut de l’onglet Setup. Taper le nom de l’ensemble de données avec l’extension exp (ou sélectionner le nom de l’ensemble de données si l’ensemble de données de la définition de l’expérience existe déjà) pour les fichiers binaires ou choisir les fichiers de configuration des expériences (Experiment configuration files) (*.xml) à partir de la boîte des types de fichiers (les fichiers XML sont solides et supportent les changements de versions).
L’expérience peut être restaurée en sélectionnant Open dans l’onglet Setup en sélectionnant Experiment1.exp dans la fenêtre de dialogue.
5.2.2.2 Mener une expérience
Pour mener l’expérience en cours, cliquer sur l’onglet Run en haut de la fenêtre Experiment Environment. L’expérience actuelle effectue 10 essais au hasard de train et de test sur l’ensemble de données Iris, en utilisant 66 des modèles de training et 34% pour le test, et en utilisant le projet ZeroR.
Cliquer Start pour démarrer l’expérience.
Si l’expérience a été définie correctement, les trois messages ci- dessus apparaissent dans le panneau Lof. Les résultats de l’expérience sont sauvegardés dans l’ensemble de données Experiment1.arff. Les quelques premières lignes dans cet ensemble de données sont listées ci-dessous :
@relation InstanceResultListener
@attribut Key_Dataset {iris}
@attribut Key_Run {1,2,3,4,5,6,7,8,9,10}
@attribut Key_Scheme {weka.classifiers.Règles.ZeroR,weka.classifiers.trees.J48}
@attribut Key_Scheme_options {,’-C 0.25 -M 2’}
@attribut Key_Scheme_version_ID {48055541465867954,-217733168393644444}
@attribut Date_time numeric
@attribut Number_of_training_instances numeric
@attribut Number_of_testing_instances numeric
@attribut Number_correct numeric
@attribut Number_incorrect numeric
@attribut Number_unclassified numeric
@attribut Percent_correct numeric
@attribut Percent_incorrect numeric
@attribut Percent_unclassified numeric
@attribut Kappa_statistic numeric
@attribut Mean_absolute_error numeric
@attribut Root_mean_squared_error numeric
@attribut Relative_absolute_error numeric
@attribut Root_relative_squared_error numeric
@attribut SF_prior_entropy numeric
@attribut SF_scheme_entropy numeric
@attribut SF_entropy_gain numeric
@attribut SF_mean_prior_entropy numeric
@attribut SF_mean_scheme_entropy numeric
@attribut SF_mean_entropy_gain numeric
@attribut KB_information numeric
66 CHAPTER 5. EXPERIMENTER
@attribut KB_mean_information numeric
@attribut KB_relative_information numeric
@attribut True_positive_rate numeric
@attribut Num_true_positives numeric
@attribut False_positive_rate numeric
@attribut Num_false_positives numeric
@attribut True_negative_rate numeric
@attribut Num_true_negatives numeric
@attribut False_negative_rate numeric
@attribut Num_false_negatives numeric
@attribut IR_precision numeric
@attribut IR_recall numeric
@attribut F_measure numeric
@attribut Area_under_ROC numeric
@attribut Time_training numeric
@attribut Time_testing numeric
@attribut Summary {’Number of leaves: 3\nSize of the tree: 5\n’,
’Number of leaves: 5\nSize of the tree: 9\n’,
’Number of leaves: 4\nSize of the tree: 7\n’}
@attribut measureTreeSize numeric
@attribut measureNumLeaves numeric
@attribut measureNumRègles numeric
@data
iris,1,weka.classifiers.Règles.ZeroR,,48055541465867954,20051221.033,99,51,
17,34,0,33.333333,66.666667,0,0,0.444444,0.471405,100,100,80.833088,80.833088,
0,1.584963,1.584963,0,0,0,0,1,17,1,34,0,0,0,0,0.333333,1,0.5,0.5,0,0,?,?,?,?
5.2.2.3 Changer les paramètres de l’expérience
Changer le classifier
Les paramètres d’une expérience peuvent être changés en cliquant sur le panneau Result generator.
Le RandomSplitResultProducer effectue des essais répétés de train et de test. Le nombre d’essais (exprimé en pourcentage) utilisé pour le training est donné dans la boîte trainPercent. (Le nombre d’essais est spécifié dans le panneau Runs de la touché Setup). Un petit fichier d’aide peut être affiché en cliquant sur More dans le panneau About.
Cliquer sur l’entrée splitEvaluator pour afficher les propriétés du SplitEvaluator.
Cliquer sur l’entrée du classifier (ZeroR) pour presenter les proprieties du projet.
Ce projet n’a pas de propriétés modifiables (en plus du mode debug on/off) mais la plupart des autres projets ont des propriétés qui peuvent être modifiés par l’utilisateur. Le bouton Capabilities ouvre une petite boîte de dialogue listant tous les types d’attributs et de classes que ce classifier peut gérer. Cliquer sur le bouton Choose pour sélectionner un projet différent. La fenêtre ci-dessous montre les paramètres disponibles pour le projet d’arborescence de décision J48. Si nécessaire, modifier les paramètres et cliquer sur Ok pour fermer la fenêtre.
Le nom du nouveau projet s’affiche dans le panneau Result generator.
Ajouter des projets supplémentaires
Les projets supplémentaires peuvent être ajoutés dans le panneau Generator properties. Pour commencer, changer l’entrée de la liste déroulante de Disabled à Enabled dans le panneau Generator properties.
Cliquer sur Select property et étendre le splitEvaluator de manière à ce que l’entrée du classifier soit visible dans la liste de proprieties ; cliquer sur Select.
Le nom du projet est affiché dans le panneau Generator properties.
Pour ajouter un autre projet, cliquer sur le bouton Choose pour afficher la fenêtre GenericObjectEditor.
Le bouton Filter…. permet de surligner les classifiers capable de gérer certains types d’attributs et de classes. Avec le bouton Remove filter, toutes les fonctionnalités sélectionnées vont être effaces et le surlignage va disparaître de nouveau.
Pour le changer en arborescence de décision, sélectionner J48 (dans les arborescences de sous-groupes).
Le nouveau projet est ajouté au panneau Generator properties. Cliquer sur Add pour ajouter le nouveau projet.
Désormais, à chaque fois qu’une nouvelle expérience est démarrée, les résultats sont générés pour les deux projets. Pour ajouter des projets supplémentaires, recommencer l’opération. Pour enlever un projet, sélectionner le projet en cliquant dessus puis cliquer sur Delete.
Ajouter des datasets supplémentaires
Les projets peuvent être gérés quelque soit le nombre d’ensembles de données simultanés. Les ensembles de données supplémentaires sont ajoutés en cliquant sur Add new… dans le panneau Datasets. Les ensembles de données sont effaces de l’expérience en sélectionnant l’ensemble de données puis en cliquant sur Delete Selected.
Les données en sortie brutes
Les données en sortie brutes générées par un projet au cours d’une expérience peuvent être sauvegardées dans un fichier puis examinées plus tard. Ouvrir la fenêtre ResultProducer en cliquant sur le panneau Result generator dans l’onglet Setup.
Cliquer sur rawOutout et sélectionner l’entrée True dans la liste déroulante. Par défaut, les données en sortie sont envoyées au fichier zip splitEvaluatorOut.zip. Le fichier de sortie peut être changé en cliquant sur le fichier outputFile dans la fenêtre. Maintenant, quand une expérience est mise en route, le résultat de chaque essai est archivé comme ci-dessous.
Le contenu du premier essai est :
ClassifierSplitEvaluator: weka.classifiers.trees.J48 -C 0.25 -M 2(version
-217733168393644444)Classifier model:
J48 pruned tree
——————
petalwidth <= 0.6: Iris-setosa (33.0)
petalwidth > 0.6
| petalwidth <= 1.5: Iris-versicolor (31.0/1.0)
| petalwidth > 1.5: Iris-virginica (35.0/3.0)
Number of Leaves : 3
Size of the tree : 5
Correctly Classified Instances 47 92.1569 %
Incorrectly Classified Instances 4 7.8431 %
Kappa statistic 0.8824
Mean absolute error 0.0723
Root mean squared error 0.2191
Relative absolute error 16.2754 %
Root relative squared error 46.4676 %
Total Number of Instances 51
measureTreeSize : 5.0
measureNumLeaves : 3.0
measureNumRègles : 3.0
5.2.2.4 Autres producteurs de résultats
Le pipeline d’analyse de validation croisée
Pour passer d’expériences de random train et test à des expériences de validation croisée, cliquer sur l’entrée Result generator. En haut de la fenêtre, cliquer sur la liste déroulante et sélectionner CrossValidationResultProducer. La fenêtre contient désormais les paramètres spécifiques à la validation croisée comme le nombre de partitions/dimensions. L’expérience effectue une validation croisée à dix dimensions au lieu du train et test de l’exemple donné.
Le panneau Result generator indique alors que la validation croisée va avoir lieu. Cliquer sur More pour générer une brève description du CrossValidationResultProducer.
Tout comme avec le RandomSplitResultProducer, de nombreux projets peuvent être démarrés au cours de la validation croisée en les ajoutant au panneau Generator properties.
Le nombre d’essais est paramétré sur 1 dans l’onglet Setup de cet exemple, de manière à ce qu’un seul essai de validation croisée soit effectué pour chaque projet et ensemble de données. Quand cette expérience est analysée, les résultats suivants sont générés. Notez qu’il y a 30 (1 détermine le temps pour 10 dimensions qui déterminent le temps pour 3 projets) lignes de résultats traitées.
Averaging Result Producer
L’AveragingResultProducer est une alternative au CrossValidationResultProducer. Ce producteur de résultats prend la moyenne d’un ensemble d’essais (qui sont typiquement des essais de validation croisée). Ce pipeline d’analyses est identifié en cliquant sur l’AveragingResultProducerdu GenericObjectEditor.
Le fichier d’aide associé est présenté ci-dessous.
Cliquer sur le panneau ResultProducer fait apparaître la fenêtre suivante.
Comme avec les autres ResultProducers, des plans supplémentaires peuvent être définis. Quand l’AveragingResultProducer est utilisé, la propriété du classifier est située plus profondément dans la hiérarchie des propriétés du Generator.
Dans cette expérience, les projets ZeroR, OneR et J48 sont lances 10 fois avec une validation croisée à 10-dimensions. Chaque ensemble de 10 dimensions de validations croisées est ainsi équilibré à la moyenne, ce qui produit une ligne de résultats pour chaque essai (au lieu d’une ligne de résultats pour chaque dimension, comme dans l’exemple précédent utilisant le CrossValidationResultProducer) pour un total de 30 lignes de résultats. Si les sorties brutes sont sauvegardées, les 300 résultats sont tous archivés.
Explicit Test-Set Result Producer
L’un des inconvénients majeurs de l’Experimenter dans le passé était son incapacité à fournir des ensembles tests. Bien que des essais répétés avec des ensembles tests explicites ne soient pas (excepté pour la randomisation des données de training, afin de tester la solidité du classifier), ceci permet de comparer différents classifiers et les paramètres des classifiers côte-à-côte, caractéristique qui manque à l’Explorer. Ce pipeline d’analyse peut être utilisé en cliquant sur le panneau Result generator puis en choisissant l’ExplicitTestSetResultProducer à partir du GenericObjectEditor.
Le fichier d’aide associé est présenté ci-dessous.
L’installation de l’expérience utilisant des ensembles de tests explicites requiert un peu plus de soin que les autres. La raison est que le pipeline d’analyse n’a aucune information sur le fichier d’où proviennent les données. Afin d’identifier l’ensemble de test qui convient, ce pipeline d’analyse utilise le nom de la relation du fichier de training. Voici comme le nom de fichier se construit sous un système base sur Unix (linux, Mac OSX), fondé sur le paramétrage du pipeline d’analyses et sur le nom de la relation de l’ensemble de training actuel :
testsetDir “/” testsetPrefix + relation-name + testsetSuffix
With the testsetDir property set to /home/johndoe/datasets/test, an empty
testsetPrefix, anneal as relation-name and the default testsetSuffix, i.e.,
test.arff, the following file name for the test set gets created:
/home/johndoe/datasets/test/anneal_test.arff
NB : Le pipeline d’analyse est compatible avec des plates-formes et utilisé le backslashes (barres obliques inverses) plutôt que les forward slashes (barres obliques) sur les systèmes basés sur MS Windows. Naturellement, il se peut que le nom de la relation ne soit pas toujours aussi simple que dans l’exemple ci- dessus, en particulier quand l’ensemble de données a été prétraité avec différents filtres avant d’être utilisé dans l’Experimenter. Le pipeline d’analyse ExplicitTestSetResultProducer permet de retirer les chaînes non désirées des noms de relation en utilisant des expressions classiques. Dans le cas d’un retrait des paramètres du filtre WEKA qui a été joint au nom de la relation pendant la phase de prétraitement, on peut utiliser tout simplement use-weka.* comme valeur pour relationFind et laisser relationReplace vide. Utiliser ce paramètre, le nom de relation suivant : annealweka.filtres.unsupervised.instance.RemovePercentage-P66.0 deviendra : anneal. Tant que l’on y prend garde et que l’on utilise les noms de relations, l’ExplicitTestSetResultProducer peut être utilisé pour comparer les différents classifiers et paramètres sur les paires train/test, en utilisant toutes les fonctionnalités de l’Experimenter.
5.3 Mener des expériences à distance
Mener des expériences à distance vous permet de répartir la charge informatique sur plusieurs ordinateurs. Plus loin; nous allons parler de l’installation et du fonctionnement pour HSQLDB et MySQL.
5.3.1 Préparation
Pour mener une expérience à distance, il vous faudra :
- Un serveur de base de données
- Plusieurs ordinateurs sur lesquels faire tourner les moteurs
- Editer le fichier de politique de contrôle à distance des moteurs inclus dans la répartition Weka, e manière à permettre au chargement de classe et d’ensembles de données Java de charger à partir de votre répertoire.
- Un protocole RMI de l’Experimenter sur une machine (quelle qu’elle soit)
Pour les exemples suivants, on imagine un utilisateur appelé johndoe avec le paramétrage suivant :
- Accès à un ensemble d’ordinateurs faisant tourner une gamme d’Unix (les chemins d’accès doivent être changes pour Windows).
- Le répertoire home est situé à /home/johndoe.
- Weka se trouve à /home/johndoe/weka.
- Les archives jar supplémentaires, par exemple les drivers JDBC, sont stockés dans /home/johndoe/jars.
- Le répertoire pour les ensembles de données est /home/johndoe/datasets.
Note : le fichier de politique d’exemple remote.policy.example utilise ce paramètre (disponible dans weka/experiment1).
5.3.2 Installation du serveur d’ensemble de données
- HSQLDB
- Télécharger le driver JDBC pour HSQLDB, extraire le hsqldb.jar et le placer dans le répertoire /home/johndoe/jars.
- Pour installer le serveur d’ensembles de données, choisir ou créer un répertoire à partir duquel faire fonctionner le serveur de bases de données, et démarrer le serveur avec :java -classpath /home/johndoe/jars/hsqldb.jar \org.hsqldb.Server \database.0experiment-dbname.0experiment
Note : cette opération va permettre de construire une base de données avec l’alias “experiment” (-dbname.0<alias>) et de créer les proprieties et le fichier log à l’emplacement actuel préfixée “experiment” (-database.0 <file>). Le code source 1Weka peut être trouvé dans l’archive weka- src.jar ou obtenue à partir de Subversion.
- MySQL
Nous n’entrerons pas dans les détails de l’installation d’un serveur MySQL, mais c’est direct et cela inclut les étapes suivantes :
- Télécharger la version appropriée de MySQL pour votre serveur
- Installer et lancer le serveur MySQL
- Créer une base de données (pour notre exemple, nous allons utiliser l’expérience comme nom de base de données.)
- Télécharger le driver JDBC approprié, extraire le jar JDBC et le placer en tant que mysql.jar in /home/johndoe/jars.
5.3.3 Paramétrer le moteur à distance
- Tout d’abord, créer un répertoire pour les fichiers de scripts et de police : /home/johndoe/remote_engine
- Dézipper le remoteExperimentServer.jar (à partir de la répartition Weka ou le construire à partir des sources2 avec un remotejar) dans un répertoire temporaire.
- Ensuite, copier remoteEngine.jar et remote.policy.example vers le répertoire moteur /home/johndoe/remote
- Créer un script, appelé /home/johndoe/remoteengine/startRemoteEngine quand vous êtes sur Linux/Unix) :
- HSQLDB java- Xmx256m\weka.experiment.RemoteEngine&
- MySQL java\classpath/home/johndoe/jars/mysql.jar:remoteEngine.jar\Djava.security.policy=remote.policy\weka.experiment.RemoteEngine&
- Maintenant, nous allons commencer le contrôle à distance des moteurs effectuant les expériences sur les ordinateurs à distance (notez que la même version de Java doit être utilisée pour l’Experimenter et les moteurs gérés à distance) :
- Renommer le fichier remote.policy.example en remote.policy
- Pour chacune des machines sur lesquelles vous voulez lancer un moteur à distance :
¤ effectuer un ssh sur la machine. Le code source Weka2 peut être trouvé dans l’archive weka-src.jar ou obtenu à partir de Subversion
¤ effectuer un cd vers /home/johndoe/remote engine.
¤ Lancer /home/johndoe/startRemoteEngine (pour permettre aux moteurs à distance d’utiliser plus de mémoire, modifier l’option –Xmx dans le script startRemoteEngine).
5.3.4 Configurer l’Experimenter
Maintenant, nous allons faire tourner l’Experimenter :
- HSQLDB
- Copier le fichier DatabaseUtils.props.hsql de weka/experiment dans l’archive weka.jar vers le répertoire /home/johndoe/remote engine et le renommer en DatabaseUtils.props.
- Editer ce fichier et changer l’entrée ”jdbcURL=jdbc:hsqldb:hsql://server name/database name” pour inclure le nom de la machine qui fait fonctionner votre serveur de base de données (par exemple, jdbcURL=jdbc:hsqldb:hsql://dodo.company.com/experiment).
- Maintenant, démarrer l’Experimenter (à l’intérieur du répertoire) :java \cp /home/johndoe/jars/hsqldb.jar:remoteEngine.jar:/home/johndoe/weka/weka.jar \ Djava.rmi.server.codebase=file:/home/johndoe/weka/weka.jar \weka.gui.experiment.Experimenter
- MySQL
- Copier le fichier DatabaseUtils.props.mysql à partir de weka/experiment dans l’archive weka.jar vers le répertoire /home/johndoe/remote engine et le renommer en DatabaseUtils.props.
- Editer ce fichier et changer l’entrée ”jdbcURL=jdbc:mysql://server name:3306/database name” de façon à inclure le nom de la machine qui gère votre serveur base de données et le nom de la base de données dans laquelle le résultat sera stocké (par exemple jdbcURL=jdbc:mysql://dodo.company.com:3306/experiment).
- Maintenant, démarrer l’Expérimenter (dans ce répertoire) : java \cp /home/johndoe/jars/mysql.jar:remoteEngine.jar:/home/johndoe/weka/weka.jar \Djava.rmi.server.codebase=file:/home/johndoe/weka/weka.jar \weka.gui.experiment.Experimenter
Note : Le nom de l’expérience de la base de données peut toujours être modifié dans l’Experimenter. Ceci n’est que le paramétrage par défaut.
Maintenant, nous allons configurer l’expérience :
- Tout d’abord, sélectionner le mode avancé (Advanced mode) dans l’onglet Setup
- Choisissez maintenant le DatabaseResultListener dans le panneau Destination. Configurer ce pipeline d’analyse :
- HSQLDB
Préciser la valeur sa pour le nom d’utilisateur et laisser le mot de passe vide.
- MySQL
Fournir le nom d’utilisateur et le mot de passé dont vous avez besoin pour vous connecter à la base de données.
- A partir du panneau Result generator, choisir soit le CrossValidationResultProducer soit le RandomSplitResultProducer (ce sont les pipes d’analyse les plus communément utilisés) puis configure les détails restant de l’expérience (par exemple, les ensembles de données et les classifiers).
- Maintenant, active le panneau Distribute Experiment en cochant dans la boîte de cases à cocher
- Cliquer sur le bouton Hosts et entrer les noms des machines sur lesquelles vous avez lance les moteurs à distance (<Enter> ajoute l’hôte à la liste).
- Vous pouvez choisir de le distribuer par essai ou ensemble de données.
- Sauvegarder la configuration de votre expérience
- Maintenant, commencez votre expérience comme vous le feriez normalement.
- Vérifier vos résultats dans l’onglet Analyse en cliquant soit sur le bouton Database, soit sur le bouton Experiment.
5.3.5 Support Multi-Cœur
Si vous voulez utiliser toutes les mémoires d’une machine multi-cœur, ensuite, vous pouvez en faire autant avec toute version Weka ultérieure à 3.5.7. Tout ce que vous avez à faire est de définir le port ainsi que le nom de l’hôte dans l’Experimenter (format : nom d’hôte : port) puis de démarrer le moteur à distance (RemoteEngine) avec l’option –p, en spécifiant le port à écouter.
5.3.6 Résolution des problèmes
- Si vous avez une erreur au début d’une expérience qui ressemble à ceci :
01:13:19: RemoteExperiment (//blabla.company.com/RemoteEngine)
(sub)experiment (datataset vineyard.arff) failed :
java.sql.SQLException: Table already exists: EXPERIMENT INDEX
in statement [CREATE TABLE Experiment index ( Experiment type
LONGVARCHAR, Experiment setup LONGVARCHAR, Result table INT )]
01:13:19: dataset :vineyard.arff RemoteExperiment
(//blabla.company.com/RemoteEngine) (sub)experiment (datataset
vineyard.arff) failed : java.sql.SQLException: Table already
exists: EXPERIMENT INDEX in statement [CREATE TABLE
Experiment index ( Experiment type LONGVARCHAR, Experiment setup
LONGVARCHAR, Result table INT )]. Scheduling for execution on
another host.
alors, ne paniquez pas – cette erreur se produit parce que plusieurs machines à distance essayent simultanément de créer le même tableur et se trouvent temporairement verrouillées – ceci va se solutionner tout seul, il n’est pas utile d’interrompre l’expérience. En fait, ceci prouve que l’expérience fonctionne !
- Si vous avez publié en série une expérience et modifie ensuite votre fichier DatabaseUtils.props suite à une erreur (par exemple un type-mapping manquant), l’Experimenter va utiliser le DatabaseUtils.props que vous aviez au moment où vous avez lance l’expérience en série. Gardez à l’esprit que le processus de mise en série va également publier en série la classe DatabaseUtils et par conséquent stocke votre fichier props (props-file) ! Ceci est une autre raison pour stocker vos expériences comme des XML et non au format binaire des produits de publication en série Java.
- Utiliser un fichier DatabaseUtils.props incomplet ou corrompu peut augmenter des erreurs d’interface étranges, par exemple désactiver le “use” du bouton User ainsi que l’URL à côté de la base de données URL. En cas de doute, copier un DatabaseUrils.props propre à partir de Subversion.
- Si vous avez NullPointerException at java.util.Hashtable.get() dans le moteur à distance (RemoteEngine) ne vous inquiétez pas. Ceci n’a aucune incidence sur l’expérience.
5.4 Analyser les résultats
5.4.1 Installation (setup)
Weka inclut un analyseur d’expérience qui puisse être utilisé pour analyser les résultats des expériences (dans cet exemple, les résultats ont été envoyés à un InstancesResultListener). L’expérience ci-dessous utilise trios plan, ZeroR, OneR, et J48, pour classifier les données Iris dans une expérience utilisant 10 essais train et test, avec 66% des données utilisées pour le training et 34% utilisées pour le testing.
Une fois que le paramétrage est complet, lancez l’expérience. Puis pour analyser les résultats, sélectionnez l’onglet Analyse en haut de la fenêtre Experiment Environment.
Cliquez sur Experiment pour analyser les résultats de l’expérience en cours.
Le nombre de lignes de résultats disponibles (Got 30 results) apparaît dans le panneau Source. Cette expérience consistait en dix essais, pour trois plans, pour 1 ensemble de données, pour un total de 30 lignes de résultats. Les résultats peuvent également être charges à partir d’un fichier d’expérience antérieur, en cliquant sur File et en chargeant le fichier .arff de résultats qui convient. De même, les résultats envoyés à une base de données (en utilisant le databaseResultListener) peuvent être chargés à partir de la base de données. Sélectionner l’attribut Percent_correct à partir du champ Comparison et cliquer sur Perform test pour générer une comparaison entre les trois projets.
Les projets utilisés dans l’expérience apparaissent dans les colonnes et les ensembles de données son affichés dans les files. Le pourcentage pour chacun des 3 projets apparaît dans la file de chaque ensemble de données : 33,33% pour ZeroR, 94,31% pour OneR et 94,90% pour J48. L’annotation v ou * indique qu’un résultat spécifique est statistiquement meilleur (v) ou pire (*) que la baseline établie par ZeroR. En bas de chaque colonne après la première colonne est le total (xx/yy/zz) ou du nombre de fois que le projet s’est avéré meilleur que (xx), similaire à (yy) ou pire que (zz) le plan de base sur les ensembles de données utilisé dans l’expérience. Dans cet exemple, il n’y avait qu’un ensemble de données et OneR s’est avéré meilleur que Zero Rune fois, et jamais similaire nip ire ZeroR (1/0/0) ; J48 s’est également révélé meilleur que ZeroR sur l’ensemble de données.
La déviation standard de l’attribut en cours d’évaluation peut être générée en cochant la case Show std.deviations puis de nouveau Perform test.
La valeur (10) au début de la file iris représente le nombre d’estimations utilisées pour calculer la déviation standard (le nombre d’essais dans ce cas).
Choisir Number_correct comme champ de comparaison et cliquer Perform test permet de générer le nombre correct moyen (sur 50 modèles de tests – 33% de 150 modèles dans l’ensemble de données Iris).
Cliquer sur le bouton Output format mène à une boîte de dialogue qui vous permet de préciser la moyenne (mean) et les std.deviations, aussi bien que le format en sortie. Cocher Show Average ajoute une ligne supplémentaire aux sorties listant la moyenne de chaque colonne. Avec la case à cocher Remove filter classnames, on peut retirer le nom du filtre et les options à partir d’ensembles de données traits (les noms de filtres dans Weka peuvent prendre un certain temps).
Les formats suivants sont supportés :
• CSV
• GNUPlot
• HTML
• LaTeX
• Plain text (default)
• Significance only
5.4.2 Sauvegarder les résultats
L’information affichée dans le panneau Test output est contrôlée par l’entrée en cours de sélection dans le panneau Result list. Cliquer sur une entrée fait s’afficher les résultats correspondant à cette entrée.
Les résultats affichés dans le panneau Test output peuvent être sauvegardés dans un fichier en cliquant sur Save output. Un seul ensemble de résultats peut être sauvegardé à la fois mais Weka permet à l’utilisateur de sauvegarder tous les résultats dans un même fichier un par un en utilisant l’option Append au lieu de l’option Overwrite pour les sauvegardes suivantes.
5.4.3 Changer le plan de base
Le plan de base peut être change en cliquant Select base… puis en sélectionnant le plan désiré. Sélectionner le plan OneR entraîne une comparaison individuelle de tous les autres plans avec le plan OneR.
Si le test est effectué sur le champ Percent correct avec OneR en tant que plan de base, le système indique qu’il n’y a pas de différence statistique entre les résultats pour OneR et J48. Il y a pourtant une différence statistique significative entre OneR et ZeroR.
5.4.4 La signification statistique
Le terme signification statistique (statistical significance) utilisé dans la section précédente fait référence au résultat d’une comparaison par paire de projets utilisant soit un T-Test standard ou un T-Test ré-échantillonné corrigé. Ce dernier est par défaut parce que le T-Test standard est susceptible de générer trop de différences importantes à cause des dépendances dans les estimations (en particulier quand on utilise autre chose qu’un essai de cross-validation à x-dimensions). Pour plus d’informations sur le T-test, consultez le livre Weka ou un texte d’introduction sur les statistiques. Comme le niveau de signification est baissé, la confiance dans la conclusion augmente. Dans l’expérience actuelle, il n’y a pas de différence significative sur un plan statistique entre les projets OneR et J48.
5.4.5 Test Résumé
Sélectionner Summary à partir de la base Test et effectuer un test entraîne la création des informations suivantes.
Dans cette expérience, la première range (- 1 1) indique que la colonne b (OneR) est meilleure que la rangée a (ZeroR) et que la colonne c (J48) est également meilleure que la rangée a.
Le nombre entre parenthèses représente le nombre de “victoires” significatives pour la colonne, en rapport avec la rangée. Un 0 signifie que le projet dans la colonne correspondante n’a pas remporté la moindre victoire (significative) en comparaison avec le projet de la rangée.
5.4.6 Le test de classement (Ranking Test)
Choisir Ranking dans la base Test entraîne la création des informations suivantes.
Le ranking test classe les projets entre eux en fonction du nombre total de victoires significatives (>) et d’échecs (<).
La première colonne (> – <) correspond à la différence entre le nombre de victoires et le nombre d’échecs. Cette différence est utilisée pour générer le classement.
