>> chi guarderebbe questo avatar e penserebbe che c'è qualcosa di umano dietro di esso?
In effetti, sono ancora più spaventoso all'interno...
Ma dovresti metterlo nel database, qui si perde, ed è una cosa interessante.
Si potrebbe pensare che non si perda lì dentro. Qui, almeno le versioni possono essere aggiunte ogni cinque minuti. Con correzioni e innovazioni. E poi c'è il fluffing.
Perché non fare lo stesso modello in kodobase come nei rami? È un mistero. E non solo per me, a giudicare dal forum.
In effetti, sono ancora più spaventoso all'interno...
Si potrebbe pensare che non si perda lì dentro. Qui, almeno le versioni possono essere aggiunte ogni cinque minuti. Con correzioni e innovazioni. E poi c'è il fluffing.
Perché non fare lo stesso modello in kodobase come nei rami? È un mistero. E non solo per me, a giudicare dal forum.
Rispetto!
E rispetto! ;)
Ti ho detto che "la bellezza salverà il mondo" ....
Grazie per il bel tacchino.
E qual è lo "slittamento" di questo zigzag? La pendenza è il rapporto tra l'ampiezza media di un segmento dello zigzag al momento della sua registrazione e l'ampiezza media dei segmenti completati.
È possibile calcolare - tutti i dati sono nel codice. Ma per cosa? È possibile vedere dove sono gli estremi e dove sono realmente determinati dal tempo: il parametro ShowZigZag (1 - dove, 2 - quando).
Altrimenti... questo parametro di "slittamento" è puramente accademico, IMHO. Nessuno andrà lungo per, diciamo, il rilevamento del trogolo. Piuttosto il contrario (è così che si fa), se il contesto lo richiede.
Bene guardate, ecco l'ultima foto di oggi degli Eurobucks sui verbali. Il canale viene visualizzato così com'è, come viene disegnato in tempo reale, cioè al momento dell'identificazione degli estremi. È chiaro che sarebbe logico andare long (ovviamente il contesto è long) nei periodi successivi alla definizione dei picchi (cambiamento della divergenza superiore del canale) puntando su qualche oscillatore minore in particolare. E non viceversa.
Ma è possibile, ripeto, calcolare. Devi proprio?
===
Allora questo parametro sarà diverso per i diversi parametri di ingresso dell'indicatore. Una cosa è usare 3, 12, e un'altra è usare 1, 7. Possiamo usare anche quelli spostati. È possibile visualizzare la pendenza media nel buffer nella modalità in tempo reale? È possibile. Non sono sicuro che sarebbe necessario. Anche se... Sì - si può in un certo senso stimare quando entrare. Ma sarebbe così impreciso che sarebbe una spina nel fianco. No, non credo.
Potete calcolarlo - tutti i dati sono nel codice. Ma per cosa?
Ho formulato una specie di teorema per me: per qualsiasi mercato (liquido), per qualsiasi zigzag, lo slippage medio sarà circa 1/2. Difficilmente può essere dimostrato, ma basterebbe un solo fatto per smentirlo. Quindi il mio interesse, e giustamente, è piuttosto accademico :) .
Esattamente questo "teorema" dice che "dritto" e "il contrario" dipendono dal contesto in egual misura, imho.
E no, penso che 1/2 sarà per qualsiasi serie di parametri e anche per qualsiasi zigzag :)
Emettere lo slittamento medio nel buffer in tempo reale?
Di solito faccio la somma dei dati al volo e li mando in uscita su Comment (diviso per il contatore, ovviamente).
Il rilevamento del contesto è ovviamente un argomento separato, e molto più interessante :). Siete in grado di formalizzare questa procedura? Cioè, la cosmetologia dell'orso bruno è una scienza esatta? :)
Ho formulato una specie di teorema per me: per qualsiasi mercato (liquido), per qualsiasi zigzag, lo slippage medio sarà circa 1/2. Difficilmente può essere dimostrato, ma basterebbe un solo fatto per smentirlo. Quindi il mio interesse, e giustamente, è piuttosto accademico :) .
Bene... se questo è il caso, naturalmente. Anche se, sapete, stavo pensando - potrebbe non essere accademico. Comunque, ci penserò, ok?
È solo questo "teorema" che dice che "dritto" e "al contrario" sono ugualmente dipendenti dal contesto, imho.
Non proprio, penso che 1/2 sarà per qualsiasi serie di parametri e anche per qualsiasi zigzag :)
Nel limite? Saluti Marchese de Lopital.))) Probabilmente. Solo da un punto di vista pratico tutta questa considerazione BP in generale è un cactus sempreverde con i suoi topi.
Di solito riassumo i dati al volo e li mostro in Comment (diviso per il contatore, ovviamente).
Puoi farlo anche in questo modo. Ma non si può contare dopo dai commenti. Ecco perché ho menzionato il buffer.
Definire il contesto è un argomento a parte e molto più interessante :). È possibile formalizzare questa procedura? Cioè, la cosmetologia dell'orso bruno è una scienza esatta? :)
А... questo è quello che vuoi dire! >> Sì, sì. >>)) Formalizzato... Sì, certo. E non ieri. Ma è davvero un argomento molto separato. Non si può nemmeno fare un articolo qui. Anche se questo thread, forse, andrà bene. Su questo sporadico, ma ha ripetutamente scritto in vari altri rami. In termini generali, naturalmente, ha scritto - sarebbe strano dettagliare lì. Ma qui, una specie di seguito... Sì, penso che scriverò lentamente. Non Time Frame o Non Fiction, sì)). Anche se, se si guarda dentro, non c'è niente di nuovo che potrei dire che qualcuno non sappia. Tale è il paradosso)))
===
In generale, un "recupero" è probabilmente una buona idea. È possibile raccogliere in un unico luogo ciò che è stato occasionalmente menzionato, scritto, ecc. // I miei messaggi, come i vini preziosi, avranno il loro turno. ("Sparsi nella polvere dei negozi..." Akhmatova)
Beh, di certo non morirò di modestia. Questo è un bene. )))
Bene... se questo è il caso, certo. Anche se, sapete, stavo pensando - l'interesse potrebbe non essere accademico. Comunque, ci penserò, ok?
Al limite? Salve, Marchese de Lopital). Forse. Solo da un punto di vista pratico, tutta questa considerazione BP in generale è un cactus sempreverde con i suoi topi.
Si può fare così. Solo che dopo non si conta dal commento. Ecco perché ho menzionato il buffer.
1 Se fosse urgente, aggiungerei io stesso il codice e lo calcolerei :)
2. 2. Nel limite.
3. Se l'indicatore è veloce - è più facile ricalcolarlo, se è lento - è meglio metterlo direttamente in un file.
Ma se è davvero "forse non accademico", io ascolterei.
А... questo è quello che vuoi dire! Si, si.)) La formalizzazione è riuscita... Sì, certo. E non ieri. Ma è davvero un argomento molto separato. Non si può nemmeno fare un articolo qui. Anche se questo thread, forse, andrà bene. Su questo sporadico, ma ha ripetutamente scritto in vari altri rami. In termini generali, naturalmente, ha scritto - sarebbe strano dettagliare lì. Ma qui, una specie di seguito... Sì, penso che scriverò lentamente. Non Time Frame o Non Fiction, sì)). Anche se, se si guarda dentro, non c'è niente di nuovo che potrei dire che qualcuno non sappia. >> Questo è il paradosso).
Interessante, interessante. Anche se confesso di avere un po' di scetticismo iniziale.
A proposito, formalizzazione reale significa essere in grado di controllare la storia, l'avete fatto?
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Avevo una voce in CodeBase su zigzag e canali orizzontali su indici diversi. Recentemente una persona voleva uno Zigzag su una croce di due MA, cosa che ha detto pubblicamente sul forum. Non è una cosa difficile da fare - basta modificare quella già pronta ed è fatta. La cosa volgare è che ha corretto ZigZag sulla base dell'indicatore sconosciuto per me e ha chiesto di farlo. Ho rifiutato. Non mi piace curiosare nei codici degli altri, vorrei capire alcuni dei miei codici. Poi, sentendo una certa responsabilità per quello che ho messo insieme/pubblicato, così come un certo disagio derivante dal rifiuto di aiutare, ho deciso di fare un indicatore che può fare quanto segue:
Lasciatemi spiegare il principio dell'identificazione dei picchi e delle depressioni dei prezzi (estremi). L'immagine (1) mostra due EMA - veloce e (puoi indovinare tre volte) - correttamente, lento. Le aree tra gli incroci sono segnate in verde e in rosso, rispettivamente per i picchi e le depressioni. È lì che vengono cercati. In generale, l'uso di due MAE permette un approccio piuttosto flessibile all'identificazione degli estremi.
Per esempio, DiNapoli si esercita usando il DMA - prime MA spostate (qualcuno glielo ha mostrato - proprio come gli insegnamenti di Don Juan). È possibile cercare gli estremi per DMA usando questo indicatore? Domanda di merda (sn.2). Impostiamo il valore del periodo della MA veloce = 1 e il periodo e l'offset della MA lenta =3 e otteniamo gli estremi identificati incrociando il prezzo di chiusura della barra con una MA semplice a 3 barre spostata di 3 barre. Mi sembra che oltre al suddetto 3 per 3, Joe usi 7 X 3 e 25 X 5 per visualizzare i MAK. Potresti semplicemente usare l'intersezione della MA e la sua replica compensata da qualsiasi barra (sn.3) - un po' come l'ACF. Alla fine, si possono semplicemente mettere i valori del periodo MAA per la classe. (12,26) o il MACD di DiNapoli (8,17) (sn,4) e si sentono felici di essere coinvolti nelle sciocchezze degli altri.
Il canale orizzontale è costruito usando gli estremi trovati (sn.5). Se impostiamo il periodo di smoothing del canale maggiore di 1, il canale grezzo rimarrà sotto forma di trattini, mentre quello smoothed sarà disegnato come linee solide (fn.6 - smoothing period =3).
La linea di tendenza (fn. 6) è disegnata come supporto sotto i prezzi per una tendenza al rialzo, o come resistenza sopra i prezzi per una tendenza al ribasso. La condizione di ribasso/rialzo è determinata dalla rottura del bordo del canale corrispondente o del prezzo di chiusura della barra, o del suo High/Low. Il confine del canale può essere spostato di un certo valore in pip o dell'ATR (parametro Border) per evitare che il confine del canale sia sfondato da un picco di rumore.
Bene, le correzioni (сn.7) e le estensioni, così come il canale equidistante, sono chiare senza alcuna spiegazione. Per il canale Fibo ho fatto alcuni cambiamenti nei livelli di default - altrimenti non ha molto senso, IMHO (fn. 8).
Maggiori dettagli sui parametri di input:
// parametri MAC
FastMA - periodo del digiuno МА.
SlowMA - periodo di una MA lenta.
SlowMAshift - spostamento di un MA lento.
Metodo - algoritmo di lisciatura.
// soglia di attivazione
ATR - periodo di ATR per la sensibilità adattiva.
xATR - moltiplicatore per il valore ATR.
Sens - sensibilità in punti.
// canale orizzontale
ChannelMA - periodo di lisciatura dei bordi del canale.
Border - rientro in punti dai bordi del canale. Utilizzato per determinare la ripartizione del canale. Meno di zero - viene selezionato il valore massimo tra la sensibilità Zigzag di ATR e il modulo del parametro inserito.
// che diavolo di stecca! (0 - non mostrare un cazzo).
ShowTrend - 1 - mostra la tendenza determinata dalla rottura dei bordi del canale barra HIgh/Low; 2 - Close.
ShowChannel - mostra il canale orizzontale in base alla posizione degli estremi; 2 - in base al tempo della loro determinazione (al momento di fissare l'incrocio MA MA).
ShowZigZag - 1 - mostra ZigZag dalle posizioni degli estremi; 2 - dal tempo della loro determinazione.
ShowFibo - 1 - mostra la correzione Fibo; 2 - estensioni Fibo; 3 - canale Fibo; 4 - canale equidistante.
===
Un po' fuori luogo nel kodobase - tutto è secondario, ma è un peccato se va via. Quindi, per continuare. Ci sarà di più sulla stocastica qui. Più tardi.