時系列プラットフォームの相互相関の出力が正しくありませんか?こんにちは、JMP コミュニティです。
(W10、64ビット、JMP Pro 15.2.1)
JMP が時系列プラットフォームで相互相関計算を実行する方法について、自分が間違っていること、または誤解していることを見つけたいと思っています。 つまり、Sin(x) と Cos(x) 関数の相互相関を比較すると、予想したような pi/2 (または 90 度) の答えは得られず、79 度が得られます。その代わり。
私は、一部の同僚にとって、「時系列 > 相互相関」の出力が何を意味するのかについて、簡略化した説明と説明をまとめようとしています。 そのために、361 行 (値は 0 ～ 360、各行は度、または 0.01745 ラジアン) と、Sin(x)、Sin(x-5)、Sin( x-45)、Cos(x)、およびランダムな一様分布 (添付の表 Periodic_series.jmp を参照)。 その目的は、SeriesJ データセットのような複雑な時間依存関数よりも直接理解できる単純な三角関数を使用して相互相関を実証することです。
データ テーブルの最初のスクリプトを実行すると、三角関数のグラフが得られます (ランダムな均一性は意図的に省略されています)。 すべてが期待どおりに見えます。
次に、Sin(x) が Y 入力、その他の関数が入力リスト列である時系列スクリプトを実行して、相互相関分析を行うことができます。 相互相関出力をデータ テーブルに変換すると (cross-correlation.jmp データ テーブルを参照)、相関値とラグをプロットできます (このデータ テーブルで最初のスクリプトを実行します)。
一見すると、これはそのはずです。Sin(x) と Sin(x-5) の相互相関は、-5 付近にピークがあり、Sin(x) と Sin(x-45) は -45 付近にあるように見えます。 、Sin(x) と Cos(x) の場合は 90 近くになります。 ただし、十字線を使用すると、Sin(x) と Cos(x) の相互相関が 80 に近いことがわかります。
実際、スクリプト「Get lags in the data table」を実行すると、ログ ウィンドウにラグが出力されます。
「Corr 対 Sin(x-5) 度の遅れ = [-5]」
「Corr 対 Sin(x-45) 度の遅れ = [-40]」
「Corr 対 Cos(x) 度の遅れ = [79]」
「Corr 対 Rondom ユニフォーム ラグ (度 = [18])」
正しく計算されるのは、-5 のラグだけです。 Sin(x) を -45 度遅らせると、期待した -45 ではなく、-40 の遅れが生じます。 同様に、Sin(x) と Cos(x) では、値が 90 であると予想されるラグは 79 になります。 「解像度」の問題かどうかを確認するために、これを複数の異なる方法で、さらに多くの行で試しましたが、約80の遅れが発生し続けます。
計算で正しいラグが返されていないか、何かが欠けているかのどちらかです。何かが足りないのではないかと思いますが、それが何かはわかりません。 他の投稿からのいくつかの提案に従い、JMP ヘルプでそれについて読んでみましたここ、しかし、Sin(x)の三角関数がCos(x)と90の遅れがない理由を説明する相互相関の計算の詳細は見つかりません。
これに関するご意見やフィードバックをいただければ幸いです。
ありがとう！、
DS
高度な統計モデリング品質およびプロセスエンジニアリングRe: 時系列プラットフォームの相互相関の出力が間違っていますか?こんにちは@peng_liu 、
追加のご提案もありがとうございます。 これが適切なタイムラグを見つけるのに役立つかどうかを確認するために、smoother を試してみます。 何か役立つものが見つかるといいですね。
私の懸念は、時間の経過とともにデータにノイズが多くなり、相関関係が失われるか、または、あなたが言及したように、サンプリング/テストスキームが相関関係を消去してしまうことです。
皆様のフィードバックとご意見に本当に感謝しています。
ありがとう！、
ディードリッヒ
Re: 時系列プラットフォームの相互相関の出力が間違っていますか?いくつかの考え...
正確な遅延がなく、データにノイズが多い可能性があります。 たとえば、実効ラグは範囲内でランダムです。 CCF を計算する前に、単純移動平均を使用して系列を平滑化してください。 時系列プラットフォームで単純移動平均を使用することも、列数式で「移動平均...」を使用することもできます。
サンプリング方式が原因で、相関信号がスキップされる可能性があります。 その場合、遅延を見つけるためのデータはほとんどありません。
Re: 時系列プラットフォームの相互相関の出力が間違っていますか?こんにちは@peng_liu 、
さらにご説明いただきありがとうございます。 今では何が問題だったのか理解できましたし、理にかなっています。 時間「ウィンドウ」内により多くのサイクルを含めると、正しい値が得られることを確認できます。
さて、本当の難問については次のとおりです。
私の製造同僚は、製造履歴システム (オーブンの温度、ベルト速度、流量などを記録します) からのデータと材料の QC 測定値の間のタイムラグを見つけたいと考えています。 生産データは、15 分、30 分、4 時間などの任意の間隔でシステムからエクスポートできます。 当社では、4 時間ごとのかなり定期的な QC テストのスケジュールを設定しています。 正確なタイムラグを見つけることができれば、生産履歴データを QC データと関連付けることができると考えられています。 たとえば、生産時の乾燥機の温度は QC テストと相関すると考えられていますが、QC テストはおそらく 120 分で行われます。後材料はすでに乾燥機を通過しています。 ラボ規模の研究から、特定の処理ステップ (オーブンの温度などの値) が特定のテスト結果と相関していることがわかっていますが、実稼働データでこれを見つけるのはラボよりも難しいことが判明しています。
時系列の相互相関を使用して、データ内の何らかのラグを検出できるかどうかを確認したり、手動で複数のラグ列を作成し、多変量プラットフォームを使用してラグ列と QC データの間の相関関係を調べたりしてみました。しかし何も見えません。 当然のことながら、プロセス中に相関関係がノイズによって洗い流されてしまう可能性もありますが、もう 1 つの選択肢は、時系列プラットフォームも多変量プラットフォームも、正しいタイムラグを決定するのに適していないということです。
フィードバックやご意見、ご意見をいただき、誠にありがとうございました。非常に役に立ちました。
ありがとう！、
DS
Re: 時系列プラットフォームの相互相関の出力が間違っていますか?2 番目のデータセットには問題があります。 2 番目のデータの Sin(x) は次のようになります。
私の 3601 行は次のようになります。
SinX と CosX CCF が変化しない理由はこれで説明されています。
ここで重要なサンプル サイズは、観測値の数ではなく、サイクル数です。 元のデータにはサイクルが 1 つだけあります。 CCF を計算するには、系列をシフトする必要があります。これにより、1 つの系列に欠損値が生じ、サンプル平均値が大きく変動します。 サイクルが多い場合、平均は真の値であるゼロに近くなります。
実際の状況でデータが 1 サイクルしかない場合、CCF は誤解を招くと思いますが、それはデータの問題であり、修正する方法はありません。
Re: 時系列プラットフォームの相互相関の出力が間違っていますか?こんにちは@peng_liu 、
フィードバックをお寄せいただきありがとうございます。 もっと多くの行を試しましたが、それほど多くの行は試しませんでした。 有限のサンプル サイズが計算にどのような影響を与えるかは理解していますが、これほど大きな影響を与えることに少し驚きました。 小さな差は想像できますが、より小さな有限集合では 88 か 89 になるかもしれませんが、12 の差はかなり大きいように思えます。 私が懸念しているのは、時系列データ セットが限られている現実の状況ではどうなるかということだと思います。
ちなみに、行の追加を正しく考慮していない Deg 列の間違いにも気付きました。 式は次のようになります。
このようにして、度数データは常に -180 から 180 まで実行されます (増分サイズにより、一方の端または他方の端に小さな違いはありますが)。
たとえば、現実世界の限られたデータ セットの場合、15 分間のみ毎秒データを収集するデバイスがあるとします。 それはわずか 900 データ ポイントです。 その状況によると、2 つの信号には 78 の遅れがあると結論付けることができますが、実際には 90 です。 信号ラグが 78 であると結論付けるのは誤りであり、誰かがデータの間違った分析を開始する可能性があります。 何があっても
この特定のケースでは、私たちは知る実際の遅れがどれだけであるかは事前にわかりますが、実際の状況では、それが常にわかるとは限りません。 同じイベントが異なる場所で測定され、信号の遅れを決定する必要があるデータセットを想像することはできますが、データセットはかなり限られています。 相互相関関数がどのように機能するかに基づくと、誤った結論が得られる可能性があります。
これを補う方法、または限られたデータセットを考慮した計算方法はありますか? ラグの信頼区間を取得するために、他の関数列を交換してラグ量のシミュレーションを行うことはできますか? それはどのような機能的な柱でしょうか？
任意の行数を考慮して正しい式を使用して評価を再実行しても、ラグ値から度数値に逆変換する場合でも、正しい答えは得られません。 たとえば、3601 行 (0 ～ 3600 の値) を使用すると、次のようなラグ プロットが得られます。
そして、Get lags スクリプトを実行すると、ラグが度に変換される列 (元のテーブルの 3601 行に基づく以下の式) を確認すると、次のようになります。
「Corr 対 Sin(x-5) 度の遅れ = [-4.89863926687031]」
「Corr vs. Sin(x-5) ラグインラグ = [-49]」
「Corr 対 Sin(x-45) 度の遅れ = [-40.2888086642599]」
「Corr vs. Sin(x-45) ラグインラグ = [-403]」
「Corr 対 Cos(x) 度の遅れ = [78.4782004998612]」
「Corr 対 Cos(x) ラグインラグ = [785]」
以下は、900 行と 785 行ずつ遅れた Cos(x) を含む Sin(x) のプロットです。 見てわかるように、785 は正しいラグ値ではなく、行 900 (赤い曲線) で発生します。
したがって、まだ正しい値が得られていません。 新しいデータテーブルが添付されます。 まだ、自分のやり方が間違っているような気がします。もしかしたら、どこか間違った式があるのではないか？ なぜ正しい値が得られないのかわかりません。
助けてくれてありがとう！、
DS
Re: 時系列プラットフォームの相互相関の出力が間違っていますか?サンプルサイズが有限であるためだと思います。 CCF 上の連続したポイントの場合、サンプル サイズは 1 異なります。 さらに 3600 行追加してプロットを再度実行したところ、ピークは 90 に近づき、振幅もピークで 1 に近づきました。
