75.000 opzioni - 4GB di RAM e 4GB di cache del disco non sono sufficienti??? - pagina 6
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
.... Ma perché ci sono solo 1000 overshoots in uno spazio così grande? È molto approssimativo. Ho eseguito questo Expert Advisor in MT4 su un'area di 1,5 miliardi di valori e ha portato a 4400 rimbalzi netti in 4 minuti su una storia di 18000 barre EURUSD H1. ....
Dipende dalla qualità della funzione obiettivo (fitness).
- max NetProfit
- max NetProfit e min DD
- max NetProfit e max PF
- qualcos'altro?
Non ho visto una tale funzione di destinazione nel vostro codice. Ecco cosa abbiamo come parametri di ottimizzazione:Inoltre, usiamo l'algoritmo originale, che è un ordine di grandezza più veloce di altri algoritmi che conosciamo.
Dubito molto delle 100-200 corse. Quale popolazione viene utilizzata? 16? :) Quando si inizia con una grande area di ricerca si possono facilmente ottenere 256 overshoots nella prima generazione su 256 popolazioni sulla stima iniziale. Questa è la variante più sporca. È questo che intendi (eseguire la prima popolazione e fermarsi)? Credete ai risultati di 100-200 corse su un campo enorme di varianti? Chi ha bisogno di risultati così sporchi?1000 corse sono un po' troppe, di solito uso 100-200 corse (per qualsiasi numero di parametri) per valutare una soluzione.
Ecco cosa ho ottenuto quando ho eseguito il MACD Sample in 198 build sulle tue condizioni iniziali dalla prima pagina di questo thread:
Da un'area di ricerca di 35 miliardi di sovracampioni, 12800 corse sono state fatte in 8 minuti e 46 secondi su una storia di 18691 barre in modalità "per prezzo di apertura". Il rapporto sul caso migliore è allegato.
Inoltre, ci sono molte domande sui dati incoerenti (tutti dai vostri rapporti nel file ZIP). I profitti, il numero di scambi, ecc. non si avvicinano affatto ai dati del rapporto TSGO (file XLS fatto per la corsa 880, come indicato nell'ultima pagina del rapporto).
Inoltre, perché il TakeProfit è a 80 pip e il trailing stop a 6700?
Qual è la spiegazione di tutto questo? Sembra che il suo test sia così difettoso che non può essere preso in considerazione in alcun modo.
La prova/spiegazione dovrebbe essere semplice e facile da capire, non confusa al punto da dover fare domande come questa. Uno screenshot che non mostra nulla e un archivio con dati incoerenti è una prova per coloro che sono troppo pigri per capirlo.
Solo che potrebbe non essere chiaro al volo ...
Lasciatemi spiegare i risultati.
1. Il criterio di ottimizzazione può essere arbitrario.
(sulla funzione di destinazione)
È calcolato dall'utente stesso e passato a TSGO.
Cioè si possono usare sia quelli che si hanno che qualsiasi altro che un utente possa sognare.
Per esempio, si possono usare i payoff attesi come criterio.
(cioè, probabilità di accordi che hanno payoff attesi positivi, o in altre parole, il sistema funziona sul lato positivo)
. Oppure, alcuni criteri che descrivono la linearità del capitale (aiuta a risolvere problemi simili a Walk Forward Optimization) ...
Il criterio di ottimizzazione gioca un ruolo critico nell'ottimizzazione.
(per ottenere il giusto risultato, non CurveFitting)
2. L'ottimizzazione può essere fatta simultaneamente secondo molti criteri.
(sulla funzione di destinazione)
Ho solo un prototipo della prossima versione di TSGO a casa.
È possibile impostare più criteri di ottimizzazione contemporaneamente in esso (vedere la funzione TS.GO.Criterion(...)).
Nell'esempio nella tabella del visualizzatore i criteri utilizzati sono evidenziati con sfondo giallo - sono NetProfit, MaxDD, ProfitFactor.
Cioè TSGO ha cercato sistemi intorno al massimo di questi tre criteri (MaxDD in Omega è con un segno meno).
Cioè ha cercato sistemi con grande profitto, con grande ProfitFactor e minimo DrawDown.
Si possono ottenere risultati interessanti massimizzando simultaneamente il NetProfit per ogni anno (o mese),
cioè cercando sistemi con buoni risultati per ogni anno o anche mese sulla storia.
(in TSGO i criteri di ottimizzazione possono essere impostati fino a 1000, in realtà ho provato finora circa 150-200 - questo è NetProfit da mesi su MSFT)
3. La nostra popolazione arriva a 1000 copie (potremmo fare di più, ma sembra essere troppo).
(Dubito fortemente di 100-200 corse. Quindi che tipo di popolazione viene utilizzata? 16? :))
In quel particolare esempio, credo che fosse 100 (vedere il valore del parametro in TS.GO.Popul(...))
Di solito uso una popolazione di 50-100, a volte 1000.
In generale questo ha poco effetto, potete sempre impostarlo a 1000, non ha quasi nessun effetto sulla velocità di ricerca.
I risultati sono molto accurati, anche con 500 corse con una popolazione di 1000 ... :))
Vi ho detto che sto usando il mio algoritmo originale, di cui finora in internet non ho visto nulla.
È molto più veloce di tutti gli altri algoritmi che conosco (e probabilmente usato da voi).
La dimensione della popolazione in esso non ha importanza (purché non sia troppo piccola) ...
È questo che intendete (eseguire la prima popolazione e fermarsi)?
È quello che dici tu, per me funziona diversamente.
Credete ai risultati di 100-200 corse su un campo enorme di varianti?
Inoltre, sono abbastanza sicuro che i risultati di CS sono indipendenti dal numero di varianti nello spazio dei parametri.
Chi ha bisogno di risultati così sporchi?
Non sono disordinati, sono ragionevolmente sufficienti.
Non si ha mai la garanzia di ottenere risultati accurati in CS.
L'unico modo per ottenere un risultato accurato è quello di fare un overshoot completo.
Cioè, si ha sempre una stima - un risultato approssimativo.
Il mio algoritmo può ottenere una buona stima nella maggior parte dei casi già a partire da 100-200 corse.
Su un'area di ricerca di 35 miliardi di ricerche, sono state fatte 12800 corse
Nel mio algoritmo 2000 corse erano più che sufficienti.
Purtroppo i vostri rapporti non sono così semplici e indicativi come quelli di MetaTrader. Hai postato il file XLS di Omega con la popolazione numero 880, anche se non c'è nessuna descrizione dei parametri trovati di questa corsa 880 da nessuna parte (né nel rapporto XLS stesso, né nel rapporto TSGO, né negli screenshot di questo thread).
Cosa fare ...
Se Omega Research ha comprato il nostro TSGO e l'ha integrato nel loro pacchetto, allora sarebbe solo una casella di controllo come la vostra.
Ma per ora è solo un Add-On per TradeStation.
Tutto è corretto con i risultati.
La corsa 880 è la migliore secondo Omega (secondo il criterio NetProfit),
ma non la migliore secondo TSGO (simultaneamente secondo i criteri NetProfit, MaxDD, ProfitFactor)
TSGO usa Omega solo per l'organizzazione dei loop by pass.
Inoltre, è possibile selezionare qualsiasi criterio disponibile in Omega, e non influisce sul lavoro di TSGO.
TSGO esegue l'ottimizzazione in base ai criteri specificati dall'utente nel codice del segnale.
Anche il numero della corsa ottenuto in Omega non gioca alcun ruolo.
Quando l'ottimizzazione è completa, i risultati sono dati per l'istanza dalla prima riga del visualizzatore.
Inoltre, ci sono un sacco di problemi con i dati incoerenti (tutto questo viene dai vostri rapporti nel file ZIP). I profitti, il numero di transazioni, ecc. non si avvicinano affatto ai dati del rapporto TSGO (il file XLS è fatto per la corsa 880, che è indicata nell'ultima pagina del rapporto).
Sì, si può avere questa sensazione, hai fatto davvero un ottimo lavoro analizzando il mio esempio... :))
Qui è necessario fare un po' di chiarezza.
Il punto è che TSGO usa una caratteristica di Omega per segnalare il miglior sistema trovato.
Il sistema migliore è la prima linea del visualizzatore, sostituite i suoi parametri e vedrete una piena corrispondenza dei risultati con il rapporto.
Omega cerca il sistema secondo i suoi criteri (non ci interessa quale),
TSGO cerca il sistema secondo i suoi criteri, impostati nel segnale dall'utente.
Durante il processo di ottimizzazione, Omega cambia il parametro Gen da 1 a K (questo è il parametro di ottimizzazione impostato in Omega).
Il valore di Gen viene inviato a TSGO.
Se Gen aumenta, allora TSGO emette i parametri del nuovo candidato per verificare i risultati della corsa.
Se Gen non è aumentato, allora TSGO considera che l'ottimizzazione è finita (Omega ricalcola il miglior risultato a suo parere),
in questo caso TSGO emette i parametri dell'istanza migliore trovata (dalla prima riga del visualizzatore).
In generale, quando l'ottimizzazione è completa, il rapporto Omega mostra i risultati dell'istanza dalla prima riga del visualizzatore.
Confronta i loro parametri e sono esattamente gli stessi.
Tutto questo perché TSGO è un Add-On di Omega e non una parte di esso.
Non c'è altro modo per farlo.
============================================================================
Renat, ti assicuro che questi sono dati assolutamente reali, e tutto ciò che contiene è assolutamente corretto.
La confusione nasce perché non siamo gli sviluppatori di Omega e non possiamo costruire l'ottimizzatore dentro Omega.
Credete ai risultati di 100-200 corse su un campo enorme di varianti?
Non essere credente. Sarebbe così gentile da dimostrare il suo punto di vista su questo riconteggio:Inoltre, sono abbastanza sicuro che i risultati di CS non dipendono dal numero di varianti nello spazio dei parametri.
Tutto è corretto con i risultati.
Quindi:Run 880 è il migliore secondo Omega (secondo il criterio NetProfit),
ma non il migliore secondo TSGO (secondo i criteri NetProfit, MaxDD, ProfitFactor contemporaneamente)
- Non hai elencato i migliori parametri di esecuzione trovati 880
- Ci dici che "il nero è bianco", giustificandolo con le peculiarità del tuo addon
- Hai inviato un rapporto Omega consapevolmente errato
- Non hai indicato esattamente quale funzione target hai usato per ottenere i risultati di 1000 esecuzioni, e invece sei andato nel modo "si può fare questo o quello" (il programmatore può impostare il criterio nel codice stesso - mostra questo criterio nel tuo codice EL)
Non _confermarmi_. Meglio _provare_ su numeri e rapporti. Ci avete costretto a spostarci nel campo della risoluzione dei problemi a livello di "cavalli in un vuoto sferico" (grazie per questo), ci siamo spostati e abbiamo risolto il problema. Ma non l'avete risolto in alcun modo, e ci avete persino fuorviato con rapporti sbagliati.Tutto quello che hai citato prima come prova dall'inizio di questo thread è una totale assurdità con giochi di parole. Non c'è nessuna prova, solo un gioco di numeri stravaganti. Sarebbe così gentile da prendere IBM Daily dal 1970 al 1999 (esattamente dall'inizio del 1970 all'inizio del 1999) ed eseguire i limiti di cui sopra (esattamente i loro) e pubblicare un tale rapporto in modo che non ci sia alcuna pretesa. E io pubblicherò il mio.
E perché devo sempre trovare delle scuse qui?
Se volete che lasci il forum, per favore.
Banditemi anche qui e farò più lavoro e meno distrazioni.
Se non capite qualcosa, non significa che vi abbiano mentito.
Significa solo che non capisci, e nella società educata.
La gente chiede solo spiegazioni per le cose che non capisce.
La gente di solito giudica gli altri da se stessa.
Io non ho mai messo in dubbio l'onestà dei partecipanti al forum.
(A differenza di te...).
Risponderò in ordine.
1. In uno dei miei post ho scritto:
Inoltre usiamo l'algoritmo originale, che è un ordine di grandezza più veloce di altri algoritmi che conosciamo.
1000 corse sono un po' troppe, per stimare una soluzione di solito uso 100-200 corse (per qualsiasi numero di parametri).
Mi avete risposto:
Lei stesso crede nei risultati di 100-200 corse su un campo enorme di varianti?
Non avere fede. Sarebbe così gentile da provare le sue parole su questo ricalcolo:Inoltre, sono assolutamente sicuro che i risultati di CS non dipendono dal numero di varianti nello spazio dei parametri.
---
Cosa devo dimostrarle?
Che "di solito uso 100-200 corse (per qualsiasi numero di parametri)" ?
E considero tali risultati sufficientemente affidabili?
Questa è la mia opinione, e perché dovrei provarla?
Non crede? - Questo è un vostro diritto.
Puoi semplicemente dire: "Non credo".
Ci saranno due opinioni sullo stesso argomento.
2. Non avete dato una lista dei migliori parametri trovati per la corsa 880
La corsa 880 non è la migliore in termini di TSGO,
e potrebbe non essere più nella popolazione.
La corsa migliore è 919, che è mostrata nella prima riga del visualizzatore TSGO.
È quello che si vede nel rapporto Omega.
Confronta.
Nel visualizzatore, linea 1.
Gen = 919 (questo è il numero della corsa)
Scambi = 52
NetProfit = 29312.07
MaxDD = -4939.19
PF = 7,42
Nel rapporto di Omega
Profitto netto totale = 29.312,07 dollari
Numero totale di scambi = 52
Max drawdown intraday = ($4,939.19)
Fattore di profitto = 7,42
Perché Omega ha fatto la corsa numero 880, l'ho scritto in un messaggio precedente.
3. Mi avete inviato un falso rapporto da Omega.
Ho inviato un rapporto deliberatamente falso Omega, guarda più attentamente.
4. Non hai specificato esattamente quale funzione target hai usato per ottenere i risultati per 1000 esecuzioni
L'ho già scritto nel mio post precedente, l'ottimizzazione è stata eseguita simultaneamente usando tre criteri - NetProfit, MaxDD, ProfitFactor. Sono evidenziati nel visualizzatore con sfondo giallo.
Nel codice del segnale in Easy sono definiti dalla funzione TS.GO.Criterion
Ecco un frammento di codice:
R = TS.GO.Method(1); -- abilitare l'ottimizzazione multi-criteri.
R = TS.GO.Criterio("NetProfit",1); -- primo criterio
R = TS.GO.Criterio("MaxDD",1); -- secondo criterio
R = TS.GO.Criterio("PF",1); -- terzo criterio
I valori dei criteri sono assegnati alla fine del codice sull'ultima barra:
R = TS.GO.Set("NetProfit",NetProfit);
R = TS.GO.Set("MaxDD",MaxIDDrawDown);
R = TS.GO.Set("PF",GrossProfit/(0.001-GrossLoss));
Non ho nessuna voglia di ascoltare i vostri attacchi.
Se vogliamo parlare, dobbiamo essere su un piano di parità.
Sei d'accordo?
Allora, per favore, cercate di provare le vostre affermazioni.
1. Hai inviato un rapporto deliberatamente falso a Omega.
2. Non avete indicato esattamente quale funzione di destinazione avete usato per ottenere i vostri risultati.
3. E tu non l'hai risolto in nessun modo, e l'hai anche fuorviato con rapporti errati.
4. Tutto quello che avete dato prima come prova dall'inizio di questo thread è una totale assurdità con giochi di parole. (Questa non è solo un'affermazione - è già un insulto)
5. Non ci sono prove, solo un gioco di numeri stravaganti.
Continuo a suggerire di passare dal regno dei giochi di parole esclusivamente al regno delle relazioni pratiche. L'ultima volta ho suggerito di nuovo il problema da risolvere. Può risolverlo e pubblicare rapporti indiscutibili?
Dopo questo compito, possiamo passare senza problemi a un'affermazione sulla sufficienza di 100-200 corse su enormi campi di varianti.
C'è stato solo un malinteso con il numero della corsa Omega.
Nel prossimo post vi ho spiegato in dettaglio di cosa si tratta.
Circa la sufficienza di 100-200 corse su enormi campi di varianti.
Non ho fatto una dichiarazione o un'affermazione.
Ho scritto letteralmente quanto segue:
... Di solito uso 100-200 esecuzioni (per qualsiasi numero di parametri) per stimare una soluzione
Capite la differenza tra "stima" e "sufficienza"?
Questo è particolarmente interessante quando si tratta di rapporti e prove, come di solito chiedo - chiaro e semplice. Avete bisogno di rapporti informatici che abbiano al massimo una riga di commento d'autore ciascuno.
Sarei felice di spiegarlo in due parole, ma se non lo capite, devo scrivere post chilometrici...
Dopo questo incarico...
E lei mi ha assunto per darmi degli incarichi?
Continuo ad aspettare che tu dimostri le tue CONCLUSIONI.
Se state facendo delle affermazioni tecniche oltraggiose, siate così gentili da provarle.
Abbiamo già avuto a che fare con 100-200 corse e si è rivelato un risultato assolutamente sporco (anche se "stimato") (l'ho detto subito, ma non eri d'accordo). E ha dovuto ammetterlo solo sotto pressione.
Non faccio affermazioni tecniche stravaganti.
Per essere più precisi - per voi possono essere fuori portata, ma per me sono del tutto ordinari e funzionanti.
Abbiamo già avuto a che fare con 100-200 corse e si scopre che questi sono risultati assolutamente sporchi (anche se "stimati") (l'ho detto subito, ma non eri d'accordo). E questo doveva ammetterlo solo sotto pressione.
Non sono "assolutamente sporchi" ma risultati abbastanza fattibili.
E non ho accettato nulla sotto pressione.
Ho sempre detto la stessa cosa e posso ripeterla.
Soprattutto per te,
ho fatto un'altra ottimizzazione in Omega.
Ho lasciato solo un criterio di ottimizzazione - NetProfit- per facilitarvi il compito.
Lo stesso criterio è stato utilizzato in Omega.
C'erano 1000 corse in totale.
IBM, 7800 barre, al 1999/12/31
(Omega non ha data di inizio periodo, ha data di fine e numero di barre)
Test su barre giornaliere per Close bar (per Open Omega non lo fa)
Stops, toes e trailing nel codice fatto da ordini pendenti,
come Omega inside bar non funziona altrimenti e i dati hanno solo barre giornaliere.
Nell'allegato:
@Renat.txt - codice del segnale EL, differisce dal precedente in quanto è rimasto solo un criterio.
1000.XLS - Rapporto di sistema Omega (migliore esecuzione secondo Omega)
SOR.xls - Rapporto di prova Omega (tutte le esecuzioni)
TSGO-1000.CSV - composizione dell'ultima popolazione in TSGO (dimensione della popolazione 100).
Il blocco di definizione dei criteri è stato cambiato nel codice del segnale:
R = TS.GO.Method(1);
R = TS.GO.Criterion("NetProfit",1); -- secondo parametro = 1 - ricerca del criterio massimo
R = TS.GO.Criterion("MaxDD",0); -- secondo parametro = 0 - l'ottimizzazione per criterio è disabilitata
R = TS.GO.Criterion("NetProfit",1).GO.Criterion("PF",0); -- secondo parametro = 0 - l'ottimizzazione per criterio è disabilitata
Si prega di notare
1. La prima linea nel visualizzatore corrisponde alla prima linea nella popolazione e corrisponde ai risultati in Omega.
2. il numero della migliore corsa nel visualizzatore è 401, in Omega 948, se si guarda in SOR.xls si vedrà che queste corse hanno gli stessi risultati. TSGO rifiuta i risultati ripetuti di corrispondenza.
3. Se guardate la composizione dell'ultima popolazione, vedrete che il miglior risultato trovato ha NetProfit 1891.86 (su 401 corse), il risultato di 213 corse è 1814.16, il risultato di 93 corse è 1796.40. Cioè, il risultato della 93esima corsa era diverso dal miglior risultato dopo 1000 corse del 5,3%, che penso non sia male e può essere considerato come una buona stima di NetProfit.
Qui sotto c'è uno screenshot