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
Ho notato di nuovo anche quando lo eseguo dal 2009 alla data attuale (04.2014) la differenza tra la MA sul grafico e ima in backtest è ancora 0.10, quindi credo che il problema persista. Farò la mia funzione di sostituzione di iMa se tutte le altre sono fallite. icustom restituisce ancora solo zeri sul grafico D1 anche quando si parte dal 2009 e funziona bene sul grafico H4.
Analizzando come funziona l'indicatore dimedia mobile personalizzato capisco perché ci sono problemi del genere.
Ogni media mobile viene conteggiata in modo non crudo contando il prossimo frame della media mobile dal precedente frame della media mobile invece di contare solo i frame necessari (in questo caso 370) per l'equazione. In questo modo, se 1 fotogramma della media mobile non è corretto, lo saranno anche tutti quelli successivi. Più lontano dall'error-frame più piccolo sarà l'errore. Potrebbe anche funzionare correttamente se tutti i fotogrammi dall'inizio fossero contati correttamente, ma ho notato che a volte l'iMA all'inizio riporta degli zeri (ho una procedura per scartare le letture errate della ma, ma l'iMA stessa non lo fa) e questi zeri sono probabilmente presi in considerazione anche quando si contano i prossimi fotogrammi dell'iMA dai fotogrammi precedenti dell'iMA.
Ecco perché quando ho iniziato i back-test nel 2013 la differenza era più grande, nel 2012 era più piccola di quando ho iniziato nel 2013, inizio=2011 ancora più piccola, e così via. La differenza era ancora visibile anche quando ho iniziato il back-test dal 2009, quindi è un problema serio.
Ho confermato prima che c'è un problema con la modalità SMMA, penso che tu l'abbia già segnalato al Service Desk? Le altre modalità mi sembrano ok.
Sto finendo di scrivere la mia procedura di sostituzione dell'iMA in modo da poter documentare completamente e capire il problema. (non solo tramite confronto visivo come fatto in questo thread).
I risultati di ima, la mia sostituzione ima e i risultati della media mobile personalizzata saranno disponibili nel log per il confronto.
PS. se confermi l'errore lo sto segnalando ora. (Aggiungerò un nuovo commento in questo thread quando il problema sarà segnalato). Il sito (o il mio internet) funziona molto lentamente al momento, quindi ho problemi anche ad arrivare alla pagina del service desk.Ho pensato che anche altri tipi di MA siano interessati, ma ho fatto altri test e SSMA sembra l'unico interessato, come hai detto tu.
ma ho notato il problema iCustom. Script per testare i problemi di SSMA e iCustom:
Analizzando come funziona l'indicatore di media mobile personalizzato capisco perché ci sono problemi del genere.
Ogni media mobile viene conteggiata in modo non crudo contando il prossimo frame della media mobile dal precedente frame della media mobile invece di contare solo i frame necessari (in questo caso 370) per l'equazione. In questo modo, se 1 fotogramma della media mobile non è corretto, lo saranno anche tutti quelli successivi. Più lontano dall'error-frame più piccolo sarà l'errore. Potrebbe anche funzionare correttamente se tutti i fotogrammi dall'inizio fossero contati correttamente, ma ho notato che a volte l'iMA all'inizio riporta degli zeri (ho una procedura per scartare le letture di ma difettose, ma l'iMA stessa non lo fa) e questi zeri sono probabilmente anche presi in considerazione quando si contano i prossimi fotogrammi di iMA dai precedenti fotogrammi di iMA.
Ecco perché quando ho iniziato i back-test nel 2013 la differenza era più grande, nel 2012 era più piccola di quando ho iniziato nel 2013, inizio=2011 ancora più piccola, e così via. La differenza era ancora visibile anche quando ho iniziato il back-test dal 2009, quindi è un problema serio.
I don't see the problem. iMA is well coded for performance. If an iMA report a 0 it's because you don't have data (or enough data). By the way there is only a problem with SMMA, I don't know why, but it cannot be due to this "incremental" implementation as it's working well for other mode.
Sì, hai ragione, sarebbe molto più lento. Ma il fatto è che questo modo di contare più alcuni fotogrammi vuoti (zeri) all'inizio comporterebbe problemi del genere. (questo è il motivo per cui iMA SSMA è sempre più piccolo, non più grande del SSMA reale) So che non controllo ciò che iMA restituisce, ecco perché ottengo degli zeri all'inizio invece di gestire correttamente la mancanza di informazioni necessarie, ma questo è un problema diverso.
Con i TF più piccoli ci sono molti più frame analizzati e il problema può essere diluito nel tempo. Con ogni nuovo frame l'ima SSMA si avvicina sempre di più alla SSMA reale, quindi più barre passano, meno visibile è il problema, ecco perché penso che nessuno lo abbia notato prima. Lo stesso problema l'ho trovato con 370 SSMA e PERIOD_12H PERIOD_8H, ecc.
Se hai tempo per favore esamina la funzione iCustom. Ho allegato il codice sorgente per testarlo facilmente. Controllate qualsiasi TF inferiore che PERIOD_D1 - iCustom funziona bene e restituisce gli stessi valori di iMA. In PERIOD_D1 è sempre zero per iCustom, mentre iMA riporta ancora alcuni valori.
La cosa curiosa è che quando si usa SSMA su max PERIOD_H12 sia iMA che iCustom "custom moving average" indicator riportano valori errati. (prova dal 2014.01 per vedere la differenza)
L'errore deve essere da qualche parte qui: (modulo media mobile personalizzata)
Notate che il firstValue è contato come nella procedura SMA:
come firstvalue = (x1 + x2 + x3 + ... + xn) / n
che è l'equazione "grezza" per la media mobile semplice, ma non per la media mobile sfumata
forse questa è la ragione del problema?
da quel sito:
https://mahifx.com/indicators/smoothed-moving-average-smma
Il primo valore della media mobile lisciata è calcolato come una media mobile semplice (SMA):
SUM1=SOMMA (CLOSE, N)
SMMA1 = SOMMA1/ N
La seconda media mobile e le successive sono calcolate secondo questa formula:
SMMA (i) = (SUM1 - SMMA1+CLOSE (i))/ N
Dove:
SUM1 - è la somma totale dei prezzi di chiusura per N periodi;
SMMA1 - è la media mobile lisciata della prima barra;
SMMA (i) - è la media mobile lisciata della barra corrente (tranne la prima);
CLOSE (i) - è l'attuale prezzo di chiusura;
N - è il periodo di lisciatura.
Quindi credo che l'iMa e le medie mobili personalizzate lo facciano nel modo giusto. Ma il calcolo in questo modo produce gli errori che abbiamo riscontrato con conseguenti enormi differenze a seconda dei periodi testati. È totalmente inaccettabile per un EA che basa i suoi trade sulla media mobile. Credo che dovrò eliminare la Smoothed MA per questo motivo dal mio EA poiché produce risultati errati durante il backtesting. Anche se lo testassi dal 2000 e lo ottenessi correttamente, i clienti potrebbero testarlo dal 2013 e dire "spazza via il conto" perché otterrebbero altre SSMA rispetto a me.
Un'altra citazione:
La SMMA dà ai prezzi recenti un peso uguale ai prezzi storici. Il calcolo prende in considerazione tutte le serie di dati disponibili piuttosto che riferirsi ad un periodo fisso.
Ecco perché è diverso ogni volta che cambia il periodo di back-test.
Per favore non rispondere all'interno della citazione. Come vedi, quando voglio citarti ora è vuoto.
L'algoritmo è buono per SMMA, bisogna iniziare da qualche parte. Ma tu indichi l'origine del problema, poiché la SMMA è costruita sul valore precedente, è sensibile alla condizione di partenza. Dato che non hai la stessa candela di partenza su un grafico live e con lo Strategy tester, questo spiega i diversi valori.
Lo stesso vale per l'EMA, dopo un secondo controllo (su D1) ora ho anche valori diversi, come per la SMMA.
da quel sito:
https://mahifx.com/indicators/smoothed-moving-average-smma
Il primo valore della media mobile lisciata è calcolato come una media mobile semplice (SMA):
SUM1=SOMMA (CLOSE, N)
SMMA1 = SOMMA1/ N
La seconda media mobile e le successive sono calcolate secondo questa formula:
SMMA (i) = (SUM1 - SMMA1+CLOSE (i))/ N
Dove:
SUM1 - è la somma totale dei prezzi di chiusura per N periodi;
SMMA1 - è la media mobile lisciata della prima barra;
SMMA (i) - è la media mobile lisciata della barra corrente (tranne la prima);
CLOSE (i) - è il prezzo di chiusura corrente;
N - è il periodo di lisciatura.
Quindi credo che l'iMa e le medie mobili personalizzate lo facciano nel modo giusto. Ma il calcolo in questo modo produce gli errori che abbiamo riscontrato con conseguenti enormi differenze a seconda dei periodi testati. È totalmente inaccettabile per un EA che basa i suoi trade sulla media mobile. Credo che dovrò eliminare la Smoothed MA per questo motivo dal mio EA poiché produce risultati errati durante il backtesting. Anche se lo provo dal 2000 e lo faccio bene, i clienti potrebbero provarlo dal 2013 e dire "cancella il conto" perché otterranno altre SSMA rispetto a me.
Grazie per il link. Questo conferma il mio post precedente. È molto interessante perché non ho mai prestato attenzione a queste cose.
Controllando l'algoritmo di EMA è anche sensibile a tale problema, non so perché il mio primo test ha ottenuto gli stessi valori.