Su un'applicazione dell'OOP - pagina 2
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
La cosa principale è come usarlo dopo. Per provare diversi input, potete farlo in blocco per numero di set di input. Cioè c'è una collezione di insiemi di input. Se conveniente, allora come array di funzioni. I più semplici - acquisto o vendita incondizionata in base al mercato. O condizionale)). E poi eseguiremo l'ottimizzatore e guarderemo attraverso i diversi set di voci.
Sì, sembra finora, abbiamo impostato il numero di strategia nelle impostazioni e ottimizzato per numero nell'ottimizzatore. Ma questa è la prima volta, è da molto tempo che sogno di fare l'auto-ottimizzazione al volo.
Qual è lo scopo di questa auto-ottimizzazione (funzione obiettivo)?
L'obiettivo è ovvio. In primo luogo, l'ottimizzatore nel tester manca il giorno corrente, almeno in MT4 di sicuro. E lo faccio per MT4.
In secondo luogo, il mercato può cambiare bruscamente durante la giornata, senza alcuna ragione (notizie). Probabilmente l'avrete notato, un piatto fiacco... Poi improvvisamente, come se la senape fosse stata sparsa sotto la coda, le citazioni cominciano a cadere. O si tratta di un'uscita a tavoletta, o di un caos totale.
Penso che possiamo classificare tali condizioni e includere la modifica richiesta della strategia nel definirle. Come fare? Non ho abbastanza fegato per creare una IA. Ma il metodo di ottimizzazione può determinare indirettamente lo stato.
Finora, questi sono solo pensieri non testati.
Sì, sembra così, nelle impostazioni abbiamo impostato il numero di strategie e ottimizzare per numeri nell'ottimizzatore. Ma questa è la prima volta, da molto tempo ho il sogno di fare auto-ottimizzazione al volo.
Il suo cliente vuole avvolgere tutte le strategie che conosce in un solo esperto, come ho capito. Non sarete in grado di finire questo compito finché non avrete una lista di strategie. Suggerisco di redigere insieme i ToR.
Se PLUS a questo elenco di strategie si tocca la questione dell'auto-ottimizzazione, allora scrivetegli una rete neurale, non reinventate la ruota e non sbalordite il vostro cliente con la conoscenza della programmazione di base. Questo è esattamente ciò che vi chiede.
E posso farvi un esempio di un "bashing"?
Ecco a voi. Gerarchia delle classi commerciali nella libreria standard:
Implica che il modulo di gestione del denaro è un Expert Advisor. Trailing Stop è anche un Expert Advisor. Expert Advisor include altri Expert Advisor. Questa eredità incoerente deriva dal fatto che sia il trailing stop che il money management hanno bisogno di accedere ad alcuni dati e metodi privati di un Expert Advisor di base.
A proposito, ci sono lunghe ghirlande di eredità. I CIndicatori usano CIndicatorBuffer che a sua volta chiama i suoi metodi superiori. Di conseguenza, un semplice tracciamento del valore dell'indicatore diventa un compito molto confuso. Dopo tre chiamate ricorsive, perdiamo completamente il senso della provenienza di qualcosa.
E questo è solo un esempio di cattiva eredità. Infatti, qualsiasi gerarchia più o meno grande di classi basata sull'ereditarietà diventa quasi sempre incoerente, confusa e ricorsiva. Il che rende estremamente difficile il debug e l'ulteriore sviluppo.
Pensiamo che la profondità dell'eredità dovrebbe essere limitata a 1-2 livelli. Inoltre, il primo livello dovrebbe ereditare dalla definizione globale e universale del CObject di livello zero (tutti sono oggetti) e implementare l'entità specifica "Expert", "Indicator", "Trailing Stop". Il secondo livello dovrebbe implementare l'implementazione specifica di "Expert Advisor basato su MACD", "indicatore SMA", "Trailing Stop", ecc. Ma l'uso del terzo livello deve essere severamente punito e perseguito.
In altre parole, si scopre che la classificazione è uno strumento veramente prezioso solo quando lo è:
Il suo cliente vuole avvolgere tutte le strategie che conosce in un solo esperto, come ho capito. Non sarete in grado di finire questo compito finché non avrete una lista di strategie. Suggerisco di redigere insieme i ToR.
Se PLUS a questo elenco di strategie si tocca la questione dell'auto-ottimizzazione, allora scrivigli una rete neurale, non reinventare la ruota e non sbalordire il tuo cliente con la conoscenza della programmazione di base. Questo è esattamente ciò che vi chiede.
Ecco a voi. Gerarchia delle classi commerciali nella libreria standard:
Implica che il modulo di gestione del denaro è un Expert Advisor. Il trailing stop è anche un Expert Advisor. Expert Advisor include altri Expert Advisor. Questa eredità incoerente deriva dal fatto che sia il trailing stop che il money management hanno bisogno di accedere ad alcuni dati e metodi privati di un Expert Advisor di base.
A proposito, ci sono lunghe ghirlande di eredità. I CIndicatori usano CIndicatorBuffer che a sua volta chiama i suoi metodi superiori. Di conseguenza, un semplice tracciamento del valore dell'indicatore diventa un compito molto confuso. Dopo tre chiamate ricorsive, perdiamo completamente il senso della provenienza di qualcosa.
E questo è solo un esempio di cattiva eredità. Infatti, qualsiasi gerarchia più o meno grande di classi basata sull'ereditarietà diventa quasi sempre incoerente, confusa e ricorsiva. Il che rende estremamente difficile il debug e l'ulteriore sviluppo.
Pensiamo che la profondità dell'eredità dovrebbe essere limitata a 1-2 livelli. Inoltre, il primo livello dovrebbe ereditare dalla definizione globale e universale del CObject di livello zero (tutti sono oggetti) e implementare l'entità specifica "Expert", "Indicator", "Trailing Stop". Il secondo livello dovrebbe implementare l'implementazione specifica di "Expert Advisor basato su MACD", "indicatore SMA", "Trailing Stop", ecc. Ma l'uso del terzo livello deve essere severamente punito e perseguito.
Ora capisco l'idea. A proposito, il modo semplice in cui ho implementato questo nei miei robot di trading come ho sottolineato. Solo i nomi sono diversi.
ZS: In che cosa ha fatto un tale grafico? Qualcosa alla Doxygen?
Ecco a voi. Gerarchia delle classi commerciali nella libreria standard:
Implica che il modulo di gestione del denaro è un Expert Advisor. Il trailing stop è anche un Expert Advisor. Expert Advisor include altri Expert Advisor. Questa eredità incoerente deriva dal fatto che sia il trailing stop che il money management hanno bisogno di accedere ad alcuni dati e metodi privati di un Expert Advisor di base.
A proposito, ci sono lunghe ghirlande di eredità. I CIndicatori usano CIndicatorBuffer che a sua volta chiama i suoi metodi superiori. Di conseguenza, un semplice tracciamento del valore dell'indicatore diventa un compito molto confuso. Dopo tre chiamate ricorsive, perdiamo completamente il senso della provenienza di qualcosa.
E questo è solo un esempio di cattiva eredità. Infatti, qualsiasi gerarchia più o meno grande di classi basata sull'ereditarietà diventa quasi sempre incoerente, confusa e ricorsiva. Il che rende estremamente difficile il debug e l'ulteriore sviluppo.
Pensiamo che la profondità dell'eredità dovrebbe essere limitata a 1-2 livelli. Inoltre, il primo livello dovrebbe ereditare dalla definizione globale e universale del CObject di livello zero (tutti sono oggetti) e implementare l'entità specifica "Expert", "Indicator", "Trailing Stop". Il secondo livello dovrebbe implementare l'implementazione specifica di "Expert Advisor basato su MACD", "indicatore SMA", "Trailing Stop", ecc. Ma l'uso del terzo livello deve essere severamente punito e perseguito.
In altre parole, si scopre che la classificazione è uno strumento veramente prezioso solo quando lo è:
+ pensieri molto veri.
ZS: In cosa è stato redatto un tale grafico? Qualcosa alla Doxygen?
Sì, se solo ;) Ci ho lavorato sopra in SnagIt per circa un'ora. L'ho fatto appositamente per il mio articolo.