Améliorer l'analyse des données grâce à une meilleure visualisation des données?

J'ai exécuté quatre programmes en a, b, c, d parallèle sur deux machines différentes Xet Yséparément pendant 10 fois. Ce qui suit est un échantillon des données. Les temps d'exécution (millisecondes) des 10exécutions de chaque programme sont indiqués sous leurs noms respectifs.

Machine-X:

a b  c d
29 40 21 18
28 43 20 18
30 49 20 28
29 50 19 19
28 51 21 19
29 41 30 29
32 47 10 18
29 43 20 18
28 51 30 29
29 41 21 19


Machine-Y:

a b c d
16 24 19 18
16 24 19 18
16 23 19 18
16 24 19 18
16 24 19 18
16 22 19 18
16 24 19 18
16 24 19 18
16 24 19 18
16 24 19 18

J'ai besoin de créer des graphiques pour visualiser les éléments suivants:

1. Comparez les performances de chaque programme (c'est-à-dire le temps d'exécution) sur les machines X et Y.
2. Comparez la variation des temps d'exécution de chaque programme sur les machines X et Y
3. Quelle machine est juste pour fournir des ressources informatiques à chaque programme?
4. Comparez les temps d'exécution totaux (a + b + c + d) des quatre programmes de chaque exécution sur les machines X et Y.
5. Comparez la variation des temps d'exécution totaux des quatre programmes sur les 10 exécutions.

Pour 1 et 2, j'ai fait la figure A, la figure B est pour 3 et la figure C est pour 4 et 5. Cependant, je ne suis pas satisfait car il y a trois graphiques et il est difficile d'adapter les trois graphiques dans mon papier. De plus, je pense que nous pouvons produire mieux que ceux-ci. J'apprécie vraiment si quelqu'un m'aide à dessiner un ou deux beaux graphiques au lieu de trois en R tout en satisfaisant mes exigences. Veuillez voir ci-dessous le code R que j'ai utilisé pour produire ces graphiques.

Figure A:

Figure B: L'axe X montre les exécutions, l'axe Y montre les temps d'exécution des quatre programmes dans une exécution particulière.

Figure C:

Code R

> pdf("Figure A.pdf")
> par(mfrow=c(1,2))
> boxplot(x,boxwex=0.4, ylim=c(15, 60))
> mtext("Time", side=2, line=2)
> mtext("Running times of each program in 10 runs", side=3, line=2, at=6,cex=1.4)
> mtext("Machine X", side=3, line=0.5, at=2,cex=1.1)
> boxplot(y,boxwex=0.4, ylim=c(15, 60))
> mtext("Machine Y", side=3, line=0.4, at=2,cex=1.1)
> dev.off()



> pdf("Figure B.pdf")
> par(mfrow=c(1,2))
>  boxplot(t(x),boxwex=0.4, ylim=c(0,50))
> mtext("Run Number", side=1, line=2, at=12, cex=1.2)
> mtext("Fairness", side=3, line=2, at=12,cex=1.4)
>  mtext("Machine X", side=3, line=0.5, at=5,cex=1.1)
> boxplot(t(y),boxwex=0.4, ylim=c(0,50))
> mtext("Machine Y", side=3, line=0.4, at=5,cex=1.1)
> dev.off()


> pdf("Figure C.pdf")
> par(mfrow=c(1,2))
> barplot(t(x), ylim=c(0,150),names=1:10,col=mycolor)
> mtext("Run Number", side=1, line=2, at=14, cex=1.2)
> mtext("Total Running-Times in 10 Runs", side=3, line=2, at=14, cex=1.2)
> mtext("Machine X", side=3, line=0.5, at=5,cex=1.1)
> barplot(t(y), ylim=c(0,150), names=1:10,col=mycolor)
> mtext("Machine Y", side=3, line=0.5, at=5,cex=1.1)
> legend("topright",legend=c("a","b","c","d"),fill=mycolor,cex=1.1)
> dev.off()

Bien que les autres répondants aient fourni des informations utiles, je suis en désaccord avec certains de leurs points de vue. En particulier, je crois que les graphiques qui peuvent montrer les détails des données (sans être encombrés) sont plus riches et plus gratifiants à voir que ceux qui résument ou cachent ouvertement les données, et je crois que toutes les données sont intéressantes, pas seulement celles pour ordinateur X. Jetons un coup d'oeil.

(Je montre ici de petites parcelles pour montrer qu'un grand nombre de chiffres peuvent être utilement affichés, en détail, dans de petits espaces.)

Ce graphique montre les valeurs de données individuelles, toutes d'entre elles. Il utilise la distance le long de l'axe des y pour représenter les temps de calcul, car les gens peuvent comparer plus rapidement et avec précision les distances sur un axe commun (comme les études de Bill Cleveland l'ont montré). Pour s'assurer que la variabilité est correctement comprise dans le contexte du temps réel, l'axe des y est étendu jusqu'à zéro: le couper à n'importe quelle valeur positive exagérera la variation relative de la synchronisation, introduisant un «facteur de Lie» (dans la terminologie de Tufte) .$80 = 2 \times 4 \times 10$

La géométrie graphique (marqueurs de points par rapport aux segments de ligne) distingue clairement l'ordinateur X (marqueurs) de l'ordinateur Y (segments). Les variations de symbolisme - à la fois la forme et la couleur des marqueurs de points - ainsi que la variation de position le long de l'axe x distinguent clairement les programmes. (L'utilisation de la forme garantit que les distinctions persisteront même dans un rendu en niveaux de gris, ce qui est probablement dans un journal imprimé.)

Les programmes semblent n'avoir aucun ordre inhérent, il est donc inutile de les présenter par ordre alphabétique par leurs noms de code "a", ..., "d". Cette liberté a été exploitée pour séquencer les résultats par le temps moyen requis par l'ordinateur X. Ce simple changement, qui ne nécessite ni complexité ni encre supplémentaire, révèle un schéma intéressant: les synchronisations relatives des programmes sur l'ordinateur Y diffèrent des synchronisations relatives sur ordinateur X. Bien que cela puisse ou non être statistiquement significatif, c'est une caractéristique des données que ce graphique met en évidence par hasard. C'est ce que nous espérons qu'un bon graphique fera.

En rendant les marqueurs de points suffisamment grands, ils se fondent presque visuellement dans une représentation graphique de la variabilité totale par programme. (Le mélange perd certaines informations: nous ne voyons pas exactement où se produisent les chevauchements. Cela pourrait être corrigé en agitant légèrement les points dans le sens horizontal, résolvant ainsi tous les chevauchements.)

Ce graphique à lui seul pourrait suffire à présenter les données. Cependant, il y a plus à découvrir en utilisant les mêmes techniques pour comparer les temps d'une exécution à l'autre.

Cette fois, la position horizontale distingue l'ordinateur Y de l'ordinateur X, essentiellement en utilisant des panneaux côte à côte. (Les contours autour de chaque panneau ont été effacés, car ils interféreraient avec les comparaisons visuelles que nous voulons faire à travers le tracé.) Dans chaque panneau, la position distingue la course. Exactement comme dans le premier graphique - et en utilisant le même schéma de marqueurs pour distinguer les programmes - les marqueurs varient en forme et en couleur. Cela facilite les comparaisons entre les deux graphiques.

Notez le contraste visuel dans les modèles de marqueurs entre les deux panneaux: cela a une immédiateté non offerte par les tableaux de nombres, qui doivent être soigneusement analysés avant de se rendre compte que l'ordinateur Y est si cohérent dans ses horaires.

Les marqueurs sont joints par de faibles lignes en pointillés pour fournir des connexions visuelles au sein de chaque programme. Ces lignes sont de l'encre supplémentaire, apparemment inutile pour présenter les données, donc je soupçonne que le professeur Tufte les éviterait. Cependant, je trouve qu'ils servent de guides visuels utiles pour séparer l'encombrement où les marqueurs de différents programmes se chevauchent presque.

Encore une fois, je suppose que les pistes sont indépendantes et que le numéro de série n'a donc aucun sens. Une fois de plus, nous pouvons exploiter cela: séparément dans chaque panneau, les exécutions ont été séquencées par le temps total pour les quatre algorithmes. (L'axe des x ne nomme pas les numéros d'exécution, car cela ne serait qu'une distraction.) Comme dans le premier graphique, ce séquençage révèle plusieurs modèles intéressants de corrélation entre les synchronisations des quatre algorithmes au sein de chaque exécution. La majeure partie de la variation pour l'ordinateur X est due à des changements dans l'algorithme "b" (carrés rouges). Nous l'avons déjà vu dans le premier graphique. Les pires performances totales, cependant, sont dues à deux longs délais pour les algorithmes "c" et "d" (diamants en or et triangles verts, respectivement), et ceux-ci se sont produits au cours des deux mêmes cycles. Il est également intéressant de noter que les valeurs aberrantes pour les programmes "a" et "c" se sont toutes deux produites au cours de la même exécution. Ces observations pourraient révéler des informations utiles sur la variation de la synchronisation du programme pour l'ordinateur X. Ce sont des exemples de la façon dont, parce que ces graphiques montrent les détails des données (plutôt que des résumés comme des barres ou des boîtes à moustaches ou autre), beaucoup peut être vu concernant la variation et les corrélations - -mais je n'ai pas besoin de m'étendre là-dessus; vous pouvez l'explorer par vous-même.

J'ai construit ces graphiques sans penser à une "histoire" ou "faire tourner" les données, parce que je voulais d'abord voir ce que les données avaient à dire. De tels graphiques ne pourront jamais honorer les pages de USA Today, mais en raison de leur capacité à révéler des modèles en permettant des comparaisons visuelles rapides et précises,ce sont de bons candidats pour communiquer les résultats à un public scientifique ou technique. (Ce qui ne veut pas dire qu'ils sont sans défauts: il existe des moyens évidents de les améliorer, y compris le tremblement dans le premier et la fourniture de bonnes légendes et d'étiquettes judicieuses dans les deux.) Alors oui, je suis d'accord que l'attention sur le public potentiel est importante, mais je ne suis pas convaincu que les graphiques doivent être créés dans le but de défendre ou d'appuyer un point de vue particulier.

En résumé, je voudrais offrir ce conseil.

• Utilisez les principes de conception trouvés dans la littérature sur la cartographie et les neurosciences cognitives (par exemple, Alan MacEachren ) pour améliorer les chances que les lecteurs interprètent votre graphique comme vous le souhaitez et qu'ils puissent en tirer des conclusions honnêtes et impartiales.

• Utilisez les principes de conception trouvés dans la littérature sur les graphiques statistiques (par exemple, Ed Tufte et Bill Cleveland ) pour créer des présentations riches en données informatives.

• Expérimentez et soyez créatif. Les principes sont le point de départ pour faire un graphique statistique, mais ils peuvent être brisés. Comprenez quels principes vous violez et pourquoi.

• Visez la révélation plutôt que le simple résumé. Un graphique satisfaisant révèle clairement les modèles d'intérêt pour les données. Un grand graphique révélera des motifs inattendus et nous invitera à faire des comparaisons auxquelles nous n'aurions peut-être pas pensé auparavant. Cela peut nous inciter à poser de nouvelles questions et d'autres questions. C'est ainsi que nous faisons progresser notre compréhension.

Les graphiques vous permettent de raconter une histoire, de faire tourner les données de la manière que vous souhaitez que le lecteur interprète vos résultats. Quel est le message à retenir? Que voulez-vous garder dans leur esprit? Déterminez ce message, puis réfléchissez à la manière d'en faire une figure.

Dans vos intrigues, je ne sais pas quel message je devrais apprendre et vous me donnez trop de données brutes --- Je veux des résumés efficaces, pas les données elles-mêmes.

Pour le graphique 1, je demanderais, quelles comparaisons voulez-vous faire? Les graphiques que vous avez illustrent les temps d'exécution d'un programme à l'autre pour un ordinateur donné. Il semble que vous souhaitiez effectuer des comparaisons entre ordinateurs pour un programme donné. Si tel est le cas, vous souhaitez que les statistiques du programme a sur l'ordinateur x soient dans le même tracé que les statistiques du programme a sur l'ordinateur y. Je mettrais les 8 cases dans vos deux boxplots dans la même figure, ordonné hache, ay, bx, par, ... pour faciliter la comparaison que vous faites vraiment.

Il en va de même pour l'intrigue 2, mais je trouve cette intrigue étrange. Vous montrez essentiellement chaque point de données que vous avez --- une case pour chaque série et une série n'a que 4 observations. Pourquoi ne pas simplement me donner une boîte à moustaches des temps d'exécution totaux pour l'ordinateur x et un pour l'ordinateur y?

La même critique «trop de données» s'applique également à votre dernière intrigue. Le tracé 3 n'ajoute aucune nouvelle information au tracé 2. Je peux obtenir le temps global si je multiplie simplement le temps moyen par 4 dans le tracé 2. Ici aussi, vous pouvez tracer une boîte pour chacun des ordinateurs x et y, mais ceux-ci sera littéralement des multiples de l'intrigue que j'ai proposé de remplacer l'intrigue 2.

Je suis d'accord avec @Andy W que l'ordinateur y n'est pas si intéressant et peut-être voulez-vous simplement l'indiquer et l'exclure des parcelles par souci de concision (bien que je pense que les suggestions que j'ai faites peuvent vous aider à réduire ces parcelles). Cependant, je ne pense pas que les tableaux soient de très bonnes façons de procéder.

Vos tracés me semblent corrects, et si vous avez des contraintes d'espace, vous pouvez les placer tous dans un seul tracé au lieu de trois tracés séparés (par exemple, utilisez-les par(mfrow=c(3,2))et sortez-les simplement sur le même appareil).

Il n'y a cependant pas grand-chose à signaler Machine Y, il n'a littéralement aucune variation, sauf pour le programme b. Je pense que les graphiques sont instructifs pour voir non seulement combien de temps les temps de fonctionnement sont longs, Machine Xmais aussi combien les temps de fonctionnement varient.

Si c'est vraiment votre cas d'utilisation, ce sont des données si simples qui placent toutes les données dans un tableau seraient suffisantes pour démontrer la différence entre les machines (bien que je pense que les graphiques sont toujours utiles si vous pouvez vous permettre de les placer dans le document également).