L'apprendimento automatico nel trading: teoria, modelli, pratica e algo-trading - pagina 199
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
Commentate poi, in ordine di letteralità, come per una distribuzione continua uniforme la densità nel punto estremo è positiva e l'integrale è zero: https://en.wikipedia.org/wiki/Uniform_distribution_(continuo)
Torniamo all'affermazione originale sugli errori di R nell'articolo.
La nostra opinione rimane - gli errori ci sono e sono causati dalla disattenzione nell'attuazione.
Il fatto è che @Quantum è una pura implementazione e un controllo completo dell'analogo della libreria matematica R in MQL5.
Questo non è il ragionamento di un teorico. E sta scavando a fondo quando scrive i test unitari che forniscono la garanzia che la libreria sia corretta.
Non si dovrebbe assumere a priori che tutto sia corretto in R. Al contrario, direi che anche se c'è un'implementazione C++ delle funzioni lì, tutto è abbastanza primitivo. E in termini di velocità, si può vedere che la libreria MQL5 nel codice sorgente sul nostro compilatore vince in media di 3 volte.
Ci siamo presi la briga di ricontrollare tutto e abbiamo trovato errori evidenti. Questi errori sono stati confermati:
Guardate le date delle pubblicazioni, per favore. Vedrete come procede il lavoro con i consigli degli scienziati.
Inoltre, sarebbe un errore non considerare @Quantum uno scienziato.
Caro Renat!
Ho le seguenti domande sui suoi ultimi post, che sono per me questioni di principio:
1. A giudicare dalla data di pubblicazione del suo articolo è l'anno 2003. Naturalmente, R, come qualsiasi altro sistema software, ha degli errori e una lista di correzioni viene sempre pubblicata al momento del rilascio. Allo stesso tempo, R ha sempre sottolineato che il basso livello di bug dovuto al numero estremamente grande di utenti è una virtù di R. E qui dal 2003 un bug nell'algoritmo è stato identificato a livello di pubblicazione e non è stato risolto. Questo non mi è chiaro.
Avete fatto una richiesta a R su questo argomento?
2. Mi piacerebbe vedere il codice con cui sono state confrontate le prestazioni di R e MQL5.
Lo apprezzo in anticipo.
Caro Renat!
Ho le seguenti domande sui tuoi ultimi post, che sono fondamentali per me:
1. A giudicare dalla data di pubblicazione dell'articolo, è il 2003. Naturalmente, R, come qualsiasi altro sistema software, ha degli errori e una lista di correzioni viene sempre pubblicata al momento del rilascio. Allo stesso tempo, R ha sempre sottolineato il basso livello di bug dovuto al numero estremamente grande di utenti come un vantaggio di R. E qui dal 2003 un bug nell'algoritmo è stato rilevato a livello di pubblicazione e non è stato corretto. Questo non mi è chiaro.
È elementare e assolutamente chiaro.
Tutti commettono errori - è quello che fanno gli sviluppatori. Facciamo un sacco di errori e non ci scoraggiamo.
Questo errore in R è solo dovuto alla disattenzione e alla dipendenza da una funzione di base che ha incasinato le altre. Correggetelo.
Avete fatto una richiesta a R su questo argomento?
Abbiamo condotto test, esaminato tutto nei dettagli mentre scrivevamo la libreria, confrontato costantemente MQL5 - Wolfram Alpha - R, mostrato i nostri risultati e siamo pronti a rispondere pubblicamente. Naturalmente, abbiamo allegato tre grandi script con test unitari e un benchmark al nostro pacchetto matematico (che è nel codice sorgente).
Sono sicuro che @Quantum scriverà un rapporto di bug in R. L'articolo aggiornato è stato rilasciato solo un paio d'ore fa.
Mi piacerebbe vedere il codice che confronta le prestazioni di R e MQL5.
Il codice del benchmark per MQL5 si trova in \Scripts\UnitTests\Stat\TestStatBenchmark.mq5 e il codice R può essere trovato alla fine dell'articolo Distribuzioni statistiche in MQL5 - prendere il meglio da R e renderlo più veloce, vedi "Appendice. Risultati del calcolo della linea temporale delle funzioni statistiche".
Si assicuri di aggiornare a MetaTrader 5 build 1467 collegandosi al server MetaQuotes-Demo, per favore. È in questa versione beta che abbiamo incluso la nuova libreria e tutti gli script di test.
Questo è elementare e completamente comprensibile.
Tutti commettono errori - è la natura degli sviluppatori. Facciamo un sacco di errori e non ci scoraggiamo.
Questo errore in R è solo dovuto alla disattenzione e alla fiducia in una funzione di base che ha incasinato le altre. Sarà corretto.
Abbiamo condotto test, esaminato tutto nei dettagli mentre scrivevamo la libreria, confrontato costantemente i risultati tra MQL5 - Wolfram Alpha - R, mostrato i nostri risultati e siamo pronti a rispondere pubblicamente. Naturalmente, abbiamo allegato tre grandi script con test unitari e un benchmark al nostro pacchetto matematico (che è nel codice sorgente).
Sono sicuro che @Quantum scriverà un rapporto di bug in R. L'articolo aggiornato è stato rilasciato solo un paio d'ore fa.
Il codice del benchmark in MQL5 può essere trovato in \Scripts\UnitTests\Stat\TestStatBenchmark.mq5 e il codice in R può essere trovato alla fine dell'articolo Distribuzioni statistiche in MQL5 - prendere il meglio da R e renderlo più veloce in "Appendice. Risultati del calcolo del tempo per le funzioni statistiche".
Si assicuri di aggiornare a MetaTrader 5 build 1467 collegandosi al server MetaQuotes-Demo, per favore. È in questa versione beta che abbiamo incluso la nuova libreria e tutti gli script di test.
Non posso ancora formarmi un'opinione sul confronto delle prestazioni. E questa è una questione di principio.
Il fatto è che R è un ambiente ideale per lo sviluppo - un interprete in una parola. Ma il codice che esiste durante lo sviluppo è molto diverso dal codice funzionante - per il numero di linee molte volte. E il codice di lavoro, d'altra parte, è molto breve e molto capiente. Quindi dovremmo confrontare su qualsiasi funzione di pacchetti, che hanno senso quando si prendono decisioni di trading, per esempio, randomforest, che utilizzano algoritmi computazionalmente capienti, operazioni di matrice, caricamento di tutti i core....
PS.
State usando una versione non aggiornata di R. Dovresti prendere la versione R 3.3.1 (2016-06-21) da MRAN - Microsofn R Open website. È obbligatorio installare MKL quando si fa questo. Microsoft ha affermato nella citata versione di R che è stata in grado di aumentare la velocità di esecuzione di alcuni pacchetti e funzioni fino a 50 (!) volte.
Non posso ancora formarmi un'opinione sul confronto delle prestazioni. E questa è una questione di principio.
Il fatto è che R è un ambiente ideale per lo sviluppo - un interprete in una parola. Ma il codice che esiste durante lo sviluppo è molto diverso dal codice funzionante - per il numero di linee molte volte. E il codice di lavoro, d'altra parte, è molto breve e molto capiente. Ecco perché dovremmo confrontare tutte le funzioni dei pacchetti, che hanno senso mentre si prendono decisioni di trading, per esempio, randomforest, che utilizzano algoritmi computazionalmente capienti, operazioni matriciali, caricamento di tutti i core....
Traduciamo metodicamente le caratteristiche di R in MQL5. E in modo tale che l'essenza delle chiamate di funzione risulta essere molto simile.
Ecco un esempio della corrispondenza dell'articolo:
Uniforme
Cerchiamo di rendere il codice di R strettamente identico per dimensioni e tempo di scrittura a quello di MQL5.
Domani rilasceremo in beta la libreria grafica e dimostreremo pezzi di codice di uguali dimensioni in R e MQL5 insieme alle immagini.
Dubito che la versione stock di R possa improvvisamente accelerare - il codice non cambia molto. È chiaro che alcune funzioni possono essere accelerate, specialmente quelle matriciali. E la tua dichiarazione conferma la mia opinione che il codice in R è scritto in modo piuttosto sciatto in termini di prestazioni.
Se leggete l'articolo, vedrete che abbiamo ottenuto accelerazioni fino a 46x anche su funzioni di base senza alcun multi-threading e MKL:
I calcoli sono stati eseguiti su un Intel Core i7-4790, 3.6 Ghz CPU, 16 GB RAM, Windows 10 x64. Risultati del tempo di calcolo in microsecondi
Tempo di calcolo PDF (µs)
Tempo di calcolo PDF (µs)
R/MQL5
Tempo di calcolo del CDF (µs)
Tempo di calcolo del CDF (µs)
R/MQL5
tempo quantile (µs)
tempo di calcolo quantile (µs)
R/MQL5
tempo di generazione dei numeri casuali (µs)
tempo di generazione dei numeri casuali (μs)
R/MQL5
Ma la versione specificata sarà testata, naturalmente. Sia per la velocità che per le prestazioni.
Ti sbagli sulla "risposta sbagliata"
...
Per esempio, la documentazione MQL dà un esempio sull'arcsine e afferma che arcsine(2) = infinito. Questo non è esatto. Esattamente: arcsinus(2) = NaN, cioè nessun valore numerico, arcsinus(1) = Inf, ma le quotazioni mancanti durante il trading = NA, cioè dovrebbero essere (o potrebbero essere durante il weekend) e non lo sono.
L'ho scritto con un po' di ironia sulle risposte sbagliate. Avrei dovuto aggiungere una faccina sorridente... In realtà ho aggiunto alla fine che non è un bug in entrambi i casi, poiché il comportamento del compilatore e dell'interprete in aree di funzioni non difese dipende interamente dall'architettura del sistema e dagli sviluppatori. È meglio restituire nan in questo caso, ovviamente.
Voglio dire, non chiamare una funzione con parametri per i quali non è definita e poi confrontare i risultati con un'altra libreria, altrimenti si possono trovare centinaia di "bug".
A proposito, è interessante l'esempio con arcsinus.
mql -
MathArcsin(1) = MathArcsin(2) = -nan(ind)
Wolfram -
Arcsin(1) = Pi/2
Arcsin(2) = qualcosa di complesso. Non esiste una soluzione con un risultato valido.
R -
asin(1) = Pi/2
asin(2) = nan (la risposta è per i numeri reali)
asin(2+0i) = qualcosa di complesso, come in wolframio
wiki dice che asin(1) è ancora definito(https://en.wikipedia.org/wiki/Inverse_trigonometric_functions), puoi scrivere una segnalazione di bug a servicedesk.
Ma asin(2) è una regione indefinibile, va bene e corrisponde ovunque.
E di nuovo riguardo all'ultimo post - la divisione per 0 in matematica semplice è impossibile, quindi è logico che lo script mql si blocchi con un errore, nessun bug qui. Ma è molto strano vedere una tale meticolosità nel precisare i risultati fino a 16 cifre decimali, e restituire nan o Inf quando dividere per zero è impossibile per qualche motivo. Imho bisogno di tornare Inf e non tormentare gli sviluppatori con crash improvvisi dei loro script.
Per disabilitare il controllo della divisione dei valori reali, usate il parametro FpNoZeroCheckOnDivision=1 nella sezione [Experts] del file metaeditor.ini
Se questo parametro è presente, il seguente codice produrrà inf
Naturalmente, la presenza di questo parametro non vi salverà da un errore di compilazione quando si divide per una costante 0,0
'0.0' - division by zero in the constant expression s1.mq5 8 12
Renat, questo trasferimento di alcune funzioni da R a mql era davvero la sorpresa di cui parlavi?
No.
La sorpresa non ha senso, faremo tutto all'interno di MQL5 e MetaTrader 5.
Se questo parametro è presente, il seguente codice darà inf