Cosa si dovrebbe aggiungere per un ulteriore supporto dei calcoli matematici universali in MQL5 e MQL5 Cloud Network? - 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
È un po' diverso. Quello che volevo fare era controllare il corso dell'ottimizzazione.
Più o meno vuoi la tua genetica?
In origine, sì, è stata chiesta la genetica.
E lo userei solo per l'auto-ottimizzazione (selezionando le aree dei parametri in base ai risultati precedenti).
E userei solo per l'auto-ottimizzazione (selezionare le aree dei parametri in base ai risultati precedenti).
Grosso modo vuoi la tua genetica?
In questa direzione, ma non è tutto così unilaterale.
Prima di tutto, se il GA standard fosse soddisfatto di tutto (~10K parametri completi, ottimizzazione multiparametro) allora la maggior parte degli insoddisfatti sarebbe messa a tacere.
Ma c'è un altro inconveniente, a volte si vuole fermare l'ottimizzazione per una sorta di istinto, e continuare oltre. Quelli per fare correzioni manuali al FF automatico.
Se anche questo, anche una piccola parte di utenti esigenti chiuderà finalmente il problema con GA.
E non lasciate che gli sviluppatori siano imbarazzati da un piccolo numero di utenti insoddisfatti, di solito sono quelli più avanzati ed è a loro che bisogna guardare.
ZZY Ma in realtà hai ragione, la sua genetica più vicino al corpo, e correre in cludes sarebbe cool. A proposito, allora sarebbe possibile risolvere il problema con i test valk-forward da soli e non dover elemosinare questa modalità da MQ.
E non lasciare che gli sviluppatori siano imbarazzati dal fatto che ci sono poche persone insoddisfatte, di solito quelle più avanzate.
Infatti, questo fattore è il più importante nel processo di rifiuto.
In sostanza, dovranno essere distratti da un compito che sarà utilizzato da una cerchia ristretta di persone avanzate.
In effetti, questo è il fattore più importante nei rifiuti.
In sostanza, dovranno essere distratti da un compito che sarà utilizzato da una ristretta cerchia di utenti avanzati.
Questo è il punto, un utente avanzato vede più di un novizio, col tempo la sua visione dei problemi si diffonderà agli altri e anche loro vorranno usare le funzionalità che l'utente avanzato vuole già usare.
Se ci si concentra sul mainstream, la piattaforma sarà sempre un po' nel passato.
Prima che Kodak creasse una soapbox e una rete di macchine sviluppatrici, i turisti non avevano alcun desiderio di scattare foto da soli, era la prerogativa degli utenti avanzati e dei professionisti della fotografia (di cui ce n'erano molti in ogni attrazione turistica).
Ma un innovatore è arrivato e ha creato un nuovo servizio, capovolgendo così l'industria e promuovendola alle masse.
Questo è il punto, l'utente avanzato vede più dell'utente inesperto, col tempo la sua visione dei problemi si diffonderà agli altri e anche loro vorranno usare le funzionalità che l'utente avanzato vuole già usare.
Se ci si concentra sul mainstream, la piattaforma sarà sempre un po' nel passato.
La cosa principale è che prima che Kodak creasse la soapbox e la sua rete di macchine sviluppatrici, i turisti non avevano alcun desiderio di fare le proprie foto - era la prerogativa degli utenti avanzati e dei professionisti della fotografia (di cui ce n'erano molti in ogni attrazione turistica).
Ma un innovatore è arrivato e ha creato un nuovo servizio, capovolgendo così l'industria e promuovendola alle masse.
Sono d'accordo. Con entrambi. :)))
L'interfaccia deve essere pensata. Cos'è la genetica personalizzata? Se l'interfaccia con la claude da fare a livello di "SetPopullationForCalc(); GetPopulationFitnessFuncs();" allora uno schema flessibile e potente non funzionerà.Sarebbe meglio implementare lo scambio con claud a livello di pacchetti di lavoro a volume casuale in cui la dimensione della popolazione non è fissa e viene passata come parametro insieme all'array di parametri. Inoltre dobbiamo staccare completamente (finalmente!) "ottimizzazione" e "test", con dare (in parallelo arbitrario!) possibilità di alternare e combinare le richieste di (1) massa di calcolo di folla leggera (analogo di ottimizzazione) di array di set di parametri con (2) corse singole dettagliate (analogo di "test"). Poi, la massa in avanti sono costruiti senza problemi, e tutti i tipi di altri caca e tè, che non è nemmeno sulla nostra mente ancora.
Questi sono i pensieri.
La conclusione è la seguente: pensate a uno strato api flessibile tra il tester e i programmi nel terminale di trading. Questo risolverà l'antico problema di "ottimizzazione genetica nel corso del trading con correzione al volo dei parametri del robot" insieme ad altri problemi.In particolare, il Cloud diventerà un mega-computer di massa super-universale, capace di risolvere compiti arbitrari con grandi volumi di calcoli di tipo singolo.
Per una buona auto-ottimizzazione, il tester dovrebbe essere buttato fuori dalla catena.
Non sto parlando dell'auto-ottimizzazione dell'EA in fase di esecuzione, ma, per esempio, di wolf-forward per conto proprio.
La selezione di intervalli di parametri per le esecuzioni future risolverebbe questo problema al 100% (le date possono essere limitate programmaticamente usando gli stessi parametri).
Ma questo, dato l'uso di cludes, non è così diretto e inequivocabile come sembra.
Non sto parlando dell'auto-ottimizzazionedell'EA mentre è in esecuzione, ma, per esempio, dell'inoltro del lupo da solo.
Um, è lo stesso dal mio punto di vista :)
Prima di tutto, se il GA standard fosse soddisfacente in tutto (~10K parametri completi, ottimizzazione multiparametro) allora la maggior parte degli insoddisfatti sarebbe messa a tacere.
Sì, la maggior parte dei 5-10 insoddisfatti :)