Un po' sorpreso :) Ho pensato di condividere e fare una domanda NON retorica. - pagina 14
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
L'ottimizzatore non è esattamente un "tester a scala lineare", ma ha i propri metodi di ottimizzazione che lavorano efficacemente su calcoli ripetuti su larga scala.
Ora siamo impegnati ad accelerare i calcoli di massa. Ecco un link ai risultati passati, e una nuova versione con calcoli più veloci è pronta.
Sono d'accordo, non esattamente un "tester a scala lineare". Voi fate ottimizzazioni esplicite, il che è una cosa molto buona. Tuttavia, non riesco a immaginare come si potrebbe ottimizzare per un caso univariato una situazione molto frequente:
L'ottimizzazione va per due parametri, un parametro (gamma di 100 valori) non tocca le chiamate dell'indicatore, il secondo (gamma di 5 valori) sì.
In questo caso calcolerete i valori dell'indicatore 500 volte cercando 500 varianti. In questo caso, si esegue effettivamente un numero enorme di ricalcoli. Questo perché l'intervallo della seconda variabile è solo 5, non 500.
Questo è solo l'esempio più semplice. Forse avete già qualche idea su come aggirare questa scalabilità lineare del tester per l'ottimizzatore.
P.S. Sono esempi come questi che vi danno un vantaggio di velocità nei vostri calcolatori di ordini di grandezza, non di percentuale. Ma queste calcolatrici non sono universali, quindi il paragone è errato fin dall'inizio.
Ok - diciamo che c'è un ottimizzatore senza cloud computing, ma multi-threaded, e che supporta C++ e MT4 (e tutto il suo sottosistema) ed è 100 volte più veloce di esso, e 6 volte più veloce puramente dal codice MT5, sì... e "risolve" non solo con forza bruta e GA, ma anche con circa 50 altre varianti. A quanto lo compreresti? Lo comprereste per 1000 dollari? Perché così caro? Tu e altre dieci persone sarete gli unici acquirenti. :)
Tuttavia, non riesco a immaginare come si potrebbe ottimizzare per un caso univariato una situazione molto frequente:
Posso già immaginare qualcosa (ma non completamente). Prima di eseguire l'ottimizzatore, dovreste eseguire un'analisi di dipendenza sui parametri di input da ottimizzare (nell'esempio precedente, due variabili sono completamente indipendenti). Successivamente, l'ottimizzazione viene eseguita prima attraverso le variabili indipendenti dalla gamma più piccola alla più grande (non sempre corretta, poiché dipende anche dall'intensità delle risorse degli stessi indicatori. A volte è meglio contare l'indicatore leggero 100 volte, che 5 volte quello pesante), memorizzando i risultati.
È chiaro che l'implementazione di tale ottimizzazione è molto complessa (soprattutto per il caso del cloud). Ma se implementato, allora almeno assolutamente tutti gli Expert Advisors creati in MQL5 Wizard saranno ottimizzati ordini di grandezza più velocemente. Perché il Wizard MQL5 è una combinazione di un gran numero di indicatori tra loro (cioè c'è un enorme numero di parametri di input indipendenti l'uno dall'altro). Un'altra cosa è che una tale attività non ha senso per un trading redditizio...
Il caching seguito dal campionamento dei risultati su campioni enormi (milioni e decine di milioni) è più costoso del calcolo diretto.
Il caching con il successivo campionamento dei risultati su campioni enormi (milioni e decine di milioni) è più costoso del calcolo diretto.
Sono sicuro che è quasi irrealistico implementare un perfetto ottimizzatore universale in modo che sia "intelligente" come ho descritto sopra. Certo, c'è spazio per migliorare, ma non c'è modo di renderlo perfetto in ogni caso.
Campioni enormi (decine di milioni), ovviamente, si esagera notevolmente. Non c'è affatto bisogno di mettere in cache queste cose.
Credo che tutti voi capiate perfettamente quello che voglio dire. E molti lo fanno. Nessuno vi criticherà nemmeno per questo, altrimenti sarebbe l'ignoranza del programmatore della critica. Perché coloro che sono adeguati sono ben consapevoli della difficoltà di realizzare queste cose.
Lasciatemi spiegare l'idea del caching usando lo stesso esempio:
Se l'indicatore non viene ridisegnato, allora alla fine di una singola esecuzione nel tester avrete un buffer completo di tutti i valori dell'indicatore. Ce l'hai già. E, se il prossimo passaggio usa gli stessi valori dell'indicatore (la seconda variabile non è cambiata), non dobbiamo leggerlo di nuovo. Potete prendere i valori dal buffer già calcolato (che avete già, non c'è bisogno di cache, la memoria della corsa precedente non è completamente libera).
Se l'indicatore non viene ridisegnato, allora
Sono sicuro che è quasi irrealistico implementare un perfetto ottimizzatore universale in modo che sia "intelligente" come ho descritto sopra. Certo, c'è molto margine di miglioramento, ma non si può comunque fare tutto alla perfezione.
Campioni enormi (decine di milioni), naturalmente, si esagera notevolmente. Non c'è affatto bisogno di mettere in cache queste cose.
Per esempio, il test EURUSD degli ultimi 11 anni dà più di 50 milioni di tick.
Significa che un semplice indicatore a un buffer come MA dovrà memorizzare 50 milioni di stati (50 milioni * 8 byte (doppio) = 400 mb di buffer), che è troppo. Se si usa qualcosa di più complesso o più grande in numero, in effetti la cache non si adatta alla memoria, figuriamoci gli agenti multi-core.
Stavamo lavorando sull'idea delle cache degli indicatori e si è scoperto che è molto più veloce e meno dispendioso in termini di risorse calcolare il prossimo valore dell'indicatore (e anche con un metodo economico) che costruire le cache.
Sì, proprio perché è impossibile scrivere un ottimizzatore universale così veloce, le smerigliatrici numeriche non universali vinceranno sempre in termini di velocità. E non c'è niente di buono o cattivo in questo.
Non vincono nulla.
Non hanno un ambiente di mercato, nessuna infrastruttura, nessun indicatore, nessuna analisi. E questo è più importante di un ciclo una tantum (e nemmeno rappresentato).
Per esempio, il test EURUSD negli ultimi 11 anni dà più di 50 milioni di tick.
Stiamo parlando di un ottimizzatore, non di tante corse di un singolo tester. Il concetto di ottimizzatore è abbastanza diverso. Lì si ottengono significativi guadagni di velocità a scapito di piccoli errori nei risultati. L'ottimizzatore non ha affatto bisogno di modelli basati sui tick. Al massimo, si basano sui prezzi di apertura. Un ottimizzatore non è un tester, è tutta un'altra cosa. Il tuo approccio è diverso, e anche abbastanza logico.
Non stanno vincendo nulla.
Non hanno un ambiente di mercato, nessuna infrastruttura, nessun indicatore, nessuna analisi. E questo è più importante di un ciclo unico (e nemmeno rappresentato).
Vincono in velocità, perché niente può essere più veloce del solo ciclo for. A volte la velocità è esattamente ciò di cui avete bisogno, e una calcolatrice batterà qualsiasi tester universale in velocità (ma non in altri parametri). Non solo da MetaQuotes.
Non posso provare la mia affermazione per la seguente ragione:
La mia calcolatrice è semplicemente un'implementazione C++ del mio EA, dove tutte le operazioni sono specificamente rese intere (i prezzi sono interi), dove i passaggi inutili ecc. sono ridotti completamente a zero. Non c'è nessuna interfaccia, niente. L'unico output è un file con i risultati dell'ottimizzazione. Cioè posso scrivere un EA con ottimizzazione algoritmica in C++ e il mio tester non farà nessun controllo di trading (per esempio, controllare se c'è abbastanza margine, ecc.). Non emulerà la storia e non conterà gli indicatori. Non c'è nulla di universale in termini di versatilità dei tester MT5. L'unico compito della calcolatrice è quello di calcolare velocemente, il più velocemente possibile. E conta cento volte più velocemente del tester MT4, producendo un errore di <1%. Non capisco cosa sto cercando di dimostrare qui.
È ovvio che il ciclo for senza controlli e con solo interi sarà sempre più veloce di un tester universale.