Confronto tra la media mobile (e qualsiasi altro indicatore) e l'errore - pagina 2
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
Questo non ha nulla a che fare con mql in linea di principio. Prendiamo un linguaggio di programmazione astratto. In questo particolare esempio che ho dato, il problema principale è che i valori della differenza di muwings in una stessa barra non sono uguali (2e-16 nel primo calcolo ed esattamente 0 nel secondo). In questo caso, questa intersezione non può essere determinata in alcun modo. Se torniamo a mql, la normalizzazione implica l'arrotondamento del numero(o meglio, semplicemente l'eliminazione di tutti i numeri dopo un certo segno, come nella funzione floor di Sish, ma fino a una certa cifra decimale). Quindi come faccio a sapere a quale cifra normalizzare? Se viene scelta la cifra sbagliata, tutti i valori possono SEMPRE essere arrotondati esattamente a 0. Quindi la normalizzazione è pericolosa qui e generalmente non risolve il problema.
Per quanto riguarda quello che ha scritto Alexey Lebedev. Sì, stavo pensando in questa direzione. Ma se confrontiamo entrambe le differenze per più o uguale a 0, c'è una probabilità di ottenere un falso segnale (per esempio, la situazione teoricamente possibile quando i muwings tra barre vicine hanno esattamente gli stessi valori). Allora la loro differenza non cambia il segno (non c'è crossover), ma il segnale per il crossover sarà determinato programmaticamente. Potresti mettere solo un confronto su più o uguale, come hai suggerito tu. Ma allora il problema è che nel calcolo in questa situazione prima non sarà uguale a 0 (2e-16), e sulla prossima barra sarà esattamente 0 ma sarà un confronto rigoroso.
È importante capire perché la stessa differenza, se calcolata su barre diverse, non produce lo stesso risultato. Se il risultato fosse lo stesso, il problema si risolverebbe sempre introducendo un confronto non rigido.
Quando si normalizza, sì, c'è l'arrotondamento a una data cifra decimale. Non scartando tutti i numeri dopo un certo segno, ma arrotondando.
Se ti capisco esattamente in quel contesto (prendo sia il tuo primo post con lo screenshot che il tuo secondo), vari esperimenti con tale metodo, tra cui prendere in considerazione DoubleToString quando si stampa, suppongo, possono ancora aiutarti. Rosomah te ne ha parlato prima di me.
Compreso, aiutare a determinare da soli a quale figura di normalizzare a qualsiasi attività, o se in alcuni casi la normalizzazione è necessaria (in casi di dubbi, applicazione o non sul set di fattori correlati, tra cui che il programma poi può essere applicato in diversi DC e, di conseguenza, i valori calcolati possono essere diversi).
Dal mio punto di vista, il pericolo di ottenere segnali che possono essere considerati falsi, a seconda del compito da svolgere, può essere solo quando la normalizzazione non viene applicata (o quando non c'è confronto nel primo modo a causa di qualche piccolo valore) dove non farebbe alcun danno.
Inoltre, se DoubleToString non viene applicato nella stampa, ci può essere semplicemente un'idea sbagliata che la stessa differenza o gli stessi valori non siano lo stesso risultato.
/* Per sicurezza, vorrei ricordare di nuovo che quando si stampano numeri di tipo doppio, è necessario usare DoubleToString, perché l'output di stampa converte un valore numerico in un valore di testo. Di conseguenza, se questa funzione non viene utilizzata, si possono vedere errori che in realtà non ci sono.
Il numero di cifre decimali in questa funzione, naturalmente, con un numero di cifre decimali non inferiore ai valori normalizzati. E per i valori non normalizzati, il numero di cifre decimali è maggiore.
Il calcolo della funzione iMA è molto probabilmente ottimizzato. Primo valore = somma(close)/N, secondo = valore precedente di MA+(new close-old close)/N.
Quindi gli iMA in generale per la stessa barra possono dare valori diversi dei due muwings a tempi di chiamata diversi?
Quando si normalizza, sì, c'è l'arrotondamento alla cifra decimale specificata. Si tratta di arrotondamento, non di scartare tutti i numeri dopo una certa posizione decimale.
Se ti capisco esattamente in quel contesto, che intendi (prendo in considerazione sia il tuo primo post con lo screenshot che il secondo post), allora vari esperimenti con tale metodo, incluso il prendere in considerazione DoubleToString quando si stampa, credo, possono ancora aiutarti.
Incluso, aiutare a definire per te stesso a quale figura per normalizzare a qualsiasi attività, o se la normalizzazione è necessaria in alcuni casi (in casi di dubbio, utilizzare o non utilizzare sul set di fattori di accompagnamento, tra cui che programma quindi può essere applicato in diversi DC e, rispettivamente, i valori calcolati risultanti possono essere diversi).
Dal mio punto di vista, il pericolo di ottenere segnali che potrebbero essere considerati falsi, a seconda del compito da svolgere, può essere solo quando la normalizzazione non viene applicata (o quando il primo metodo non viene confrontato a causa di qualche piccolo valore) dove non sarebbe male.
Inoltre, se DoubleToString non viene applicato nella stampa, ci può essere semplicemente un'idea sbagliata che la stessa differenza o gli stessi valori non siano lo stesso risultato.
/* Per sicurezza, vorrei ricordare di nuovo che quando si stampano numeri di tipo doppio, è necessario usare DoubleToString, perché l'output converte un valore numerico in un valore di testo. Di conseguenza, quando questa funzione non viene utilizzata, possono verificarsi i seguenti errori
Il numero di cifre decimali in questa funzione, naturalmente, con un numero di cifre decimali non inferiore ai valori normalizzati. E per i valori non normalizzati, il numero di decimali è maggiore.
È chiaro che l'ultima cifra significativa è arrotondata. Ma se, per esempio, si mettono 5 cifre significative per il numero 0,000016, sarà 0,00002, e se ci sono meno cifre significative, sarà sempre 0. Quindi l'arrotondamento a una cifra specifica non è sempre possibile. I valori di MA non dipendono solo dal timeframe, ma anche dalle barre stesse. Quindi non è chiaro come impostare il numero di cifre significative durante la normalizzazione nel caso generale.
Quello che non riesco a capire del valore infinitesimale è come applicarlo. Infinitesimo (errore) è usato per confrontare un numero reale con 0. Io, invece, ho bisogno di confrontare la differenza. La situazione qui potrebbe essere ancora peggiore. Per esempio, ho impostato alcuni epsilon. Quando la differenza è maggiore di epsilon, la considero positiva. Quando è inferiore a meno l'epsilon, è negativo. Quando è all'interno dei confini è 0. Ma allora come si fa a determinare il cambiamento del segno della differenza? Per esempio, la differenza di movimenti su due barre è entro l'epsilon. Ma nel primo caso è positivo, nel secondo è negativo (cioè l'incrocio è già avvenuto). E io, tenendo conto dell'introduzione dell'errore, considererò la differenza come 0. Allora la condizione di cambio di segno dovrebbe essere cambiata. Condizionatamente, il segnale di due MA che attraversano dall'alto in basso in questo caso sarà sia un semplice confronto di <0 (era) e >0 (è diventato), sia =0 (era) e >0 (è diventato). E soprattutto, nel caso descritto (quando i valori nello stesso punto sono diversi per diverse chiamate) introdurre questo errore non aiuta. Questa differenza può sempre essere tale che qualsiasi epsilon si scelga, non si otterrà un segnale.
È chiaro che l'ultima cifra significativa è arrotondata. Ma se, per esempio, per un numero 0,000016 si mette la normalizzazione con 5 cifre, sarà il numero 0,00002, e se meno cifre, sarà sempre 0. Quindi l'arrotondamento a una cifra specifica non è sempre possibile. I valori di MA non dipendono solo dal timeframe, ma anche dalle barre stesse. Quindi non è chiaro come impostare il numero di cifre significative durante la normalizzazione nel caso generale.
Quello che non riesco a capire del valore infinitesimale è come applicarlo. Infinitesimo (errore) è usato per confrontare un numero reale con 0. Io, d'altra parte, ho bisogno di confrontare la differenza. La situazione qui potrebbe essere ancora peggiore. Per esempio, ho impostato alcuni epsilon. Quando la differenza è maggiore di epsilon, la considero positiva. Quando è inferiore a meno l'epsilon, è negativo. Quando è all'interno dei confini è 0. Ma allora come si fa a determinare il cambiamento del segno della differenza? Per esempio, la differenza di movimenti su due barre è entro l'epsilon. Ma nel primo caso è positivo, nel secondo è negativo (cioè l'incrocio è già avvenuto). E io, tenendo conto dell'introduzione dell'errore, considererò la differenza come 0. Allora la condizione di cambio di segno dovrebbe essere cambiata. Condizionatamente, il segnale di due MA che attraversano dall'alto in basso in questo caso sarà sia un semplice confronto di <0 (era) e >0 (è diventato), sia =0 (era) e >0 (è diventato). E soprattutto, nel caso descritto (quando i valori nello stesso punto sono diversi per diverse chiamate) introdurre questo errore non aiuta. Questa differenza può essere sempre tale, che qualunque epsilon si scelga, non si otterrà il segnale.
Penso che quando si risolvono problemi particolari, si può anche fare affidamento sulla precisione delle cifre significative decimali. Al doppio è di 15 cifre significative, secondo la documentazione. Il formato della precisione di normalizzazione, da 0 a 8, secondo la documentazione. DoubleToString ha le sue peculiarità di formati di precisione.
Inoltre, iMA è, dal mio punto di vista, una funzione che tiene conto del fatto che i valori derivati con essa saranno applicati in diverse situazioni e per risolvere diversi problemi. Di conseguenza, i valori che emette possono essere elaborati in modo diverso, anche in relazione a compiti specifici.
Inoltre, il calcolo delle medie è un calcolo matematico. Per esempio: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... Corrispondentemente, i valori calcolati con arrotondamenti piccoli o estesi aumentano le opzioni di applicazione dei calcoli.
Nel caso, voglio menzionare che invece di iMA, potete usare le funzioni della libreria MovingAverages, che è inclusa nel pacchetto standard del terminale. Oppure potete usare le vostre funzioni basate su quelle di questa libreria.
/* Nei calcoli matematici, ci possono essere delleparticolarità nel lavorare con numeri di tipo doppio */.
Sugli epsilon, invece, passo.
P./S.: Allora, penso che gli esperimenti possano aiutarti. Il ragionamento teorico senza esperimenti pratici (su grandi quantità di dati) per compiti specifici, tra cui, può confondere, e portare lontano da soluzioni accettabili.
Dina Paches:
...
Che casino! Abbiamo confrontato le mascotte per 300 giorni... Normalizzare alle cifre e non preoccuparsi...
Potete normalizzare i valori direttamente (la differenza - non c'è modo). Ma ancora una volta, il codice di benchmark dato per il confronto di MA deve essere cambiato e si dovrebbe comunque inserire una disuguaglianza non rigida. Inoltre, rimane aperta la questione dei diversi valori di MA su una stessa barra quando sono calcolati in tempi diversi. Se si ripeterà ulteriormente, non è sicuro che anche la normalizzazione e l'introduzione di una disuguaglianza non rigida risolverà completamente il problema. Inoltre il caso in cui i muwings all'interno di una barra si intersecano due volte, non si può prendere, se si analizza non da ticks, ma dall'apertura di una nuova barra. Forse puoi condividere la tua esperienza, come ti comporti in questa situazione?
Beh, in primo luogo, la differenza di due valori normalizzati darà alla fine un valore non normalizzato. Dovete controllare la differenza normalizzata.
In secondo luogo, se volete catturare i crossover all'interno di una barra, prendete i valori di tutti i tick sullo zero e sulla prima barra - ne prenderete molti... ...basta fare attenzione...
Se testate dall'apertura di una barra, allora l'Expert Advisor dovrebbe chiaramente monitorare l'apertura di una nuova barra, e dopo il fatto, controllare i crossover.
Prima decidi per te stesso - fare trading all'apertura della barra o ad ogni tick, poi scrivi il tuo codice. E, di conseguenza, testarlo allo stesso modo.
Dina, sono stupito dalla tua angelica pazienza...
Grazie, Artem, ma purtroppo si scopre che può avere anche dei limiti.