Output errato per la correlazione incrociata nella piattaforma delle serie temporali?Salve JMP Community,
(W10, 64 bit, JMP Pro 15.2.1)
Spero di scoprire cosa sto sbagliando o cosa fraintendo sul modo in cui JMP esegue i calcoli di correlazione incrociata nella piattaforma Time Series. In breve, quando confronto la correlazione incrociata di una funzione Sin (x) con una funzione Cos (x), non ottengo una risposta di pi / 2 (o 90 gradi) come mi aspetterei, ottengo 79 gradi anziché.
Sto cercando di mettere insieme una spiegazione e una descrizione semplificate di cosa significa per alcuni colleghi l'output di Time Series> Cross-correlation. Per fare ciò, ho creato una semplice tabella con 361 righe (valori 0-360, ogni riga è un grado o 0,01745 radianti) e diverse altre colonne che calcolano Sin (x), Sin (x-5), Sin ( x-45), Cos (x) e una distribuzione casuale uniforme (vedere la tabella Periodic_series.jmp allegata). Lo scopo è dimostrare la correlazione incrociata utilizzando semplici funzioni trigonometriche che le persone possono comprendere in modo più diretto rispetto a una complessa funzione dipendente dal tempo, come il set di dati SeriesJ.
Se esegui il primo script nella tabella dati, ottieni un grafico delle funzioni trigonometriche (l'uniforme casuale viene omessa di proposito). Tutto sembra come dovrebbe.
È quindi possibile eseguire lo script delle serie temporali, dove Sin (x) è l'input Y e le altre funzioni sono le colonne dell'elenco di input in modo da poter eseguire l'analisi della correlazione incrociata. Trasformando l'output della correlazione incrociata in una tabella dati (vedere tabella dati cross-correlation.jmp), è possibile tracciare i valori di correlazione rispetto al ritardo (eseguire il primo script in questa tabella dati).
A prima vista, sembra come dovrebbe: la correlazione incrociata di Sin (x) con Sin (x-5) ha il suo picco vicino a -5, Sin (x) con Sin (x-45) sembra essere vicino a -45 e per Sin (x) con Cos (x) è vicino a 90. Tuttavia, se usi il mirino, vedrai che la correlazione incrociata tra Sin (x) e Cos (x) è più vicina a 80.
Infatti, se esegui lo script: Ottieni ritardi nella tabella dati, stampa i ritardi nella finestra Registro:
"Ritardo tra Corr vs. Sin (x-5) in gradi = [-5]"
"Ritardo tra Corr vs. Sin (x-45) in gradi = [-40]"
"Ritardo corr vs. cos (x) in gradi = [79]"
"Ritardo uniforme corr vs. Rondom in gradi = [18]"
L'unico che viene calcolato correttamente è il ritardo di -5. Ritardare Sin (x) di -45 gradi si traduce in un ritardo di -40, non di -45 come previsto. Allo stesso modo, con Sin (x) e Cos (x), il ritardo è 79, quando mi aspetto che il valore sia 90. L'ho provato in molti modi diversi e con molte più righe per vedere se si tratta di un problema di "risoluzione", ma continuo a ricevere un ritardo di circa 80.
O il calcolo non restituisce il ritardo corretto o mi manca qualcosa.Immagino che mi manchi qualcosa, ma non sono sicuro di cosa sia. Ho seguito alcuni suggerimenti da altri post e ho provato a leggerli nella guida di JMP Qui , ma non riesco a trovare alcun dettaglio del calcolo per la correlazione incrociata che spiegherebbe perché una funzione trigonometrica di Sin (x) non ha un ritardo di 90 con Cos (x).
Qualsiasi pensiero / feedback su questo è molto apprezzato.
Grazie!,
DS
AnalyticsTabella datiAltroRi: Output errato per la correlazione incrociata nella piattaforma delle serie temporali?Credo che sia dovuto alla dimensione del campione limitata. Per punti consecutivi su CCF, le dimensioni del campione sono diverse di 1. Ho aggiunto altre 3600 righe, ho rifatto il grafico e il picco è più vicino a 90, anche l'ampiezza è più vicina a 1 al picco.
Ri: Output errato per la correlazione incrociata nella piattaforma delle serie temporali?Ciao @peng_liu ,
Grazie per il feedback. Avevo provato più righe, ma non ne ho provate molte. Sebbene comprenda come la dimensione del campione finito possa influenzare il calcolo, sono un po 'sorpreso che abbia un impatto così grande. Posso immaginare una piccola differenza, forse 88 o 89 con un insieme finito più piccolo, ma avere uno scarto di 12 sembra piuttosto grande. Immagino che la mia preoccupazione riguardi le situazioni del mondo reale in cui potresti avere un set di dati di serie temporali limitato.
A proposito, ho anche notato un errore nella mia colonna Deg che non teneva conto correttamente dell'aggiunta di più righe. La formula dovrebbe essere:
In questo modo, i dati dei gradi verranno sempre eseguiti da -180 a 180 (beh, con la piccola differenza su un'estremità o sull'altra a causa della dimensione dell'incremento).
Ad esempio di un set di dati limitato nel mondo reale, forse hai un dispositivo che raccoglie i dati ogni secondo solo per un periodo di quindici minuti. Sono solo 900 punti dati. Secondo quella situazione, si concluderebbe che i due segnali hanno un ritardo di 78, quando in realtà è 90. Concludere che il ritardo del segnale è 78 sarebbe errato e potrebbe indurre qualcuno a iniziare a fare un'analisi sbagliata dei dati. Non importa cosa
In questo caso particolare, noi conoscere quale sia il vero ritardo a priori, ma in situazioni reali, non è sempre noto. Posso immaginare set di dati, in cui lo stesso evento viene misurato in luoghi diversi e il ritardo nel segnale deve essere determinato, ma il set di dati è piuttosto limitato. In base a come sembra funzionare la funzione di correlazione incrociata, ciò potrebbe portare a una conclusione errata.
C'è un modo per compensare questo o perché il calcolo tenga conto del set di dati limitato? Potresti avere qualche altra colonna funzionale da sostituire e fare una simulazione dell'importo del ritardo per ottenere un intervallo di confidenza sul ritardo? Che tipo di colonna funzionale sarebbe?
Se eseguo nuovamente la valutazione con la formula corretta per consentire un numero arbitrario di righe, non ottengo ancora la risposta giusta, anche quando converto da un valore di ritardo a un valore di grado. Ad esempio, con 3601 righe (valori da 0 a 3600), ottengo i grafici di ritardo in questo modo:
E quando eseguo lo script Ottieni ritardi, ma ora osservando la colonna in cui il ritardo viene riconvertito in gradi (formula di seguito basata sulle righe 3601 nella tabella originale), ottengo:
"Ritardo tra Corr vs. Sin (x-5) in gradi = [-4,89863926687031]"
"Ritardo tra Corr vs. Sin (x-5) = [-49]"
"Ritardo tra correzione e peccato (x-45) in gradi = [-40,2888086642599]"
"Ritardo tra Corr vs. Sin (x-45) = [-403]"
"Ritardo tra correzione e cos (x) in gradi = [78,4782004998612]"
"Ritardo tra correzione e Cos (x) nel ritardo = [785]"
Di seguito è riportato un grafico di Sin (x) con Cos (x) ritardato di 900 e 785 righe. Come si può vedere, 785 non è al valore di ritardo corretto, che si verifica sulla riga 900 (curva rossa).
Quindi, non sto ancora ottenendo i valori giusti. Vengono allegate nuove tabelle di dati. Ho ancora la sensazione che non sto facendo qualcosa di giusto, forse una formula sbagliata da qualche parte? Non riesco a capire perché non ottengo i valori giusti.
Grazie per l'aiuto!,
DS
Ri: Output errato per la correlazione incrociata nella piattaforma delle serie temporali?Ci sono problemi nella seconda serie di dati. Questo è l'aspetto di Sin (x) nei secondi dati:
Questo è l'aspetto delle mie righe 3601:
Questo spiega perché il tuo SinX e CosX CCF non cambia.
La dimensione del campione che conta qui non è il numero di osservazioni qui, ma il numero di cicli. Nei dati originali, c'è solo un ciclo. Per calcolare il CCF, è necessario spostare le serie, il che creerà valori mancanti in una serie, il che farà oscillare selvaggiamente i mezzi di campionamento. Se ci sono molti cicli, la media rimarrà prossima allo zero, il valore vero.
Se in una situazione reale si ha solo un ciclo di dati, credo che CCF sarà fuorviante, ma questo è un problema di dati e non c'è modo di risolverlo.
Ri: Output errato per la correlazione incrociata nella piattaforma delle serie temporali?Ciao @peng_liu ,
Grazie per le tue ulteriori spiegazioni. Ora capisco qual era il problema e ha senso. Posso confermare che ottengo i valori corretti se includo più cicli nella "finestra" temporale.
Ora per il vero enigma:
I miei colleghi di produzione vogliono trovare l'intervallo di tempo tra i dati dal loro sistema storico di produzione (registra cose come la temperatura del forno, le velocità del nastro, le portate, ecc.) E le misurazioni QC sul materiale. I dati di produzione possono essere esportati dal sistema in un dato intervallo, 15 min, 30 min, 4 ore, ecc. Abbiamo un programma di test QC abbastanza regolare ogni 4 ore. Si ritiene che i dati storici della produzione possano essere correlati con i dati QC se è possibile trovare il ritardo di tempo corretto. Ad esempio, si ritiene che la temperatura dell'essiccatore in produzione sia correlata a un test QC, ma il test QC viene eseguito forse 120 min dopo il materiale è già passato attraverso l'asciugatrice. Sappiamo da studi su scala di laboratorio che alcune fasi di lavorazione (valori come la temperatura del forno) sono correlate a determinati risultati dei test, ma trovarli nei dati di produzione si sta rivelando più impegnativi che in laboratorio.
Ho provato a utilizzare la correlazione incrociata nelle serie temporali per vedere se è possibile trovare qualsiasi tipo di ritardo nei dati, nonché creare manualmente più colonne di ritardo e utilizzare la piattaforma multivariata per cercare correlazioni tra le colonne ritardate e i dati QC, ma non vedo niente. Naturalmente, potrebbe essere che qualsiasi correlazione venga eliminata dal rumore durante il processo, ma l'altra opzione è che né le serie temporali né le piattaforme multivariate sono quelle giuste per cercare di determinare l'intervallo di tempo corretto.
Grazie mille per il feedback e i pensieri / input, è stato molto utile.
Grazie!,
DS
