Cosa restituiscono le funzioni Lowest e Highest - pagina 3

 
Candido, cercherò di descrivere l'instabilità dell'operazione.

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.
 
Il punto è 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 ancora 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. <br/ translate="no">.


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)
 
nen:
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?

Quando spostiamo la finestra durante il calcolo dell'indicatore (shift,shift+ExtDepth), la comparsa di un nuovo estremo può essere legata al nuovo prezzo o al fatto che il vecchio estremo è uscito dalla finestra. - Sarebbe meglio specificarlo esplicitamente. Per chiarire. Nella descrizione della lingua.

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.
Per fare questo nel mio inserire 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;
Mi piace di più la mia versione :). Funziona con i numeri interi. In un tale confronto di doppi (come Low[shift]==val) può semplicemente apparire come un battimento.
 
Rosh, ho la stessa opzione. Nella mia testa. Ci sono alcuni punti vaghi che mi impediscono di realizzarlo. Mettiamola così. Il punto 4) è un po' fuori dall'algoritmo. È già un altro algoritmo. E quando la sezione elaborata al punto 4) sarà disponibile per la storia, la sua elaborazione con l'algoritmo che parte dal punto 1) può portare a disegnare altri estremi. Cioè, il tempo reale e la storia saranno diversi. Questo, secondo me, non è accettabile.
 
Rosh Ho la stessa opzione. Nella mia testa. Ci sono alcuni punti vaghi che mi impediscono di realizzarlo. Mettiamola così. Il punto 4) è un po' fuori dall'algoritmo. Questo è un algoritmo diverso. E quando la sezione elaborata al punto 4) sarà disponibile per la storia, la sua elaborazione con l'algoritmo che parte dal punto 1) può portare a disegnare altri estremi. Cioè, il tempo reale e la storia saranno diversi. Questo, secondo me, non è accettabile.


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).
C'è una descrizione verbale di cosa dovrebbe fare lo zigzag? Qualcosa come una specifica tecnica.
 
Non l'ho ancora visto. Lascia un'estremità della trave attaccata? E quale. Se è sulla barra zero, allora forse si dovrebbe dare un'occhiata più da vicino alle condizioni in cui le variabili di tipo doppio vengono confrontate?
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'è una descrizione verbale di cosa dovrebbe fare lo zigzag? Qualcosa come i termini di riferimento?
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.
 
nen:
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.
Beh, sono guidato dal codice nel ramo. E calcola il valore ogni volta. È solo più sicuro non usare == quando si confronta dou
 
Beh, sono basato sul codice del ramo. E calcola il valore ogni volta. È vero, è così. Si trova il numero di una cella. Da questa cella (serie temporale), si prende il valore della barra massima o minima. Si ritiene che il massimo sia stato trovato su questa barra. Questo valore viene poi messo nel buffer dell'indicatore con il numero trovato. Il massimo dell'indicatore dovrebbe corrispondere al massimo sulla barra. Nel mio codice, il massimo è anche preso dall'array (serie temporale) con lo stesso numero trovato e confrontato con il valore di val. Si controlla se stiamo facendo la cosa giusta: mettiamo nel buffer con questo numero il valore di val. Dovrebbe anche essere uguale al massimo della barra. Il confronto di numeri presi dallo stesso posto è abbastanza corretto.