Sortie incorrecte pour la corrélation croisée dans la plate-forme de séries chronologiques?Salut la communauté JMP,
(W10, 64 bits, JMP Pro 15.2.1)
J'espère savoir ce que je fais de mal ou ce que je ne comprends pas sur la façon dont JMP effectue les calculs de corrélation croisée dans la plate-forme Time Series. En bref, quand 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 au lieu.
J'essaie de rassembler une explication et une description simplifiées de ce que signifie la sortie Série chronologique> Corrélation croisée pour certains collègues. Pour ce faire, j'ai fait un tableau simple avec 361 lignes (valeurs 0-360, chaque ligne est un degré, ou 0,01745 radians) et plusieurs autres colonnes qui calculent le Sin (x), Sin (x-5), Sin ( x-45), Cos (x) et une distribution aléatoire uniforme (voir le 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 omis). Tout semble comme il se doit.
Vous pouvez ensuite exécuter le script de séries temporelles, 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écutez le premier script de 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 proche 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: Obtenir les décalages dans la table de données, il imprime les décalages dans la fenêtre Journal:
"Corr vs Sin (x-5) lag en deg = [-5]"
"Corr vs Sin (x-45) lag en deg = [-40]"
"Corr vs Cos (x) lag en deg = [79]"
"Corr vs. Rondom Uniform lag in deg = [18]"
Le seul qui est correctement calculé est le décalage de -5. Un décalage 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 90. J'ai essayé de plusieurs façons différentes et avec beaucoup plus de lignes pour voir si c'est 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 ce que c'est. J'ai suivi quelques suggestions d'autres articles et j'ai essayé de les lire dans l'aide JMP ici , mais je ne trouve pas de détails sur le calcul de la corrélation croisée qui expliquerait pourquoi une fonction trigonométrique de Sin (x) n'a pas un décalage de 90 avec Cos (x).
Toutes les réflexions / commentaires à ce sujet sont très appréciés.
Merci!,
DS
AnalytiqueTableau de donnéesAutreRe: Sortie incorrecte pour la corrélation croisée dans la plate-forme de séries chronologiques?Je pense que cela est dû à la taille limitée de l'échantillon. Pour les points consécutifs sur CCF, la taille des échantillons est différente de 1. J'ai ajouté 3600 lignes supplémentaires, j'ai refait le tracé et le pic est plus proche de 90, l'amplitude est également plus proche de 1 au pic.
Re: Sortie incorrecte pour la corrélation croisée dans la plate-forme de séries chronologiques?salut @peng_liu ,
Merci pour les commentaires. J'avais essayé plus de rangées, 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 qu'elle ait un tel impact. Je peux imaginer une petite différence, peut-être 88 ou 89 avec un ensemble fini plus petit, mais être 12 off semble assez grand. Je suppose que ma préoccupation concerne les situations du monde réel où vous pourriez avoir un ensemble de données chronologiques limité.
Au fait, 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é iront toujours de -180 à 180 (enfin, avec la petite différence à une extrémité ou à l'autre en raison de la taille de l'incrément).
Par exemple, pour un ensemble de données limité dans le monde réel, vous avez peut-être 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 conclurait que les deux signaux ont un décalage de 78, alors qu'en fait il est de 90. Conclure que le décalage du signal est de 78 serait incorrect et conduirait peut-être quelqu'un à commencer à faire une mauvaise analyse des données. Peu importe ce que
Dans ce cas particulier, nous connaître quel est le vrai décalage a-priori, mais dans des situations réelles, ce n'est pas toujours connu. Je peux imaginer des ensembles de données, où 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é. En fonction du fonctionnement de la fonction de corrélation croisée, cela peut conduire à une conclusion incorrecte.
Existe-t-il un moyen de compenser cela ou que le calcul tienne compte de l'ensemble limité de données? Pourriez-vous avoir une autre colonne fonctionnelle que vous permutez et faites une simulation de la quantité de retard afin d'obtenir un intervalle de confiance sur le retard? De quel genre de colonne fonctionnelle s'agit-il?
Si je refais l'évaluation avec la formule correcte pour permettre un nombre arbitraire de lignes, je n'obtiens toujours pas la bonne réponse - même lors de la conversion d'une valeur de décalage en une valeur de degré. Par exemple, avec 3601 lignes (valeurs de 0 à 3600), j'obtiens les graphiques de décalage comme ceci:
Et quand j'exécute le script Get lags - mais maintenant en regardant 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:
"Décalage Corr vs. Sin (x-5) en deg = [-4.89863926687031]"
"Corr vs Sin (x-5) décalage de décalage = [-49]"
"Corr vs Sin (x-45) lag en deg = [-40,2888086642599]"
"Corr vs Sin (x-45) décalage de décalage = [-403]"
"Corr vs. Cos (x) lag in deg = [78.4782004998612]"
"Corr vs. Cos (x) lag in lag = [785]"
Vous trouverez ci-dessous un graphique 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 retard 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 plate-forme 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 secondes données:
Voici à quoi ressemblent mes 3601 lignes:
Cela explique pourquoi votre SinX et CosX CCF ne change pas.
La taille de l'échantillon qui compte ici n'est pas le nombre d'observations ici, mais le nombre de cycles. Dans les données d'origine, 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 un swing brutal des moyennes d'échantillons. S'il y a plusieurs cycles, la moyenne restera proche de zéro, la vraie valeur.
Si dans une situation réelle, on n'a qu'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 l'intercorrélation dans la plate-forme de séries chronologiques?salut @peng_liu ,
Merci pour vos explications supplémentaires. Je comprends maintenant quel était le problème et cela a du sens. Je peux confirmer que j'obtiens les bonnes valeurs si j'inclus plus de cycles dans la «fenêtre» de temps.
Maintenant, pour la vraie énigme:
Mes collègues de production veulent trouver le décalage entre les données de leur système d'historique de production (il enregistre des éléments tels que la température du four, les vitesses de bande, 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 calendrier de tests de contrôle qualité assez régulier toutes les 4 heures. On pense que les données d'historique de production peuvent être corrélées avec les 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écheur en production est en corrélation avec un test QC, mais le test QC est effectué peut-être 120 min. après le matériau est déjà passé dans le séchoir. Nous savons d'après des études à l'échelle du laboratoire que certaines étapes de traitement (des valeurs telles que la température du four) sont en corrélation avec certains résultats de test, 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 pouvait trouver tout type de retard dans les données, ainsi que créer manuellement plusieurs colonnes de retard et utiliser la plate-forme multivariée pour rechercher des corrélations entre les colonnes retardées et les données QC, mais je ne vois rien. Naturellement, il se peut que toute corrélation soit éliminée du bruit dans le processus, mais l'autre option est que ni la série chronologique ni les plates-formes multivariées ne sont les bonnes pour essayer de déterminer le décalage temporel correct.
Merci beaucoup pour les commentaires et les réflexions / contributions, cela a été très utile.
Merci!,
DS
