時系列プラットフォームの相互相関の出力が正しくありませんか？こんにちは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付近にあるように見えます。 、およびCos（x）を使用したSin（x）の場合は90に近くなります。 ただし、十字線を使用すると、Sin（x）とCos（x）の間の相互相関が80に近いことがわかります。
実際、次のスクリプトを実行すると、データテーブルでラグを取得すると、ログウィンドウにラグが出力されます。
「Corrvs.Sin（x-5）lag in deg = [-5]」
「Corrvs.Sin（x-45）lag in deg = [-40]」
「Corrvs.Cos（x）lag in deg = [79]」
「Corrvs。RondomUniformlagin deg = [18]」
正しく計算されるのは-5のラグだけです。 Sin（x）が-45度遅れると、予想どおり-45ではなく、-40の遅れが発生します。 同様に、Sin（x）とCos（x）の場合、値が90になると予想される場合、ラグは79です。 これを複数の異なる方法で試し、さらに多くの行を使用して、それが「解決」の問題であるかどうかを確認しましたが、約80のラグが発生し続けています。
計算が正しいラグを返さないか、何かが足りません。何かが足りないと思いますが、それが何なのかわかりません。 私は他の投稿からのいくつかの提案に従い、JMPヘルプでそれを読んでみましたここに、しかし、Sin（x）の三角関数がCos（x）と90のラグを持たない理由を説明する相互相関の計算の詳細は見つかりません。
これについての考え/フィードバックは大歓迎です。
ありがとう！、
DS
分析データ表その他Re：時系列プラットフォームの相互相関の出力が正しくありませんか？サンプルサイズが限られているためだと思います。 CCFの連続するポイントの場合、サンプルサイズは1だけ異なります。 さらに3600行を追加し、プロットを再度実行すると、ピークは90に近くなり、振幅もピークで1に近くなります。
Re：時系列プラットフォームの相互相関の出力が正しくありませんか？こんにちは@peng_liu 、
フィードバックをお寄せいただきありがとうございます。 私はもっと多くの行を試しましたが、それほど多くは試しませんでした。 有限のサンプルサイズが計算にどのように影響するかは理解していますが、それが計算に大きな影響を与えることに少し驚いています。 私は小さな違いを想像することができます、おそらくより小さな有限集合で88または89ですが、12オフになることはかなり大きいようです。 私の懸念は、時系列データセットが限られている可能性がある実際の状況についてはどうでしょうか。
ちなみに、行の追加を正しく考慮していないDeg列の間違いにも気づきました。 式は次のようになります。
このように、次数データは常に-180から180まで実行されます（増分サイズのため、一方の端ともう一方の端でわずかな違いがあります）。
たとえば、実際の限られたデータセットの場合、15分間だけ毎秒データを収集するデバイスがあるかもしれません。 それはたった900のデータポイントです。 その状況によると、実際には90であるのに、2つの信号には78の遅れがあると結論付けることができます。 シグナルラグが78であると結論付けるのは誤りであり、誰かがデータの誤った分析を開始する可能性があります。 何があっても
この特定のケースでは、知っている実際のラグはアプリオリですが、実際の状況では、それが常にわかっているわけではありません。 同じイベントが異なる場所で測定され、信号の遅れを決定する必要があるデータセットを想像できますが、データセットはかなり制限されています。 相互相関関数がどのように機能するかに基づいて、これは誤った結論をもたらす可能性があります。
これを補う方法、または限られたデータセットを説明するための計算を補う方法はありますか？ ラグの信頼区間を取得するために、スワップアウトしてラグ量のシミュレーションを実行する他の機能列がありますか？ それはどのような機能的な列でしょうか？
正しい式を使用して評価をやり直し、任意の数の行を許可すると、ラグ値から次数値に変換し直しても、正しい答えが得られません。 たとえば、3601行（0〜3600の値）の場合、次のようなラグプロットが得られます。
Get lagsスクリプトを実行すると、ラグが度に変換される列（元のテーブルの3601行に基づく以下の式）を見ると、次のようになります。
"Corr vs. Sin（x-5）lag in deg = [-4.89863926687031]"
「Corrvs.Sin（x-5）lag in lag = [-49]」
"Corr vs. Sin（x-45）lag in deg = [-40.2888086642599]"
「Corrvs.Sin（x-45）lag in lag = [-403]」
"Corr vs. Cos（x）lag in deg = [78.4782004998612]"
「Corrvs.Cos（x）lag in lag = [785]」
以下は、900行と785行だけ遅れているCos（x）を使用したSin（x）のプロットです。 見てわかるように、785は行900（赤い曲線）で発生する正しいラグ値ではありません。
だから、私はまだ正しい値を取得していません。 新しいデータテーブルが添付されます。 私はまだ何か正しいことをしていないという予感があります-おそらくどこかで間違った式ですか？ なぜ正しい値が得られないのか理解できません。
助けてくれてありがとう！、
DS
Re：時系列プラットフォームの相互相関の出力が正しくありませんか？2番目のデータセットに問題があります。 2番目のデータのSin（x）は次のようになります。
これは私の3601行がどのように見えるかです：
これが、SinXおよびCosXCCFが変更されない理由を説明しています。
ここで重要なサンプルサイズは、ここでの観測数ではなく、サイクル数です。 元のデータでは、サイクルは1つだけです。 CCFを計算するには、系列をシフトする必要があります。これにより、1つの系列に欠落値が作成され、サンプル平均が激しく変動します。 サイクルが多い場合、平均は真の値であるゼロに近いままになります。
実際の状況で、データのサイクルが1つしかない場合、CCFは誤解を招くと思いますが、それはデータの問題であり、修正する方法はありません。
Re：時系列プラットフォームの相互相関の出力が正しくありませんか？こんにちは@peng_liu 、
ご説明ありがとうございます。 私は今、問題が何であったかを理解し、それは理にかなっています。 時間「ウィンドウ」内により多くのサイクルを含めると、正しい値が得られることを確認できます。
さて、本当の難問について：
私の生産部門の同僚は、生産履歴システムからのデータ（オーブンの温度、ベルト速度、流量などを記録する）と材料のQC測定値との間のタイムラグを見つけたいと考えています。 生産データは、15分、30分、4時間など、任意の間隔でシステムからエクスポートできます。 4時間ごとのかなり定期的なQCテストスケジュールがあります。 正しいタイムラグが見つかれば、生産履歴データをQCデータと相関させることができると考えられています。 たとえば、製造時の乾燥機の温度はQCテストと相関すると考えられていますが、QCテストはおそらく120分で行われます。後材料はすでに乾燥機を通過しています。 ラボ規模の研究から、特定の処理ステップ（オーブン温度などの値）が特定のテスト結果と相関していることがわかっていますが、これを本番データで見つけることは、ラボよりも困難であることが証明されています。
時系列の相互相関を使用して、データ内のあらゆる種類のラグを検出できるかどうかを確認し、複数のラグ列を手動で作成し、多変量プラットフォームを使用してラグ列とQCデータ間の相関を探しました。でも何も見えません。 当然、相関関係がプロセスのノイズから洗い流される可能性がありますが、他のオプションは、時系列または多変量プラットフォームのどちらも、正しいタイムラグを決定しようとするのに適切なものではないということです。
フィードバックと考え/入力をありがとうございました、それは非常に役に立ちました。
ありがとう！、
DS
