4.5 Réutilisation, reproductibilité et diffusion
4.5.2 Visualisation des résultats
Le but de cet outil est de rendre accessible tous les outils qui ont permis les analyses faites dans [Bra+15], à savoir d’évaluer les performances en temps et en qualité des différents algorithmes pour des données avec diverses caractéristiques. Afin de s’inscrire dans une perspective d’extension des analyses précédemment produites, nous proposons d’évaluer les résultats au travers de graphiques et figures déjà utilisés dans de précédents travaux [AM12 ; BBN13 ; CDK06 ; SZ09].
4.5.2.1 Comparaison des résultats
Lorsque les calculs ont été effectués avec l’option permettant de mesurer précisé-ment le temps nécessaire pour le calcul de chaque consensus par chaque algorithme,
126 QUALITÉ DES ALGORITHMES D’AGRÉGATION DE CLASSEMENTSCHAPITRE 4. ÉVALUATION DE LA PERFORMANCE ET DE LA
Figure 4.19 – Le graphique supérieur présente les résultats avec en abscisse le gap et en ordonnée le temps nécessaire pour calculer le consensus.Le graphique inférieur présente les temps de calculs moyen pour différent nombre d’éléments dans le jeu de données.
Figure 4.20 – Le graphique supérieur présente les gap moyens sous forme d’un treemap ordonné. Le graphique inférieur présente les gap moyens en fonction du nombre de pas utilisé lors de la généra-tion des données.
le temps est exploité dans deux graphiques qui sont présentés en Figure 4.19. Dans le graphique supérieur, chaque point représente un algorithme pour un jeu de don-nées, l’abscisse indiquant la qualité du résultat obtenu (via le gap), et l’ordonnée le temps nécessaire pour obtenir le consensus. Dans ce graphique, l’algorithme en noir est KwikSortStDev, une variante de KwikSort qui lui est en bleu. Cette variante semble proposer de meilleurs résultats que la version classique mais au prix d’une consommation en temps légèrement plus élevé. Ces deux algorithmes étant à la fois moins coûteux, mais moins bons que BioConsert (vert).
La partie inférieure de la Figure 4.19 est un graphique plus classique avec en abscisse, le nombre d’éléments dans les jeux de données et en ordonnée le temps de calcul moyen pour chaque algorithme (échelle logarithmique). On remarque ici aussi que KwikSortStDev est plus lent que KwikSort, mais de peu, et que BioConsert est bien plus coûteux en temps que les deux autres.
4.5. RÉUTILISATION, REPRODUCTIBILITÉ ET DIFFUSION 127
Figure 4.21 – Les algo-rithmes occupent la surface allouée à la visualisation selon une spirale tournant dans le sens horaire de l’ex-térieur vers l’inl’ex-térieur. Afin de comparer la qualité moyenne des
résul-tats, deux types de visualisation sont proposés. Le premier type de visualisation est basé sur un treemap ordonné (Ordered TreeMap) [SW01 ; TS07] visible en haut de la Figure 4.20. Le second type est visible dans la partie inférieure de Figure 4.20, on y trace le gapen ordonnée. Concentrons-nous dans un premier temps sur le treemap ordonné.
En Figure 4.20, le schéma du haut est un treemap ordonné où l’on représente une visualisation du gap moyen des consensus de chaque algorithme. Dans
cette visualisation, les algorithmes de consensus sont triés par leur gap, puis placés selon une spirale allant de l’extérieur vers l’intérieur dans un sens horaire en spirale (cf. Figure 4.21). Plus précisément, le meilleur algorithme est représenté dans le tiers ouest de la visualisation, le second recevant le tiers nord de ce qui est encore disponible, le troisième recevant le tiers est de ce qui est disponible, le quatrième le tiers sud et ainsi de suite. Lorsqu’il y a égalité entre deux algorithmes, ils se partagent 40% de l’espace disponible. À noter que l’avant-dernier algorithme reçoit 60% de l’espace disponible, et le dernier ce qu’il reste.
Afin de mettre en évidence des variations de la qualité des résultats liés à divers paramètres, on représente le gap en fonction de différentes abscisses. Si les données sont synthétiques et générées avec la modélisation par chaîne de Markov (cf. Section 4.2.5) (unifiée ou non), on représente le gap en fonction du nombre de pas parcourus dans la chaîne de Markov lors de la génération. Le graphique présenté en Figure 4.20 reproduit la Figure 4.12 et y représente le gap pour des pas allant de 103 à 106. Pour les jeux de données synthétiques uniformément générés, mais aussi les jeux de données réels, ce graphique est produit en prenant comme abscisse le nombre d’éléments présents dans les jeux de données.
4.5.2.2 Comparaison sur de nouveaux jeux de données
Trois approches peuvent être suivies pour exécuter/évaluer des algorithmes sur de nouveaux jeux de données ou obtenir des consensus sur ces jeux de données. Pour cela, la partie centrale de la Figure 4.15, nommé "Datasets", propose trois onglets. L’onglet "Text" permet de saisir manuellement un jeu de données. L’onglet "File" permet d’envoyer un fichier texte dans lequelle on a préalablement écrit son jeu de données. Finalement, l’onglet "Database" permet d’envoyer plusieurs fichier et le sauvegarder dans la base de données de Rank’n’ties afin de s’en servir ultérieurement. Il suffit ensuite de sélectionner le type de jeux de données (datasets) "Others".
128 QUALITÉ DES ALGORITHMES D’AGRÉGATION DE CLASSEMENTSCHAPITRE 4. ÉVALUATION DE LA PERFORMANCE ET DE LA 4.5.2.3 Comparaison de nouveaux algorithmes par rapport à
l’existant
Dans l’interface principale présentée en Figure 4.15, la colonne de gauche per-met de choisir parmi différents algorithmes. Afin d’évaluer de nouvelles approches, tout utilisateur peut envoyer dans Rank’n’ties un algorithme et ensuite l’évaluer. Pour des raisons évidentes de confidentialité, cet algorithme n’est visible que par l’utilisateur qui l’a changé. Pour envoyer et évaluer un nouvel algorithme, l’utili-sateur doit dans un premier temps télécharger une archive contenant un squelette d’algorithme d’agrégation de classements (détaillé dans la sous section suivante), à charge de l’utilisateur de faire le lien entre son algorithme et le squelette. Ce dernier pouvant tout autant écrire l’algorithme en Java, ou l’écrire dans un autre langage et appeler son code depuis le squelette Java.