Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Bonjour la communauté JMP,
(W10, 64 bits, JMP Pro 15.2.1)
J'espère découvrir soit ce que je fais de mal, soit ce que je comprends mal sur la façon dont JMP effectue les calculs de corrélation croisée dans la plateforme Time Series. En bref, lorsque je compare la corrélation croisée d'une fonction Sin(x) avec une fonction Cos(x), je n'obtiens pas de réponse de pi/2 (ou 90 degrés) comme je m'y attendais, j'obtiens 79 degrés. plutôt.
J'essaie de rassembler une explication et une description simplifiées de ce que la sortie Série chronologique > Corrélation croisée signifie pour certains collègues. Pour ce faire, j'ai créé un tableau simple avec 361 lignes (valeurs 0 à 360, chaque ligne est un degré, soit 0,01745 radians) et plusieurs autres colonnes qui calculent le Sin(x), Sin(x-5), Sin( x-45), Cos(x) et une distribution uniforme aléatoire (voir tableau ci-joint Periodic_series.jmp). Le but est de démontrer la corrélation croisée à l'aide de fonctions trigonométriques simples que les gens peuvent comprendre plus directement qu'une fonction complexe dépendante du temps, comme l'ensemble de données SeriesJ.
Si vous exécutez le premier script de la table de données, vous obtenez un graphique des fonctions trigonométriques (l'uniforme aléatoire est volontairement laissé de côté). Tout semble comme il se doit.
Vous pouvez ensuite exécuter le script de série chronologique, où Sin(x) est l'entrée Y et les autres fonctions sont les colonnes de la liste d'entrée afin que vous puissiez effectuer l'analyse de corrélation croisée. En transformant la sortie de corrélation croisée en une table de données (voir la table de données cross-correlation.jmp), vous pouvez tracer les valeurs de corrélation par rapport au décalage (exécuter le premier script dans cette table de données).
À première vue, cela semble normal : la corrélation croisée de Sin(x) avec Sin(x-5) a son pic près de -5, Sin(x) avec Sin(x-45) semble être proche de -45. , et pour Sin(x) avec Cos(x) est proche de 90. Cependant, si vous utilisez le réticule, vous verrez que la corrélation croisée entre Sin(x) et Cos(x) est plus proche de 80.
En fait, si vous exécutez le script : Get lags in the data table, il affiche les lags dans la fenêtre Log :
"Corr vs. Sin(x-5) décalage en degrés = [-5]"
"Corr vs. Sin(x-45) décalage en degrés = [-40]"
"Corr vs. Cos(x) décalage en degrés = [79]"
"Corr vs. Rondom Décalage uniforme en degrés = [18]"
Le seul qui soit correctement calculé est le décalage de -5. Un retard de Sin(x) de -45 degrés entraîne un décalage de -40, et non de -45 comme prévu. De même, avec Sin(x) et Cos(x), le décalage est de 79, alors que je m'attendrais à ce que la valeur soit de 90. J'ai essayé cela de plusieurs manières différentes et avec beaucoup plus de lignes pour voir s'il s'agissait d'un problème de "résolution", mais j'obtiens toujours un décalage d'environ 80.
Soit le calcul ne renvoie pas le bon décalage, soit il me manque quelque chose.Je suppose qu'il me manque quelque chose, mais je ne suis pas sûr de quoi. J'ai suivi quelques suggestions d'autres articles et essayé de les lire dans l'aide de JMP. ici , mais je ne trouve aucun détail sur le calcul de la corrélation croisée qui expliquerait pourquoi une fonction trigonométrique de Sin(x) n'a pas de décalage de 90 avec Cos(x).
Toute réflexion/commentaire à ce sujet est très apprécié.
Merci!,
DS
Modélisation statistique avancéeIngénierie Qualité et ProcédésRe : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Salut @peng_liu ,
Merci pour les suggestions supplémentaires. Je vais essayer le plus fluide pour voir si cela peut aider à trouver un décalage raisonnable. J'espère que je pourrai trouver quelque chose d'utile.
Ma préoccupation est que soit les données sont bruitées dans le temps et les corrélations sont perdues, soit, comme vous l'avez mentionné, le schéma d'échantillonnage/test efface toute corrélation.
J’apprécie vraiment vos commentaires et vos contributions.
Merci!,
Diedrich
Re : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Quelques idées...
Il est possible qu'il n'y ait pas de décalage exact et que vos données soient parasitées. Par exemple, le décalage effectif est aléatoire dans une plage. Essayez de lisser votre série en utilisant une simple moyenne mobile avant de calculer le CCF. Vous pouvez utiliser la moyenne mobile simple dans la plateforme de séries chronologiques ou la « moyenne mobile » dans la formule de colonne.
Il est possible que les signaux corrélés soient ignorés en raison de votre schéma d'échantillonnage. Il n’y a alors pas grand-chose dans les données pour vous permettre de trouver le décalage.
Re : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Salut @peng_liu ,
Merci pour vos explications complémentaires. Je comprends maintenant quel était le problème et c'est logique. Je peux confirmer que j'obtiens les bonnes valeurs si j'inclus plus de cycles dans la « fenêtre » temporelle.
Passons maintenant à la vraie énigme :
Mes collègues de production souhaitent connaître le décalage temporel entre les données de leur système d'historique de production (il enregistre des éléments tels que la température du four, la vitesse des bandes, les débits, etc.) et les mesures de contrôle qualité sur le matériau. Les données de production peuvent être exportées du système à n'importe quel intervalle donné, 15 min, 30 min, 4 heures, etc. Nous avons un programme de tests de contrôle qualité assez régulier toutes les 4 heures. On pense que les données de l'historique de production peuvent être corrélées aux données de contrôle qualité si le décalage temporel correct peut être trouvé. Par exemple, on pense que la température du séchoir en production est en corrélation avec un test QC, mais le test QC est effectué peut-être 120 minutes. après le matériau est déjà passé au séchoir. Nous savons grâce à des études en laboratoire que certaines étapes de traitement (des valeurs comme la température du four) sont en corrélation avec certains résultats de tests, mais trouver cela dans les données de production s'avère plus difficile qu'en laboratoire.
J'ai essayé d'utiliser la corrélation croisée dans la série chronologique pour voir si elle peut trouver un type de décalage dans les données, ainsi que de créer manuellement plusieurs colonnes de décalage et d'utiliser la plate-forme multivariée pour rechercher des corrélations entre les colonnes décalées et les données QC. mais je ne vois rien. Naturellement, il se pourrait que toute corrélation soit éliminée du bruit au cours du processus, mais l’autre option est que ni les séries chronologiques ni les plates-formes multivariées ne sont les bonnes pour tenter de déterminer le décalage temporel correct.
Merci beaucoup pour vos commentaires et vos réflexions/contributions, cela a été très utile.
Merci!,
DS
Re : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Il y a des problèmes dans le deuxième ensemble de données. Voici à quoi ressemble Sin(x) dans les deuxièmes données :
Voici à quoi ressemblent mes 3601 lignes :
Cela explique pourquoi votre CCF SinX et CosX ne change pas.
La taille de l’échantillon qui compte ici n’est pas le nombre d’observations, mais le nombre de cycles. Dans les données originales, il n’y a qu’un seul cycle. Pour calculer le CCF, il faut décaler les séries, ce qui créera des valeurs manquantes dans une série, ce qui entraînera une variation considérable des moyennes d'échantillon. S’il y a plusieurs cycles, la moyenne restera proche de zéro, la vraie valeur.
Si dans une situation réelle, on ne dispose que d'un seul cycle de données, je pense que le CCF sera trompeur, mais c'est un problème de données et il n'y a aucun moyen de le résoudre.
Re : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Salut @peng_liu ,
Merci pour les commentaires. J'avais essayé plus de lignes, mais je n'en ai pas essayé autant. Bien que je comprenne comment la taille finie de l'échantillon peut influencer le calcul, je suis un peu surpris que cela l'impacte autant. Je peux imaginer une petite différence, peut-être 88 ou 89 avec un ensemble fini plus petit, mais être à 12 semble assez important. Je suppose que ma préoccupation concerne les situations du monde réel dans lesquelles vous pourriez disposer d'un ensemble de données chronologiques limité.
À propos, j'ai également remarqué une erreur dans ma colonne Deg qui ne tenait pas correctement compte de l'ajout de lignes supplémentaires. La formule doit être :
De cette façon, les données de degrés seront toujours comprises entre -180 et 180 (enfin, avec une petite différence d'un côté ou de l'autre en raison de la taille de l'incrément).
Par exemple, dans le cas d'un ensemble de données limité dans le monde réel, vous disposez peut-être d'un appareil qui collecte des données toutes les secondes pendant une période de quinze minutes seulement. Cela ne représente que 900 points de données. Selon cette situation, on pourrait conclure que les deux signaux ont un décalage de 78, alors qu'en réalité il est de 90. Conclure que le décalage du signal est de 78 serait incorrect et pourrait conduire quelqu'un à commencer à faire une mauvaise analyse des données. Peu importe ce que
Dans ce cas particulier, nous savoir quel est le véritable décalage a priori, mais dans les situations réelles, cela n'est pas toujours connu. Je peux imaginer des ensembles de données, dans lesquels le même événement est mesuré à différents endroits et le décalage du signal doit être déterminé, mais l'ensemble de données est plutôt limité. Compte tenu de la façon dont la fonction de corrélation croisée semble fonctionner, cela pourrait conduire à une conclusion incorrecte.
Existe-t-il un moyen de compenser cela ou de faire en sorte que le calcul tienne compte de l'ensemble limité de données ? Pourriez-vous avoir une autre colonne fonctionnelle que vous échangeriez et effectueriez une simulation du décalage afin d'obtenir un intervalle de confiance sur le décalage ? De quel type de colonne fonctionnelle s'agirait-il ?
Si je refait l'évaluation avec la formule correcte pour autoriser un nombre arbitraire de lignes, je n'obtiens toujours pas la bonne réponse, même lors de la reconversion d'une valeur de décalage en valeur de degré. Par exemple, avec 3 601 lignes (valeurs de 0 à 3 600), j'obtiens les graphiques de décalage comme ceci :
Et lorsque j'exécute le script Get lags - mais en regardant maintenant la colonne où le décalage est reconverti en degrés (formule ci-dessous basée sur les 3601 lignes de la table d'origine), j'obtiens :
"Corr vs. Sin(x-5) décalage en degrés = [-4.89863926687031]"
"Corr vs. Sin(x-5) décalage en décalage = [-49]"
"Corr vs. Sin(x-45) décalage en degrés = [-40.2888086642599]"
"Corr vs. Sin(x-45) décalage en décalage = [-403]"
"Corr vs. Cos(x) décalage en degrés = [78.4782004998612]"
"Corr vs. Cos(x) décalage en décalage = [785]"
Vous trouverez ci-dessous un tracé de Sin(x) avec Cos(x) décalé de 900 et 785 lignes. Comme on peut le voir, 785 n'est pas à la valeur de décalage correcte, ce qui se produit sur la ligne 900 (courbe rouge).
Donc je n'obtiens toujours pas les bonnes valeurs. De nouveaux tableaux de données sont joints. J'ai toujours le sentiment que je ne fais pas quelque chose de bien – peut-être une mauvaise formule quelque part ? Je n'arrive pas à comprendre pourquoi je n'obtiens pas les bonnes valeurs.
Merci pour l'aide!,
DS
Re : Sortie incorrecte pour la corrélation croisée dans la plateforme de séries chronologiques ?Je pense que cela est dû à la taille limitée de l'échantillon. Pour les points consécutifs sur le CCF, les tailles d’échantillon sont différentes de 1. J'ai ajouté 3600 lignes supplémentaires, refait le tracé, et le pic est plus proche de 90, et l'amplitude est également plus proche de 1 au pic.
