Lega dei sistemi di trading. Continuate a fare un buon lavoro. - pagina 66
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
Ehm... Come può essere "non sfruttare schemi reali" se la Lega usa esclusivamente schemi conosciuti?
Il preferito del passato è ChnTrendSP - una rottura di canale con stop fissi - non è un pattern?
L'attuale favorito dalla bilancia - EMAFlatSP - entrata nella controtendenza, determinata dall'incrocio del prezzo e dell'EMA con stop fissi - non è anche questo un pattern?
Quale pensi sia il "vero schema"?
Hai scritto tu stesso che era una cosa ed è diventata un'altra, e finché non capisci che hai bisogno di cambiare un sistema per un altro, rimarrai con "0" profitti, e sta girando di nuovo in tondo.
...è regolato nell'ottimizzatore. In questo caso la quantità non conta in nessuna combinazione, la spazzatura dentro è spazzatura fuori. Questo segue da una logica banale, non c'è nemmeno bisogno di essere sensitivi qui.
L'ottimizzazione è comunque tutta una questione di adattamento. Ma, secondo me, nella Lega - è molto meno di quello della maggior parte degli esperti di KodoBase.
Diciamo che in un sistema a canali capovolti - ho solo un parametro di trim - il periodo del canale.
Inoltre - la mia ottimizzazione è "multistrato". Significa che se ci sono molti parametri (per esempio, se impostiamo anche il Breakeven), prima tutto viene ottimizzato senza Breakeven - cioè il sistema funziona anche senza Breakeven. E solo dopo selezioniamo i parametri di pareggio, che migliorano ulteriormente il sistema.
Se questo è "trash" - è difficile per me dire cosa è "non-trash".
Non ci sono gradini, quindi non si vede! Finora, qualunque cosa io provi, non ci riesco. Allora che senso ha aprire i segnali e mostrare qualcosa, se non c'è niente da mostrare?
"Perché non nel tester" - risposi, il test viene fatto automaticamente, usando gli script, i parametri trovati vengono immediatamente "segnati" nella Lega, e inoltre - tutti i dati del test vengono cancellati. Al momento della sovraottimizzazione - posso "intercettare" i rapporti di prova - due pezzi di quei maghi che hanno richiesto la sovraottimizzazione - ho postato. Tutti quelli precedenti sono spariti. Oggi, a proposito, un mucchio di sistemi sono morti - domani lo script inizierà a riottimizzarli, posso postare i rapporti dei tester per loro.
Non è la risposta alla mia domanda.
Ho bisogno di un algoritmo per selezionare i sistemi per lavorare nel tester. E per metterlo alla prova. Non c'è affatto bisogno di demo, una perdita di tempo.
L'ottimizzazione è tutta una questione di adattamento in ogni caso. Ma, a mio parere, nella Lega - è molto meno che nella maggior parte degli esperti di KodoBase.
Diciamo che in un sistema a canali capovolti - ho solo un parametro di trim - il periodo del canale.
Inoltre - la mia ottimizzazione è "multistrato". Significa che se ci sono molti parametri (diciamo, se impostiamo anche il Breakeven), prima tutto viene ottimizzato senza Breakeven - cioè il sistema funziona anche senza Breakeven. E solo dopo selezioniamo le impostazioni di breakeven che migliorano ulteriormente il sistema.
Se è "spazzatura" è difficile per me dire cosa è "non spazzatura".
L'ottimizzazione è quando c'è un modello fondamentale, ma i parametri del TS devono essere migliorati per farlo funzionare meglio. E quando il TS stesso inizia a funzionare solo dopo l'ottimizzazione, e prima non funzionava, è una cattiva ottimizzazione.
Approssimativamente, non è spazzatura se non lo si accorda e funzionerà ancora, ma lo si può accordare facoltativamente. E tali sistemi sono molto pochi in natura, quindi la domanda ragionevole è se è necessario trasportare tutto il resto della spazzatura e aspettare che spari.
...
Se è "spazzatura" - è difficile per me dire cosa è "non spazzatura".
George, pensiamo in modo logico.
Cercherò di essere costruttivo. Tecnicamente, però, è difficile.
All'inizio volevo consigliarvi di pensare alle strategie utilizzate, ma poi mi sono reso conto che l'essenza dell'esperimento della Lega è il contrario.
Vale a dire:
Lo scopo principale dell'esperimento: Trova un algoritmo per selezionare i sistemi per ogni periodo della dinamica del mercato.
Nel farlo, c'è una condizione: i sistemi possono essere quello che volete. Non c'è bisogno di pensare molto all'essenza. Il criterio principale - il profitto nel tester.
Questo esperimento è certamente interessante, anche se i suoi risultati non coincidono con i desideri di George. Vorrebbe trovare un algoritmo per selezionare sistemi casuali in dinamiche casuali, ma l'algoritmo non si trova...
Perché quell'algoritmo è il Graal...
Il risultato reale dimostra che il sistema stesso, e i metodi della sua applicazione, devono essere significativi.
Suggerirei a George di creare un unico robot significativo, con la capacità di adattarsi alle dinamiche attuali del mercato. Ma l'adattamento, non attraverso l'ottimizzazione, e non attraverso il MO, ma attraverso una valutazione significativa di ciò che sta accad endo. (Il compito è più vicino alla creazione di un'IA).
Questa non è la risposta alla mia domanda.
Avete bisogno di un algoritmo di selezione del sistema per lavorare nel tester. E per metterlo alla prova. Non c'è affatto bisogno di demo, una perdita di tempo.
Lo faccio. Ma il fiore di pietra non esce...
È chiaro da qui, e la Lega può benissimo selezionare il miglior TS proprio nel tester (o con l'aiuto di script e del tester). Ma, prima di tutto, prima di stipare l'algoritmo di selezione nel tester - dovrebbe essere inventato! Cioè, almeno per qualcosa da "prendere". Possiamo selezionare i migliori in modo che nel tester potremmo vedere se abbiamo selezionato i sistemi con l'aiuto di questo algoritmo e poi se funzionano stabilmente. Noi non ce l'abbiamo!
Quando preparerò la Lega per i progetti condivisi, inizierò di nuovo degli esperimenti con questo algoritmo di selezione.
E su "non abbiamo bisogno di una demo" - non sono d'accordo. Abbiamo bisogno della demo per vedere quanto è stabile il sistema. Per assicurarsi che il sistema abbia funzionato nel tester e continui a funzionare.
L'ottimizzazione è quando c'è già un modello fondamentale, ma i parametri del TS devono essere regolati per farlo funzionare meglio. E quando il TS stesso inizia a funzionare solo dopo l'ottimizzazione, e prima non funzionava, questa è una cattiva ottimizzazione.
Approssimativamente, non è spazzatura se non lo si accorda e funzionerà ancora, ma lo si può accordare facoltativamente. E tali sistemi sono molto pochi in natura, quindi la domanda ragionevole è se è necessario trasportare tutto il resto della spazzatura e aspettare che spari.
Beh, sono completamente d'accordo con la prima affermazione. Questo è quello che faccio.
La questione discutibile è se sia necessario o meno portare in giro la spazzatura. Approssimativamente - c'è bisogno di una Middle, o ancora di più di una Lower Division. Sì, non c'è modo di saperlo, cazzo. È chiaro che per l'uso e il miglioramento - solo i TC di divisione superiore, con qualità del commercio non inferiore a 80% sono considerati, e tutto ciò che è peggio - è più "zavorra".
Non occupa il mio tempo - solo il tempo della CPU. Ogni mattina eseguo semplicemente uno script che genera una lista di sistemi che hanno bisogno di essere riottimizzati, e poi - li riottimizza. Dopo di che devo solo ricompilare EX-module e aggiornarlo su UPU. Non fa assolutamente differenza se c'è solo una divisione superiore o tutte e tre - ci vuole circa la stessa quantità di sforzo corporeo da parte mia. Quindi, finora tutti i 672 TC funzionano sulla demo. Se la complessità del supporto - allora questo problema sarebbe un problema, e, naturalmente, non mi preoccuperei di "cestinare i TC".
Ehm... Come può essere "non sfruttare schemi reali" se la Lega usa esclusivamente schemi conosciuti?
Il preferito del passato è ChnTrendSP - una rottura di canale con stop fissi - non è un pattern?
L'attuale favorito dalla bilancia - EMAFlatSP - entrata nella controtendenza, determinata dall'incrocio del prezzo e dell'EMA con stop fissi - non è un pattern?
Quale pensi sia il "vero schema"?
George, ciao. Lei ha criticato molto le mie idee, ma leggendo il suo thread vedo che le sue idee sono altrettanto criticate. A quanto pare, questa è la tradizione del forum.
Lasciatemi esprimere la mia opinione sull'essenza della Lega.
Purtroppo l'idea della Lega, in questa forma, è un involontario discredito del trading. Il tuo approccio priva l'essenza del trading. Perché?
Perché:
In una parola, tu stesso crei spazzatura, poi crei un'illusione del suo (possibile) valore attraverso l'ottimizzazione, e poi la butti via, essendo convinto ogni volta che è RIFIUTO.
Si finisce per screditare involontariamente il trading, convincendo tutti dell'inutilità di cercare di creare sistemi di trading.
Mi rendo conto che lo stai facendo involontariamente, ma nel tuo subconscio funziona così.
1. Non sono d'accordo. Tutte le TS della Lega sono tecniche abbastanza conosciute e ampiamente utilizzate. Simboli diversi funzionano per l'uno o per l'altro. Qui sarei piuttosto d'accordo con Maxim che "solo l'Alta Divisione è necessaria, il resto è spazzatura". In Alta Divisione funzionano i sistemi che corrispondono al comportamento dei simboli. E quelli che non lo fanno - vanno alla Divisione Media e Bassa.
È solo che ho notato più di una volta che lo stesso sistema funziona con successo nella High Division per un po', e poi all'improvviso smette di funzionare. L'esempio brillante che ho già menzionato - rottura del canale su GBPUSD - il sistema ha funzionato molto bene per tutto il semestre. E poi - bang... e qualcosa è cambiato, ora non può nemmeno entrare nei primi posti. Qui, le divisioni Media e Bassa sono interessanti per me proprio per guardare gli "ex favoriti".
2. La qualità non si ottiene affatto con l'ottimizzazione. Ancora una volta sono d'accordo con Maxim su questo punto - il sistema dovrebbe già mostrare almeno alcuni risultati senza alcuna ottimizzazione, e l'ottimizzazione lo migliora solo. La qualità si ottiene proprio attraverso quelle "trappole di modelli". Per ogni simbolo, eseguo TUTTE le varianti. Per vedere quale funziona. E bisogna continuare a usarlo, migliorarlo e renderlo ancora migliore.
3. Tutto è giusto. Ma se il sistema non è conforme al comportamento del simbolo, non lo sarà, non importa quanto lo si ottimizzi. Qui sto citando le parole di Maxim per la terza volta - il primo dei rapporti postati era spazzatura. Cioè, anche la migliore variante del sistema è un commercio abbastanza schifoso. L'essenza di un tale sistema è solo vedere quali tecniche NON funzionano.