Lega dei sistemi di trading. Continuate a fare un buon lavoro. - pagina 192

 
Eduard_D:

Perché non è permesso? Qual è esattamente la funzione che impedisce la chiusura di un trade con una perdita di 0,8 del range di un giorno, se succede che il TP trilling "raggiunge" il prezzo esattamente in quelle condizioni?

Mi sono espresso male.

Quello che volevo dire è che dopo una perdita di 0,8 giorni di intervallo - dopo 6 scambi ci dovrebbe essere un ritiro dal commercio perché stiamo aspettando troppo a lungo per un alto aggiornamento.

 
Roman Shiredchenko:

Duro per te... :-)

È possibile che lì, dopo le chiacchiere, sia possibile andare a Equity e su!!!?!!!!

Se inizia a scendere, sì. Anche se, ovviamente, tu lo sai bene... Continueremo a guardare...

Possibile.

Ma per due anni di fila non è successo. Stiamo aspettando un "volo verso l'alto"? È certamente possibile, ma la probabilità di un "flight out" è maggiore, secondo me.

 
Georgiy Merts:

Mi sono espresso male.

Quello che volevo dire è che dopo una perdita di 0,8 giorni di range - dopo 6 trade ci dovrebbe essere un ritiro dal commercio perché stiamo aspettando troppo a lungo per un alto aggiornamento.

Esattamente.

Considerate l'esempio 643642. Durante l'ottimizzazione non ha avuto alcuna perdita significativa (nessuna perdita superiore a 0,6).

Durante il trading, possono facilmente verificarsi perdite superiori a 0,6 (come si può vedere nel drawdown sui tick reali). Quindi, in caso di perdita superiore a 0,6 range si priva il TS di una possibilità di rivincita. E questo non è logico, che ancora una volta può essere visto nella corsa su zecche reali. Questa perdita non significa che il sistema ha smesso di guadagnare, semplicemente non è stato modellato su OHLC. Si scopre che non appena il TS fa una perdita significativa, sarà automaticamente rimosso dal commercio a causa del mancato rinnovo del massimo.

IMHO. Dovremmo in qualche modo dividere il calpestio di TC in un posto e il suo ripristino dopo una perdita. Per esempio, introducendo il criterio della redditività media di n-trade.

Non sei ancora d'accordo che il controllo dopo l'ottimizzazione con i tick reali può essere utile per capire gli aspetti latenti del comportamento del TS?

 
Eduard_D:

Esattamente.

Considerate l'esempio 643642. Durante l'ottimizzazione non ha avuto una sola perdita significativa (nessuna perdita superiore a 0,6 range).

Durante il trading, possono facilmente verificarsi perdite superiori a 0,6 (come si può vedere nella corsa sui tick reali). Quindi, in caso di perdita superiore a 0,6 range si priva il TS di una possibilità di rivincita. E non è logico, come ancora una volta può essere visto nella corsa su zecche reali. Questa perdita non significa che il sistema ha smesso di fare soldi, semplicemente non è stato modellato su OHLC. Si scopre che non appena il TS fa una perdita significativa, sarà automaticamente rimosso dal commercio a causa del mancato rinnovo del massimo.

Il sistema deve essere eliminato dal commercio perché non è modellato.

La ragione principale per rimuovere il sistema dal trading: il sistema non si comporta come si è comportato nella storia. Non importa perché è successo - potrebbe essere qualcosa che non abbiamo considerato durante i test, o il mercato è cambiato, o c'è un errore nell'algoritmo.

Se la perdita, che ha portato alla rimozione del sistema dal trading, è accidentale, il sistema sarà riottimizzato in un giorno, e i risultati della riottimizzazione saranno sicuramente migliori di quelli di un trade reale, e inizierà immediatamente a mostrare lo stesso risultato di prima. E la divisione non importa, lo script che raccoglie le statistiche per il rapporto - le raccoglie immediatamente per tutte le divisioni, ma, naturalmente, che nella parte superiore ottiene solo il TS dalla divisione superiore, perché non appena il TS della divisione media o inferiore inizia a mostrare la qualità del commercio nella divisione superiore - si trasferisce immediatamente ad essa.

Cioè, se questo TS è così costoso per te, Edward, allora il massimo che perdi è 10 offerte. Dato che è un "sei", ognuno dei suoi scambi è molto piccolo. Bene, cercherò di ricordarmi di avvisare gli interessati quando, dopo l'iperottimizzazione, il TS passa direttamente alla divisione superiore.

Attualmente ci sono 90 TC che commerciano nella Divisione Superiore.

 
Eduard_D:

IMHO. è necessario dividere in qualche modo lo stomping su un posto e il recupero dopo una perdita. Per esempio, introducendo un criterio di redditività media per n-trade.

Non è separato?

Guarda, passiamo due anni interi a testare come funziona il sistema. E ci prendiamo il periodo di recupero più lungo. Se il TS impiega più tempo a recuperare nel trading reale, è un chiaro segno che il TS non funziona come previsto (di nuovo, il motivo non è importante per noi).

 
Eduard_D:

Non sei ancora d'accordo che i test post-ottimizzazione su tick reali possono essere utili per capire gli aspetti nascosti del comportamento di TC?

Non ne vedo il motivo. Dopo tutto, quello che c'era non ci sarà mai più.

Tuttavia, nessuno vi impedisce di farlo da soli. Qualsiasi TC senza restrizioni funziona nel tester senza alcun codice.

 
Georgiy Merts:

Cosa dice il log di questo codice? Non è valido.

Ho controllato - tutto sembra funzionare...

Azzarderei l'ipotesi che non sia il regcode.

Eccomi qui.

ecco l'incidente.


c'è scritto codice di registrazione

Conto: 2599118
Magia: 542041

RegCode: 3265001878


 

mettere

con l'arrivo del tic, è sparito...



ecco il registro


 

Roman, sta imprecando contro il magik. 542041 ha una data di compilazione del 12.06.2019 Il tuo eseguibile ha una data di giugno. La mia ipotesi: quando questo eseguibile è stato creato non c'era ancora il 542041.

Prendi un modulo più recente, dovrebbe funzionare.

 
Georgiy Merts:

Non ne vedo il motivo. Dopo tutto, quello che c'era non ci sarà mai più.

Beh, allora che senso ha ottimizzare sulla storia?

Se fosse tecnicamente possibile (in termini di tempo), ottimizzerei tutto solo sui tick reali.