L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 211
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
1) Sfortunatamente, hai formulato la domanda in modo incompleto e hai ottenuto una risposta non esaminata e brevemente educata "non importa".
Lei voleva una risposta "così concordata/convenzione" formulandola nella domanda stessa. Ma Duncan se l'è cavata con "ciò che è giusto" la prima volta e l'ha ripetuto la seconda volta.
2) Non hai avuto conferma della precisione in R e non hai avuto una risposta sul perché il risultato è diverso in altri pacchetti. Analizzare la domanda "perché la risposta è diversa in altri pacchetti" è più importante ed è in grado di rivelare l'argomento.
3) La nostra posizione:
выражение для dgamma
(x)= 1/(s^a Gamma(a)) x^(a-1) e^-(x/s)
for x ≥ 0, a > 0 and s > 0в точке 0 является неопределенным.
R ritiene che si possa includere questo punto nel calcolo ma prendere i valori limite anche se sono infiniti come nel caso di dgamma(0,0.5,1).
Tuttavia, se si calcolano le probabilità date all'infinito nel punto zero, tutti gli integrali di dgamma diventano formalmente infiniti e per questa logica pgamma dovrebbe essere uguale a infinito per tutti i valori di x.
Tuttavia, questo contraddice i risultati di pgamma, dove tutti i valori risultano essere finiti. Sono corretti, perché se nel punto x=0 si assume che la densità =0.1) Sì, non ho avuto una risposta dettagliata. Anche se l'ho riassunto... Non sto imponendo la mia opinione, anche io sono stanco di discutere, ad essere onesto. Richiamo la vostra attenzione sul fatto che le parole di questa persona erano quasi verbatim al nostro messaggio originale. Come determinare la densità nel punto estremo non è importante, l'importante è calcolare correttamente gli integrali:
Dichiariamo che, a rigore, la densità della distribuzione gamma al punto zero è indefinita. E prendendo il limite a destra, la densità è uguale a uno.
Alla luce di ciò pensiamo che l'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.
2) Non si parlava nemmeno di precisione da parte mia. La densità al punto zero non è una questione di precisione, ma di come la si ricava come risultato della funzione - non convergenza (NaN) o equiparazione al limite o a zero. Il punto principale è che non ha importanza per il calcolo dell'integrale.
3) Ho riletto il testo corretto dell'articolo. E sono contento che tu abbia deciso di non considerare il comportamento di dgamma come un errore.
Ma questo :
tutti gli integrali di dgamma diventano formalmente infiniti e per questa logica pgamma dovrebbe essere uguale a infinito per tutti i valori di x.
Strano, Renat.
pgamma in linea di principio non può essere infinito, poiché l'ingegrale è delimitato dall'alto da un valore di 1.
Prendiamo la distribuzione normale. È definito su [-inf,+inf]. Integrale della funzione di distribuzione = 1 in tutto questo intervallo. Ma in qualche modo si scopre che la somma (integrazione) della densità su una saporte infinitamente grande non risulta in una somma infinita. Anche se la densità su tutto il keepport != 0 in qualsiasi regione.
E per dgmamma il punto x ==0 con la sua densità == inf (e a proposito, non hai considerato il caso in cui la densità tende a 1 in questo punto e quali conclusioni sull'integrazione trai da questo...) quanto spesso si verifica? Direi che non è così. La probabilità di realizzare una variabile casuale in qualsiasi punto == 0 in qualsiasi distribuzione continua... Tutti gli statistici lo sanno. La densità è considerata come un'approssimazione della probabilità in una regione infinitesimale intorno a x.
Segue da questo fatto che non importa quanto sia grande la densità nel punto estremo, il suo effetto sull'ingrale totale = 0. Pensateci...
Credo che tu stia pensando troppo. ) Ma non ho intenzione di discutere e capire. Forse un giorno me ne renderò conto e risponderò io stesso invece di Duncan. )
Grazie.
R è un sistema incredibile che mi ha personalmente aperto gli occhi su quanto eravamo lontani in MetaTrader/MQL dalle reali esigenze di "rendere i calcoli complessi semplici e subito".
Noi (sviluppatori C++) abbiamo nel sangue l'approccio "tu puoi fare tutto da solo e noi ti diamo la base di basso livello e la velocità dei calcoli". Siamo fanatici delle prestazioni e siamo bravi a farlo - MQL5 è ottimo su 64 bit.
Quando ho iniziato a lavorare io stesso su R mi sono reso conto che avevo bisogno di quante più funzioni potenti possibili in una linea e di poter fare ricerca in generale.
Quindi abbiamo preso una brusca svolta e abbiamo iniziato ad aggiornare MetaTrader 5:
Certo, siamo all'inizio del cammino, ma il giusto vettore di sforzi è già chiaro.
Sette passi nell'integrazione non sono certo sufficienti. Eccone 1.000:
[1] 0.7940968
#а теперь велосипедное интегрирование:
> integration_steps <- seq(0, 0.8, length.out=1001)
> integration_result <- 0
> for(i in 2:length(integration_steps)){
+ integration_result <- integration_result + dgamma(integration_steps[i], 0.5, 1) * (integration_steps[i] - integration_steps[i-1])
+ }
> integration_result
[1] 0.7709089
#погрешность ~0.02, но тут способ уже проще некуда, и так сойдёт :) . Бесконечность при x=0 не мешает.
1) Sì, non ho avuto una risposta dettagliata. Anche se stavo riassumendo... Non sto imponendo la mia opinione, anche io sono stanco di discutere, ad essere onesto. Richiamo la vostra attenzione sul fatto che le parole di questa persona erano quasi verbatim al nostro messaggio originale.
Era una risposta educata senza dettagli o verifiche. E la risposta non coincideva con Wolfram Alpha e Matlab, il che è un problema.
Non c'è bisogno di fare il passo più lungo della gamba - la domanda principale è stata posta chiaramente.
#погрешность ~0.02, но тут способ уже велосипедней некуда, и так сойдёт :) . Бесконечность при x=0 не мешает.
Integrare la funzione 1/x, da 0 a 1, includendo i punti limite e confrontare con il risultato dei calcoli analitici.
Wolfram dice che l'integrale non convergerà a causa della singolarità a x=0.
Integrare la funzione 1/x, da 0 a 1, compresi i punti limite e confrontare con il risultato dei calcoli analitici.
Con lo stesso codice - 7.485471. R è arrivato a 76,3342 e ha detto che non sarebbe andato oltre, e questo non è un risultato accurato, e non è corretto. Wolfram ha subito detto che il risultato non quadra, e non ha risposto a nulla.
La risposta giusta non la so, quanto?
Non dirmi che siccome non si può trovare l'integrale di 1/x, non si può trovare neanche l'integrale di dgamma(x). Le due funzioni tendono all'infinito in x -> 0+ , ma tendono a velocità diverse, e questa velocità influenza il fatto che l'integrale possa essere trovato o meno.
Esiste una funzione -log(x). Tende all'infinito a x->0. Si può fare senza meno, allora tende verso il basso, ma non mi sento a mio agio con questo.
E ha un integrale da 0 a 1. L'infinito non interferisce.
R è un sistema incredibile che personalmente mi ha aperto gli occhi su quanto eravamo lontani in MetaTrader/MQL dalla reale necessità di "fare calcoli complessi in modo semplice e diretto ora".
...
Così abbiamo fatto una brusca virata e abbiamo iniziato ad aggiornare MetaTrader 5:
Certo, siamo all'inizio del viaggio, ma il giusto vettore di sforzi è già chiaro.
R, così come molti altri linguaggi di programmazione, è di gran lunga più conveniente per l'apprendimento automatico rispetto a MQL, in quanto ha un set di funzionalità integrate per l'elaborazione dei dati di matrice. Il fatto è che un campione per l'apprendimento automatico è molto spesso un array di dati bidimensionale, quindi ha bisogno di un funzionale per lavorare con gli array:
Fino a quando MQL non avrà implementato il suddetto funzionale necessario per gestire i campioni negli array, la maggior parte degli sviluppatori di algoritmi di apprendimento automatico preferirà altri linguaggi di programmazione che hanno già tutto questo a disposizione. Oppure useranno MLP senza pretese (algoritmo degli anni '60) dalla libreria AlgLib dove, se ricordo bene, per comodità gli array bidimensionali sono rappresentati come monodimensionali.
Naturalmente, le funzioni per le densità delle distribuzioni casuali sono anche una funzionalità necessaria. Ma tali funzioni non sono sempre necessarie nei compiti di apprendimento automatico, e in alcuni compiti non sono utilizzate affatto. Ma le operazioni con i campioni, come con gli array multidimensionali, è qualcosa di cui l'implementazione degli algoritmi di apprendimento automatico non può fare a meno per qualsiasi compito, a meno che, naturalmente, non sia un compito di addestramento di una griglia per imparare i dati normalizzati noti da banali CWR.
R è un sistema incredibile, che personalmente mi ha aperto gli occhi su quanto fossimo lontani in MetaTrader/MQL dalle reali esigenze di "rendere i calcoli complessi semplici e subito".
Noi (sviluppatori C++) abbiamo nel sangue l'approccio "tu puoi fare tutto da solo e noi ti diamo la base di basso livello e la velocità dei calcoli". Siamo fanatici delle prestazioni e siamo bravi a farlo - MQL5 è ottimo su 64 bit.
Quando ho iniziato a lavorare io stesso su R mi sono reso conto che avevo bisogno di quante più funzioni potenti possibili in una linea e di poter fare ricerca in generale.
Quindi abbiamo preso una brusca svolta e abbiamo iniziato ad aggiornare MetaTrader 5:
Certo, siamo all'inizio del cammino, ma il giusto vettore di sforzi è già chiaro.
Questa è una valutazione equilibrata e sorprendentemente obiettiva di R.
La parte costruttiva della discussione non è stata sprecata. Ascoltate i commenti e i suggerimenti degli utenti di R. Anche noi siamo interessati a migliorare la piattaforma.
Naturalmente siete all'inizio, ma in ogni caso i vaccini R rafforzeranno il MCL.
Buona fortuna per il vostro duro lavoro.
Per quanto riguarda le convenzioni di cui parlava Burnakov.
Consideriamo tre casi molto diversi.
1. Divisione per una costante uguale a zero.
In R abbiamo il risultato
[1] Inf
È un risultato corretto?
Per l'interprete, questo risultato deve essere considerato corretto, perché non possiamo terminare R
Per il compilatore, questo risultato è corretto. Quando si verifica una situazione eccezionale, l'esecuzione del programma viene interrotta e viene dato il controllo per gestire questa situazione eccezionale, altrimenti si blocca.
Notate come è diverso!
2. Divisione per una variabile, uguale a zero.
> 1/a
[1] Inf
In senso stretto, questa variante differisce dalla precedente.
La funzione 1/a è continua ovunque tranne a=0. In questo punto il limite a sinistra = -Inf, e il limite a destra = +Inf.
R non lo capisce, ma potete accettarlo perché la differenza tra meno infinito e più infinito ha senso in matematica, non nel codice del programma
3. Divisione di due quantità infinitesime nella loro aspirazione a zero
[1] NaN
Il significato di NaN non ha alcuna spiegazione per me. Ma è abbastanza chiaro, dato il punto 2, che R non capisce i limiti in quanto tali.
Sono errori di R come sistema di programmazione? Non lo so. Molto probabilmente la documentazione di R avrebbe dovuto informare su tali sfumature, ma poi come implementarlo con uno sviluppo decentralizzato al momento circa 130.000 funzioni? Ne abbiamo bisogno?
Cosa ne consegue nel senso della discussione che ne è scaturita?
Le decisioni vengono prese a terra.
1. prendiamo R e trasferiamo senza mezzi termini il codice in MKL. Allo stesso tempo dobbiamo renderci conto che le varianti sopra menzionate possono avere diverse interpretazioni in diverse funzioni di R
2. dichiarare gli accordi, quali valori saranno accettati nei casi che ho menzionato (la lista può essere incompleta). Controlliamo accuratamente il codice R e se non corrisponde alle nostre impostazioni, lo portiamo da R a MCL con correzioni secondo i nostri accordi. In questo caso, grazie allo sviluppo centralizzato, implementiamo coerentemente gli accordi accettati e in questo senso, abbiamo un sistema migliore.