L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 1547

 
Maxim Dmitrievsky:

Non lo so, è sempre diverso.

Hmm, quindi forse pensare a un modo per scoprirlo?

A proposito, posso costruire un modello in R usando i tuoi dati - se sei interessato al confronto dell'efficienza dei metodi.
 
Aleksey Vyazmikin:

Hmm, possiamo pensare a un modo per scoprirlo?

A proposito, posso costruire in R il modello dai vostri dati - se siete interessati al confronto dell'efficienza dei metodi.

non si può già fare niente di meglio, il modello è perfetto e conferma la natura casuale di kotir

ulteriori miglioramenti possono essere fatti solo con diversi metodi di lavoro con processi casuali, come ho scritto sopra

 
Maxim Dmitrievsky:

non si può fare niente di meglio, il modello è perfetto e conferma la natura casuale di kotir

Ulteriori miglioramenti possono essere fatti solo con diversi metodi di lavoro con processi casuali, come ho scritto sopra

Soluzioni casuali per processi casuali mi sembra un metodo troppo rischioso nella sua ideologia...

 
Maxim Dmitrievsky:

Sto tornando a qualcosa che volevo fare da molto tempo - MO + stoh

http://www.turingfinance.com/random-walks-down-wall-street-stochastic-processes-in-python/

L'argomento è interessante - specialmente il modello di salto di Merton o qualche sua variante. Sembra che, a differenza della diffusione convenzionale, non si riduca (per campionamento temporale) all'autoregressione, o lo si faccia in qualche modo non banale. Forse i calcoli in una finestra scorrevole per un portafoglio saranno abbastanza inaccessibili.

 

La foresta casuale è una storia adatta senza possibilità di aggiustamento. Ho spremuto ogni opzione da SL un anno fa.

La regressione lineare ha molte più possibilità di produrre un profitto. Quando ci si allena, bisogna alimentare i prezzi relativi, non i prezzi reali.

Pytorch = TensorFlow 1.x + Keras + Numpy = TensorFlow 2.0

 
Roffild:

Pytorch = TensorFlow 1.x + Keras + Numpy = TensorFlow 2.0

Quale configurazione di griglia ti piace?

 

Il costruttore è forte!

Per esempio, molte persone usano mentalmente "funzioni di attivazione" anche quando non sono necessarie. "Funzioni di attivazione" = conversione di dati in una certa gamma di valori con perdita parziale o completa di informazioni - è come una funzione hash per un file.

Se l'input è già costituito da dati normalizzati, allora le "funzioni di attivazione" tra gli strati non sono necessarie, cazzo. Non potete sbarazzarvi della "funzione di attivazione" in Alglib.

Ho un intero sistema di controllo delle modifiche sotto forma di Jenkins + MLFlow per enumerare le varianti e memorizzare i risultati.

Ora la configurazione è così:

Sequential(
  (input): Linear(in_features=2836, out_features=1000, bias=True)
  (hidden1): Linear(in_features=1000, out_features=100, bias=True)
  (hidden2): Linear(in_features=100, out_features=2, bias=True)
  (output_activ): Softmax()
)

Naturalmente, non ho capito subito come addestrare la rete sulla scheda video a scapito della latenza dei dati. Ora il mio codice è ottimizzato e impara 100 volte più velocemente dalla versione originale, riducendo la quantità di dati caricati sulla scheda video.

 
Roffild:

Il costruttore è forte!

Per esempio, molte persone usano mentalmente "funzioni di attivazione" anche quando non sono necessarie. "Funzioni di attivazione" = conversione di dati in una certa gamma di valori con perdita parziale o completa di informazioni - è come una funzione hash per un file.

Se l'input è già costituito da dati normalizzati, allora le "funzioni di attivazione" tra gli strati non sono necessarie, cazzo. In Alglib non potete sbarazzarvi della "funzione di attivazione".

Ho un intero sistema di controllo delle modifiche sotto forma di Jenkins + MLFlow per enumerare le varianti e memorizzare i risultati.

Ora la configurazione è così:

Naturalmente, non ho capito subito come addestrare la rete sulla scheda video a scapito della latenza dei dati. Ora il mio codice è ottimizzato e sta imparando 100 volte più velocemente dalla versione originale, riducendo la quantità di dati caricati sulla scheda video.

e il livello ricorsivo? lstm o gru

 
Roffild:

Il costruttore è forte!

Per esempio, molte persone usano mentalmente "funzioni di attivazione" anche quando non sono necessarie. "Funzioni di attivazione" = conversione di dati in una certa gamma di valori con perdita parziale o totale di informazioni - è come una funzione hash per un file.

Se l'input è già costituito da dati normalizzati, allora le "funzioni di attivazione" tra gli strati non sono necessarie, cazzo. Non potete sbarazzarvi della "funzione di attivazione" in Alglib.

Ho un intero sistema di controllo delle modifiche sotto forma di Jenkins + MLFlow per enumerare le varianti e memorizzare i risultati.

Ora la configurazione è così:

Naturalmente, non ho capito subito come addestrare la rete sulla scheda video a scapito della latenza dei dati. Ora il mio codice è ottimizzato e impara 100 volte più velocemente dalla versione originale, riducendo la quantità di dati caricati sulla scheda video.

La velocità è bella, ma secondaria.
La vostra NS sta prevedendo con successo il futuro? Se è così, sarebbe interessante vedere il segnale o almeno i risultati del tester con il forward.
 
Maxim Dmitrievsky:

e il livello di ricorrenza? lstm o gru

Potrei aggiungere, ma in questo momento voglio testare completamente la mia variante. Ho solo bisogno di aggiungere 1 linea al codice per cambiare la struttura della rete. Non stiamo traducendo un testo, ma riconoscendo un evento storico.

https://pytorch.org/docs/stable/nn.html - scegliete qualsiasi livello che vi piace e aggiungetelo su una linea.

torch.nn¶
  • pytorch.org
class ¶ A kind of Tensor that is to be considered a module parameter. Parameters are subclasses, that have a very special property when used with s - when they’re assigned as Module attributes they are automatically added to the list of its parameters, and will appear e.g. in iterator. Assigning a Tensor doesn’t have such effect. This is...