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
Un'opzione. Ce ne sono altri.
Abbiamo il primo raggio. Per semplicità - venendo dalla barra zero. La barra dello zero ha un massimo e un minimo. Il prezzo si muove all'interno della barra senza cambiare i suoi estremi. Poiché gli estremi non cambiano, il primo raggio dovrebbe stare fermo e non muoversi. Ma non è così. Il primo raggio sobbalza. Cambia la sua posizione. Questa è solo una descrizione della manifestazione esterna dell'instabilità. Se l'algoritmo funziona stabilmente e i parametri del mercato (massimo e minimo dell'ultima barra), da cui dipende l'operazione a zigzag, non cambiano, il primo raggio non dovrebbe vacillare. Ho lottato con questo problema per conto mio. Ma le peculiarità notate delle funzioni di ricerca mi hanno costretto ad andare sul forum.
========================
Quando spostiamo la finestra (shift,shift+ExtDepth) durante il calcolo dell'indicatore, la comparsa di un nuovo estremo può essere legata sia a un nuovo prezzo sia al fatto che il vecchio estremo è uscito dalla finestra. - Sarebbe meglio specificarlo esplicitamente. Per chiarire. Nella descrizione della lingua. Per non esplorare le possibilità nascoste della lingua.
A questo scopo, la linea if(highpos!=shift) val=0.0; . Come questo sia fatto nel codice standard, non lo capisco. A giudicare dal fatto che gli estremi penzolanti scompaiono nella mia variante, o non è fatto correttamente o non è fatto affatto. - La mia soluzione a questo problema è diversa: se (High[shift]=val) ZigZagBuffer[shift]=val; e se (Low[shift]=val) ZigZagBuffer[shift]=val;
Ma in effetti è la stessa cosa. Ma non risolve tutti i problemi. È il modo in cui combattiamo la conseguenza e non la causa. Ha cercato di combattere la conseguenza allo stesso modo. Ma sul primo raggio non funziona. Il fatto è che l'algoritmo a zig zag, diciamo, non seziona. Lasciatemi spiegare questo. Il calcolo viene eseguito su tutta la storia. E se ne correggiamo una parte, l'elaborazione rimane incompleta vicino alla barra zero, per così dire. Non riesco a trovare le parole giuste. Quindi questa incompletezza vicino alla barra dello zero fa emergere il problema di identificare correttamente gli estremi.
Ho provato a regolare i parametri della finestra (shift,shift+ExtDepth) non molto tempo fa. Anche io stavo sperimentando con la finestra l'altro giorno. Ma finora senza risultato.
Questo problema è noto ed è risolto teoricamente (ho l'algoritmo in testa da tempo). Comunque, se non appare nessun'altra soluzione, ottimizzerò l'algoritmo Zigzag. Viene fatto come segue:
1) la prima corsa viene fatta su tutta la storia come nell'algoritmo attuale
2) su ogni tick da zero barre in profondità nella storia, vengono cercati due estremi dello Zigzag, l'ultimo estremo viene forzatamente ucciso.
3) dall'ultimo (ora l'ultimo) segue di nuovo la procedura standard del calcolo Zigzag.
4) se l'estremità attuale (la coda dello ZigZag) può essere teoricamente un estremo (abbiamo il massimo dall'ultimo minimo o viceversa), diventa anche un estremo.
5) con una nuova spunta da capo dal punto 2)
Ma non è successo. Il primo raggio si contrae. Cambia la sua posizione.
Non l'ho ancora visto. Lascia un'estremità della trave fissa? E quale. Se è sulla barra zero, forse si dovrebbe dare un'occhiata più da vicino alle condizioni in cui le variabili di tipo doppio vengono confrontate?
Questo mi sembra che si riferisca all'algoritmo piuttosto che alla lingua. Quindi, un promemoria che le funzioni di cui stiamo discutendo stanno effettivamente cercando il valore massimo (minimo) del prezzo sull'intervallo, piuttosto che un estremo, sarebbe appropriato in un libro o in alcuni commenti.
il punto 4) al prossimo tick viene elaborato con un file attraverso il punto 2)
Questo problema è noto, e teoricamente risolto (c'è un algoritmo in mente da molto tempo).
La questione è che sto testando l'indicatore che utilizza lo zigzag in condizioni molto rigide. Sui minuti e con i parametri 2-1-1. Qual è lo scopo di tali test? Questo tipo di test rivela tutti i difetti nascosti abbastanza rapidamente. Inoltre c'è il desiderio che l'indicatore funzioni su tutti i timeframe senza eccezione. Il mercato è una cosa frattale. Ci sono molte persone che fanno trading sui minuti. Perché dovremmo privarli dell'opportunità di lavorare con lo strumento familiare su piccole scadenze?
Mi piace di più la mia versione). Funziona con i numeri interi. Quando si esegue un tale confronto di doppi (di tipo Low[shift]==val) può causare dei battimenti.
Finora non ho incontrato alcuna difficoltà a lavorare con il doppio. Questi numeri sono conservati in memoria senza modifiche. Ma il mio confronto prende valori da una sola cella di memoria. Se ci sarà un problema in questo posto, è una questione di hardware (cioè di computer). Bisogna fare qualcosa con l'hardware.
Mi sembra che questo si riferisca non al linguaggio, ma all'algoritmo. Quindi, un promemoria che le funzioni di cui stiamo discutendo stanno effettivamente cercando il valore massimo (minimo) del prezzo sull'intervallo, piuttosto che un estremo, sarebbe appropriato per un libro o alcuni commenti.
L'ho appena definito un extremum. È in realtà il massimo e il minimo dell'intervallo scelto. È una pronuncia lunga. Ma il significato è lo stesso.
C'è stato per molto tempo su CodeBase.mql4.com. Ma questa descrizione è molto difficile da capire. E contraddittoria. Durante l'estate, credo che Slava abbia messo a punto il codice dello zigzag. Solo una parte della descrizione precedente è rimasta sul sito dopo.
Lavorare con il doppio non ha causato alcuna difficoltà finora. Questi numeri sono conservati in memoria senza modifiche. E il mio confronto prende valori da una singola posizione di memoria. Se si verifica un problema qui, è una questione di hardware - il computer. Bisogna fare qualcosa con l'hardware.