![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Ottimizzare per campi di bit, non ci saranno passaggi inutili in questa variante.
Per esempio:
e ottimizzare in determinati parametri, per questo esempio bp è ottimizzato da 0 a 3
Solo tu hai dimenticato di scrivere il verdetto se puoi o non puoi.
Come può essere "più facile"? :) Le condizioni per cancellare un EA o per REASON_INITFAILED devono ancora essere tracciate. Questo è quello che sembra una seccatura.
Si scopre che, in linea di principio, un set di parametri funzionante produce zero risultati e non è coinvolto in un'ulteriore selezione.
In assenza di una soluzione elegante, si può usare prima quella più "facile". Se si trova qualcosa di meglio, può sempre essere sostituito. :)
Non proprio, se stai parlando della mia idea tortuosa. Con "set di parametri funzionante" e primo trpar2=falso il passaggio darà un risultato abbastanza funzionante. Tutti gli altri passaggi con lo stesso "set di parametri di lavoro" e trpar2=false porteranno immediatamente a degli zeri, ma il vostro "set di parametri di lavoro" parteciperà comunque alla selezione. Questo è quello che volevi, vero?
Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere
if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute. Per quante coppie ci sono se, non sembra così brutto. Grazie.
Ancora una volta: la seccatura non riguarda quale comando per terminare il passaggio in anticipo - questa è una soluzione piuttosto primitiva, qualunque essa sia. La seccatura sta nel tenere traccia delle condizioni per completare il passaggio in anticipo. Il fatto che il passaggio sarà completato in anticipo con l'aiuto del tuo suggerimento, "l'unità di tracciamento" in sé non è meno fastidioso e l'eleganza di questa unità non è aumentata in alcun modo.
Cosa intendeva dire con questo? Che in assenza di una soluzione elegante, non si dovrebbe usarne affatto? Anche se ce n'è uno, ma, come dice lei, "doloroso"?
In breve, andiamo avanti. Altrimenti è più fastidioso dall'allagamento che dal codice. :)
Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere
if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute.
Si può correggere un po'. I parametri di ottimizzazione dovrebbero essere scritti in strutture, e queste (strutture semplici) dovrebbero essere trattate come variabili. Il codice dovrebbe leggere
if(!trpar && Par1==Parold1 && Par2==Parold2) { Parold1=Par; Parold2=Par2 ; return(9) } Qui Par e Parold sono strutture in cui vengono scritti i parametri ottimali di altre coppie di valute. Per quante coppie ci sono se, non sembra così brutto. Grazie.
C'è un'altra variante (mi è sfuggita).
Potete dare un'occhiata alle funzioni: OnTesterInit(), OnTesterPass(), OnTesterDeinit().
E FrameFirst (),FrameFilter (),FrameNext (),FrameInputs (),FrameAdd().
È esattamente a questo che servono. :)
Cioè, potete sempre richiedere tutti i parametri di qualsiasi passaggio nell'ottimizzazione corrente in qualsiasi momento.