L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 197
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
Mi chiedevo - prendete solo i valori dei prezzi e diversi indicatori dai prezzi come predittori qui? e qualcuno usa i volumi reali e gli indicatori dai volumi?
Lavoro con i prezzi, senza volume.
Ho provato a usare i volumi e i loro indicatori, ma non ha funzionato. Non ci sono volumi reali nel forex, ma ci sono ticks, che sembrano corrispondere un po' a quelli reali, cioè in linea di principio si può provare. Ma il problema è che la storia delle barre e dei tick del broker contiene alcuni volumi"non così" tick. Mentre il simbolo è nella piazza del mercato nel terminale in esecuzione - c'è una storia corretta dei volumi di tick per esso. Se il simbolo viene rimosso dal wotch o il terminale viene chiuso - i volumi di tick per queste barre saranno presi come dati dal broker. E questi due valori, "digitato dal terminale" e "ricevuto dal broker" sono completamente diversi, a volte dieci volte. Ora ho bisogno di tenere il terminale in funzione per un paio di mesi per ottenere i volumi di tick reali, non quelli che mi dà il broker, poi posso provare a usarli di nuovo.
Lavoro con i prezzi, senza volume.
Ho provato a usare i volumi e i loro indicatori, ma non ha funzionato. Non ci sono volumi reali nel forex, ma ci sono ticks, che sembrano corrispondere un po' a quelli reali, cioè in linea di principio si può provare. Ma il problema è che la storia delle barre e dei tick del broker contiene alcuni volumi di tick"non tali". Mentre il simbolo è nella piazza del mercato nel terminale in esecuzione - c'è una storia corretta dei volumi di tick per esso. Se il simbolo viene rimosso dal wotch o il terminale viene chiuso - i volumi di tick per queste barre saranno presi come dati dal broker. E questi due valori, "digitato dal terminale" e "ricevuto dal broker" sono completamente diversi, a volte dieci volte. Ora ho bisogno di tenere il terminale in funzione per un paio di mesi per ottenere volumi di tick reali e non quelli del broker e poi posso provare a usarli di nuovo.
Per informazioni sul linguaggio R e la nuova MetaTrader 5 build 1467:
Distribuzioni statistiche in MQL5 - prendere il meglio da R e renderlo più veloce
Molte nuove funzioni matematiche e statistiche simili a R saranno aggiunte nelle prossime versioni. Questo permetterà più calcoli e visualizzazioni direttamente in MetaTrader 5.Puoi aggiornare alla 1467 dal server MetaQuotes-Demo.
Caro Renat!
Permettetemi di rispondere al commento sul punto 6. Gli errori di calcolo rilevati in R nel link citato:Distribuzioni statistiche in MQL5 - prendere il meglio da R e renderlo più veloce
Il controllo è stato eseguito per la funzione Gamma. Lasceremo il controllo del resto delle funzioni alla vostra responsabilità.
A nome del dipartimento Data Science, rappresentato dal manager e da due statistici (posso informarvi in PM) vi informiamo che la densità della distribuzione gamma al punto zero non si riduce a zero, in senso stretto.
R stima infatti che la densità nel punto zero sia 1:
x <- seq(0, 20, 0.5) #support
plot(k, dgamma(x = x, shape = 1, scale = 1, log = FALSE)) #PDF plot
print(dgamma(x = 0.000001, shape = 1, scale = 1, log = FALSE)) #limiting to zero
Tuttavia, possiamo vedere che quando x tende a zero, la densità si avvicina all'unità.
Inoltre, secondo:
https://en.wikipedia.org/wiki/Gamma_distribution
a x = 0, alfa = 1, beta = 1, il numeratore dà un valore indeterminato, che porta l'intera frazione nell'incertezza.
Affermiamo che, a rigore, la densità gamma della distribuzione al punto zero è indefinita. E prendendo il limite a destra, la densità è una.
Alla luce di ciò, crediamo che la formulazione dell'affermazione "errori di calcolo in R" non sia corretta. Più precisamente, è una questione di convenzione: cosa si deve considerare uguale all'espressione zero alla potenza di zero. Equiparare la densità della distribuzione gamma a zero nel punto zero non sembra essere una pratica condizionale.
Sv.
Alexey
Dichiarare che, a rigore, la densità della distribuzione gamma al punto zero è indefinita. E quando si prende il limite a destra, la densità è uguale a uno.
Alla luce di ciò, pensiamo che la formulazione dell'affermazione "errori di calcolo in R" non sia corretta. Più precisamente, è una questione di convenzione: che equiparare l'espressione zero alla potenza di zero. Equiparare la densità della distribuzione gamma a zero nel punto zero non sembra essere una pratica condizionale.
Se la densità (pdf) è non-zero, allora anche l'integrale (cdf) in quel punto deve essere non-zero, altrimenti zero non è possibile.
Ma cdf=0. È difficile da spiegare.
A x=0 la pdf è zero per definizione:
Wolfram Alpha:
Per distribuzioni chi-quadro non centrali e centrali:
Se la densità (pdf) è non-zero, allora anche l'integrale (cdf) in quel punto deve essere non-zero, altrimenti non c'è zero.
Ma cdf=0. Questo è difficile da spiegare.
A x=0 la pdf è zero per definizione:
Wolfram Alpha:
Per distribuzioni chi-quadro non centrali e centrali:
Faresti meglio a dirci da te stesso cos'è 0 ^ alfa - 1, quando alfa = 1.
L'integrale non è definito neanche lì.... Ma nel limite è vicino allo zero. Questione di convenzioni...
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = F)) #right side
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = T)) #left side
e qualcuno usa i volumi reali e gli indicatori di volume?
perché il limite sia definito, deve essere lo stesso per gli approcci a sinistra e a destra, ma questo non è il caso:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
perché il limite sia definito, deve essere lo stesso per gli approcci a sinistra e a destra, ma questo non è il caso:
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
Ce n'è solo uno a destra e quello è 1...
Quello che dice Wolfram 0 non è la verità in ultima istanza. Voglio dire che la parola "errore" nella formulazione è ridondante...
Ho trovato un altro errore in R. R non divide correttamente per 0.
Ecco lo script:
//| test.mq5 |
//| Copyright 2016, MetaQuotes Software Corp. |
//| https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2016, MetaQuotes Software Corp."
#property link "https://www.mql5.com"
#property version "1.00"
#property script_show_inputs
input double div = 0.0;
//+------------------------------------------------------------------+
//| Script program start function |
//+------------------------------------------------------------------+
void OnStart()
{
//---
Print(1.0/div);
}
//+------------------------------------------------------------------+
La risposta corretta, in mql è.
zero divide in 'test.mq5' (20,13)
con arresto dello script
Errato, in R:
> 1/0
Inf
con continuazione dello script
Intendo la stessa cosa di Alexey - il comportamento dei programmi in condizioni non definite può essere diverso, e non è un errore. Come l'architettura deve essere, così sarà il risultato.
Un'altra osservazione interessante. Non si può dividere per zero. E non si può togliere la radice ai numeri negativi. Ricordo dall'università che tutto questo è possibile, ma ora non si tratta di questo, in matematica semplice non si possono fare entrambe le cose.
Perché se divido per 0 in mql allora rompe l'intero script e lo interrompe, ma se estraggo una radice da un numero negativo allora ottengo "-nan(ind)" senza rompere lo script, e questo "-nan(ind)" può essere usato per fare ulteriori calcoli (romperà tutti gli ulteriori calcoli)? Qui è dove mi aspetterei lo stesso comportamento dello script mql in entrambi i casi.