Plus tôt cette année, mon responsable m'a envoyé un article très intéressant de Data Colada, un article de blog rédigé par trois spécialistes du comportement qui examine les recherches publiées. Les auteurs de Data Colada ont travaillé avec une équipe de chercheurs anonymes et ont découvert de curieuses anomalies dans un ensemble de données sur le kilométrage d'une voiture utilisé dans un article de 2012. Je suis chargé de tester la plateforme Explore Patterns dans JMP , qui peut être utilisée pour identifier des modèles inhabituels ou inattendus dans les données. Dans cet article, j'utilise Explorer les modèles, ainsi que d'autres outils utiles dans JMP, pour rechercher des modèles inattendus ou inhabituels dans les données de kilométrage des voitures.
Arrière-plan
Les premières lignes et colonnes de l’ensemble de données sur le kilométrage de la voiture sont présentées ci-dessous. Ces données ont été recueillies à partir d'une étude dans laquelle 13 488 clients d'une agence d'assurance automobile particulière ont été invités à déclarer leurs relevés actuels de leur compteur kilométrique. Les lectures signalées par les clients sont incluses dans les données dans les colonnes update_car1 à update_car4, car chaque client a déclaré des informations pour un maximum de quatre voitures. Les données contiennent également les relevés du compteur kilométrique de chaque véhicule au moment de l'émission initiale des polices d'assurance. Ces colonnes sont nommées baseline_car1 à baseline_car4. Étant donné que toutes les polices n’ont pas été émises en même temps, le temps écoulé entre la référence et la mise à jour varie selon les observations de cette étude.

Dans l'article Data Colada, les chercheurs ont présenté quatre anomalies trouvées dans cet ensemble de données. Examinons chacune de ces découvertes à l'aide de JMP.
Anomalie n°1 : La répartition des kilomètres parcourus est uniforme
Les auteurs de Data Colada ont constaté que la répartition des kilomètres parcourus était cohérente avec une répartition uniforme allant de 0 à 50 000 milles.
Étant donné que les données incluent une colonne de référence et de mise à jour pour les relevés du compteur kilométrique de chaque voiture, nous créons des colonnes de formule pour stocker les kilomètres parcourus en soustrayant les valeurs de base des valeurs mises à jour. Dans JMP, nous utilisons ensuite la plateforme de distribution pour afficher la distribution des valeurs de référence et des mises à jour, ainsi que le nombre total de kilomètres parcourus pour chaque voiture. Considérez le rapport de distribution de la première voiture pour chaque client.

La forme de la répartition du kilométrage de base est similaire à la répartition du kilométrage mis à jour, le compteur kilométrique médian indiquant environ 26 000 milles de plus au moment de la mise à jour. Ce constat n’est pas surprenant en soi. Ce que je trouve le plus intéressant dans les relevés de base et les mises à jour, c'est que deux participants possédaient des véhicules qui ont parcouru près d'un million de kilomètres ! Ils doivent avoir de très bons mécaniciens.
La partie la plus alarmante du rapport est la troisième distribution ci-dessus, qui montre la différence entre les deux premières. La répartition des miles parcourus entre les heures de référence et de mise à jour semble être uniformément répartie entre 0 et 50 000 miles. Il n'y a pas de valeurs supérieures à 50 000 miles et chaque case de l'histogramme contient à peu près le même nombre de participants. L'inspection visuelle fournit dans ce cas des preuves solides que les données sont uniformément réparties. Cependant, pour les données qui ne sont pas aussi évidentes, vous pouvez effectuer un test d'ajustement à l'aide de l'option Fit Beta de la plateforme de distribution .
La capture d'écran ci-dessous montre la répartition des kilomètres parcourus (mise à jour – référence) pour chacune des voitures des participants. Nous constatons que chaque distribution apparaît uniformément répartie entre 0 et 50 000 pour les deuxième, troisième et quatrième voitures également. Sur la base de ce modèle de distribution, nous pouvons conclure que les valeurs de kilométrage mises à jour auraient pu être générées en ajoutant des valeurs aléatoires uniformément distribuées aux valeurs de kilométrage de base.

Anomalie n° 2 : le kilométrage de base a été arrondi, mais pas les kilométrages mis à jour.
Les auteurs de Data Colada ont constaté que le kilométrage de base avait de nombreuses valeurs arrondies au millier le plus proche alors que le kilométrage mis à jour ne contenait pas cet arrondi.
Les chercheurs de Data Colada ont étudié l'arrondi en examinant les trois derniers chiffres des kilométrages. Nous pourrions utiliser JSL pour adopter une approche similaire, mais utilisons plutôt Explore Patterns ! Si vous n'avez jamais utilisé Explorer les modèles auparavant, vous pouvez le trouver en sélectionnant Analyser > Dépistage.

Après avoir lancé Explore Patterns pour explorer chaque ligne de base et colonne de mise à jour, nous obtenons le résultat présenté dans la capture d'écran suivante. Dans le rapport Modèles univariés, sélectionnez les valeurs de référence et mettez à jour pour la première voiture pour comparer les modèles.

Par défaut, Explorer les modèles inclut les rapports pour les valeurs les plus dupliquées dans chaque colonne, les exécutions les plus longues dans chaque colonne et les séquences dupliquées les plus longues dans chaque colonne. Pour la première voiture appartenant aux participants, il n'y a pas grand-chose à gagner des rapports sur les trajets les plus longs ou sur les séquences en double les plus longues. Cependant, le rapport Valeurs les plus dupliquées montre un contraste intéressant. Dans les kilométrages de base de la première voiture possédée, de nombreuses valeurs semblent être arrondies aux 10 000 près. Il ne s’agit pas nécessairement d’une tendance inattendue ; lorsqu'on me demande le kilométrage de mon véhicule, je réponds toujours en rond.
Le rapport des valeurs les plus dupliquées pour les kilométrages mis à jour est très différent. Dans ce rapport, il y a beaucoup moins de doublons et les doublons qui apparaissent ne sont pas arrondis comme les valeurs de référence. C'est ce qui se passerait si les colonnes de mise à jour étaient générées en ajoutant des valeurs aléatoires uniformément distribuées aux valeurs de base. Par conséquent, cette constatation est cohérente avec l’anomalie n°1.
Anomalie n°3 – Les données ont été saisies dans deux polices, et chaque observation a un « jumeau » dans l'autre police.
Les chercheurs ont remarqué que dans le fichier de données original, les observations étaient enregistrées en utilisant deux polices différentes. Grâce à un tri intelligent, les chercheurs ont découvert que chaque observation de base dans une police correspondait à une ligne très similaire dans l’autre police.
J'applaudis les chercheurs d'avoir remarqué les différentes polices et d'avoir adopté cette approche. Cependant, supposons que les données soient toutes dans la même police et que ce signal d'alarme n'ait pas été déclenché. Pouvons-nous utiliser JMP pour identifier d’éventuelles relations curieuses entre les lignes et les colonnes ? Bien sûr que nous le pouvons – c’est le blog JMP après tout.
Nous pouvons utiliser Explorer les modèles pour rechercher s'il existe des relations linéaires entre les colonnes des lignes contiguës. Considérez l’exemple simple suivant. Dans les quatre premières lignes, les colonnes ont une relation linéaire exacte où Y=2*X. Dans les trois lignes suivantes, les deux colonnes ont à nouveau une relation linéaire exacte où Y=0,5*X.

Nous pouvons utiliser Explorer les modèles pour rechercher des relations linéaires comme celle-ci entre les colonnes de base. Si nous n'avions pas déjà remarqué l'anomalie n°1, il serait logique de rechercher également des relations linéaires dans les colonnes mises à jour.

S'il existait de nombreuses relations linéaires exactes, ou peut-être de grandes séries de relations linéaires, cela peut indiquer que les valeurs d'une colonne ont été générées à l'aide d'un multiple d'une autre colonne. Ici, il n'y a que quelques lignes pour lesquelles les colonnes de référence ont une relation linéaire exacte. Nous pourrions utiliser l'option Coloriser pour visualiser ces cellules et inspecter d'éventuelles irrégularités, mais pour un ensemble de données de cette taille avec de nombreuses valeurs arrondies, il n'est pas surprenant de trouver quelques relations linéaires.
À l’aide d’Explorer les modèles, nous avons recherché s’il existait des relations linéaires suspectes entre les lignes de deux colonnes pour les valeurs de référence. Cependant, les résultats n’ont pas été très utiles. Maintenant, recherchons également les relations linéaires entre les colonnes de deux lignes, toujours pour les valeurs de base. Pour ce faire, nous devrons utiliser Explore Patterns sur la transposition de nos données.
J'ai utilisé l'option Transposer dans JMP pour transposer les données par colonnes de référence, pour les participants ayant déclaré le kilométrage d'au moins trois véhicules. J'ai exclu les rangées où les participants possédaient deux voitures ou moins, car cela ne permettrait pas d'identifier les relations linéaires.

Dans le rapport Explorer les modèles pour ces données transposées, il existe de nombreuses relations linéaires exactes où la pente est d'environ un. Ainsi, de nombreuses lignes dans le tableau de données d'origine comportent une ligne presque double de valeurs de référence pour l'ensemble des voitures. (Indice : vous pouvez cliquer avec le bouton droit sur la colonne Pente et utiliser la fonction Sélectionner où pour mettre en surbrillance toutes les lignes où la pente est proche de un. Il existe 69 paires où la pente est comprise entre 0,99 et 1,01).

Vous pouvez sélectionner Coloriser au-dessus du tableau des relations linéaires pour coloriser toutes les valeurs dans une relation linéaire exacte, ou vous pouvez cliquer avec le bouton droit sur la colonne Y pour coloriser des valeurs spécifiques. Le tableau ci-dessous contient les valeurs colorisées pour les trois premières lignes du rapport Relations linéaires.

Explore Patterns a identifié plusieurs paires de « jumeaux de conduite » dont les valeurs de kilométrage de base étaient très similaires pour toutes les voitures, ayant une relation linéaire exacte. Nous pourrions poursuivre dans cette voie en recherchant d’autres paires qui n’ont pas de relation linéaire exacte mais qui sont néanmoins très étroitement liées. Comme illustré dans l'article de Data Colada, une fois que vous triez par valeur de base pour la quatrième voiture, il est facile d'identifier de nombreux jumeaux conducteurs.
Anomalie n°4 – Une police a de nombreuses valeurs de base arrondies, et l'autre non.
Les chercheurs ont constaté que les valeurs de base de la police Calibri étaient arrondies et que les valeurs de la police Cambria n’étaient pas arrondies.
Supposons maintenant que nous sachions que certaines lignes sont écrites dans une police et que les autres lignes sont écrites dans une deuxième police, et que nous avons une colonne dans nos données avec la police de chaque ligne. Nous pouvons utiliser Explorer les modèles avec le nom de la police comme colonne Par.

Comme le montrent les rapports Explore Patterns, les valeurs de kilométrage de base pour les lignes dans la police Calibri ont de nombreuses valeurs arrondies, tandis que les valeurs de base pour les lignes Cambria ne sont pas arrondies. Étant donné que nous nous attendrions à ce que les kilométrages déclarés par les clients soient arrondis, cela suggère que les valeurs rapportées d'origine étaient les lignes avec la police Calibri et que les données du « jumeau de conduite » ont été créées puis saisies dans la police Cambria.
Conclusion
Chaque fois que vous acquérez un nouvel ensemble de données, vous effectuez probablement une analyse exploratoire et un nettoyage des données. Peut-être recherchez-vous des valeurs aberrantes , vérifiez-vous les données pour détecter les valeurs manquantes ou affichez-vous la distribution de chaque variable. J'espère que cet article vous a encouragé à envisager d'utiliser Explorer les modèles pour rechercher des modèles inhabituels dans vos données. Tous les modèles que vous trouvez à l'aide d'Explorer les modèles ne prouvent pas que quelque chose ne va pas ou est préoccupant, mais l'utilitaire vous fournit un outil pour trouver des modèles qui justifient une enquête plus approfondie.
Salut @madhu . Merci pour cette question, je vais partager deux solutions pour que les titres des colonnes du tableau de données transposées utilisent ce format.
Tout d'abord, vous pouvez créer une nouvelle colonne dans la table de données d'origine qui utilise la formule vue dans la capture d'écran ci-dessous.

Après avoir créé cette colonne, vous pouvez l'utiliser comme colonne Libellé lors de l'exécution de la transposition.

Une deuxième option que vous pouvez utiliser, puisque vous avez déjà créé la table de données transposée, consiste à utiliser JSL pour modifier les titres des colonnes. Pour ce faire, veuillez ouvrir votre tableau de données transposées, puis sélectionnez Fichier > Nouveau > Script et collez le script ci-dessous dans la fenêtre de l'éditeur de script. L'exécution de ce script mettra à jour les titres de colonne au format souhaité.
dt = Data Table("Transpose of Car Mileage Data");
colNames = dt << Get Column Names(string);
For(i=2, i <= Length(colNames), i++,
Column(dt, i) << Set Name("id=" || char(colNames[i]))
);
J'espère que ça aide. Merci encore pour vos commentaires.
Salut @madhu . Vous pouvez trouver Sélectionner où sous Lignes > Sélection de lignes > Sélectionner où.

Toutefois, si vous souhaitez utiliser JMP de manière interactive pour sélectionner ces lignes, au lieu d'utiliser JSL, je vous recommande d'ajouter une nouvelle colonne et de créer une formule pour identifier ces lignes. Pour ce faire, veuillez essayer les étapes suivantes.
- Sélectionnez Cols > Nouvelles colonnes... dans le menu du haut
- Dans le menu Nouvelle colonne, sélectionnez Propriétés de la colonne > Formule
- Dans l'éditeur de formule, entrez la formule comme ci-dessous

Lorsque vous avez saisi la formule, cliquez sur OK pour créer la colonne. Dans la nouvelle colonne, les lignes avec la valeur 1 correspondent aux participants avec trois voitures ou plus. Vous pouvez sélectionner toutes les lignes avec la valeur 1 en cliquant avec le bouton droit sur une ligne avec la valeur 1 et en cliquant sur "Sélectionner les cellules correspondantes" comme ci-dessous.

Pour votre question sur l'utilisation de JSL pour ce faire, un excellent point de départ consiste à consulter le journal amélioré pour trouver le JSL qui a été généré pour les actions que vous avez effectuées de manière interactive. Par exemple, la capture d'écran ci-dessous montre le journal après avoir ouvert le tableau de données joint à cette page, créé la nouvelle colonne de formules décrite ci-dessus et transposé les données à l'aide des lignes sélectionnées. Vous pouvez enregistrer le script du journal dans un nouveau script que vous pouvez réexécuter à tout moment.

J'espère que ceci est utile. Merci encore pour la lecture.
Salut @madhu merci pour la lecture et pour la question. Pour identifier les participants qui ont déclaré des kilométrages pour au moins trois véhicules, vous pouvez utiliser la fonction Sélectionner où de JMP pour sélectionner ces lignes. Ensuite, lors de la transposition des données, vous pouvez choisir de n'utiliser que les lignes sélectionnées. Voici un script JSL qui sélectionne des lignes pour tous les participants avec trois voitures ou plus, puis transpose les données en utilisant uniquement les lignes sélectionnées.
Data Table( "Car Mileage Data" ) << Select Where(
Sum(Is Missing(:baseline_car1),
Is Missing(:baseline_car2),
Is Missing(:baseline_car3),
Is Missing(:baseline_car4)
) <= 1);
Data Table( "Car Mileage Data" ) << Transpose(
columns( :baseline_car1, :baseline_car2, :baseline_car3, :baseline_car4 ),
Transpose selected rows only( 1 ),
Output Table( "Transpose of Car Mileage Data" )
);