L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 3151
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
la dimensione della finestra della cronologia è solo una grande limitazione per i MO classici con dati tabellari
Le AS (asoc. rules) non soffrono di questa malattia, digeriscono perfettamente i dati non strutturati, inoltre ogni osservazione può essere di dimensioni arbitrarie.
E la stessa "finestra di visione" (finestra della storia) può essere limitata solo dalla potenza di calcolo. o dal buon senso.
Quindi il tuo esempio con la dimensione della finestra della storia è solo un voto a favore di AC e contro MO.
Dammi qualche altra argomentazione, sono curioso di sapere se mi manca davvero qualcosa.
E un'altra domanda: quanto ti piace l'UA?
Non mi sono immerso nelle regole. Ho già scritto che sono arrivato all'applicazione delle grammatiche formali dall'altra parte - ho guardato il prezzo come costruito dalla grammatica stocastica. Ho abbandonato l'approccio proprio per la sua macchinosità, che è un male innanzitutto perché provoca overtraining.
Ora evito i modelli pesanti. La regola informale principale per me è che la pesantezza del modello dovrebbe corrispondere alla pesantezza dell'informazione nel campione.
Il vostro modello è abbastanza pesante per un modello di prezzo completo, ma il campione di prezzi che abbiamo (anche se aggiungiamo altre informazioni) non è sufficiente per un modello di questo tipo.
Naturalmente, IMHO
Come fa AMO a trovare un modello nell'esempio?
Ho descritto il tutto in modo molto modesto per motivi di chiarezza, in realtà l'aspetto è più simile a questo.
E il vostro modello vede solo questo: (le ultime 5 candele non orarie).
Si noti anche che non c'è alcun legame con l'indice, se un evento importante è stato ieri 200 candele fa, oggi lo stesso evento può essere già 1555 candele fa o 12 per esempio....
AC troverà questo schema, AMO no!
AMO ha bisogno che ogni funzione abbia sempre la stessa colonna nella tabella, in modo da essere attivata sempre sotto lo stesso indice.
o come questo, che è anche piuttosto visivo.
e il modellatore lo vede.
Comunque, spero di aver chiarito il mio punto di vista.
A proposito, come sta andando lo studio sul pitone?
A proposito, come sta andando lo studio sul pitone?
È un buon linguaggio, ma da un certo punto di vista diventa troppo complicato per un non programmatore. Per esempio, è molto più difficile scrivere estensioni in C che in R. Mi sono piaciute molto le tabelle in numpy.
Non mi sono immerso nelle regole. Ho già scritto che sono arrivato all'applicazione delle grammatiche formali dall'altra parte: ho guardato il prezzo come costruito dalla grammatica stocastica. Ho rinunciato a questo approccio proprio per la sua macchinosità, che è un male prima di tutto perché provoca un overtraining.
Ora evito i modelli pesanti. La regola informale principale per me è che la pesantezza del modello deve corrispondere alla pesantezza dell'informazione nel campione.
Il vostro modello è abbastanza pesante per essere un modello di prezzo a tutti gli effetti, ma il campione di prezzi che abbiamo (anche se aggiungiamo altre informazioni) non è sufficiente per un modello di questo tipo.
Naturalmente, IMHO
100%
Si noti anche che non c'è alcun legame con l'indice, se un evento importante è stato ieri 200 candele fa, oggi lo stesso evento può essere già 1555 candele fa o 12 per esempio....
AC troverà un tale pattern, AMO no!
AMO ha bisogno che ogni funzione abbia sempre la stessa colonna nella tabella, in modo da essere attivata sempre sotto lo stesso indice.
o in questo modo, che è anche piuttosto visivo.
Curioso, sto facendo esattamente quello che ho descritto circa mezzo anno fa.
Non capisco come le vostre regole cerchino il valore di una caratteristica in verticale senza fare riferimento all'indice - nel mio concetto dovrebbe esserci un intervallo di ricerca accettabile - non capisco la vostra implementazione.
Curioso, fare esattamente quello che ho descritto circa mezzo anno fa.
Non capisco come le vostre regole cerchino il valore di una caratteristica in verticale senza fare riferimento all'indice - nel mio concetto ci dovrebbe essere un intervallo di ricerca accettabile - non capisco la vostra implementazione.
È un buon linguaggio, ma a partire da un certo livello diventa troppo complicato per un non programmatore. Ad esempio, è molto più difficile scrivere estensioni in C che in R. Mi sono piaciute molto le tabelle in numpy.
domanda sacrosanta)
per le ricerche di mercato - R o python?
domanda di holivar)
per le ricerche di mercato - R o Python?
Per le ricerche di mercato da parte mia, al momento - R. Non sono pronto a garantire per altri o per me stesso in futuro).
I soliti algoritmi di regole associative, diversi a seconda del problema.
Non so nemmeno di quale codice stiamo parlando - a quanto pare qualcosa non ha funzionato. Di quale codice stiamo parlando?
Lei sostiene che la profondità non è importante per gli eventi nel tempo - e come è scritto dalla regola - non ho capito.