Un po' sorpreso :) Ho pensato di condividere e fare una domanda NON retorica. - pagina 7
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
Il punto non è nel tester, di nuovo! Non nel tester, ma in condizioni reali in cui la storia viene scaricata e si verificano errori di connessione.
Se un reset e un ricalcolo dell'indicatore avvengono nella vita reale, non c'è niente di male.
È sorta un'altra domanda. La maggior parte della gente non ha niente da fare qui? Stanno riscrivendo la funzionalità standard del terminale per mql5. Forse, qualcuno scriverà molto presto un intero terminale su mql5.
Se, in condizioni reali, si verifica un reset e un ricalcolo dell'indicatore, non c'è niente di male in questo.
È sorta un'altra domanda. La maggior parte della gente non ha niente da fare qui? Stanno riscrivendo la funzionalità standard del terminale per mql5. Forse, qualcuno scriverà molto presto un intero terminale su mql5.
Certo, non è così male. Quando hai 100 ZUP in un terminale (solo per esempio), non è un problema...
È venuta fuori la stessa domanda. A tutti piace parlare solo dal loro punto di vista, perché?
C'è più di un indicatore usato qui:
L'influenza della funzione standard IndicatorCount è semplicemente micidiale (l'ho controllata personalmente). E quando sono implementate come classi, le discontinuità di comunicazione sono ancora più viola
P.S. Per un MA non è ovviamente un grosso problema
Naturalmente non è un grosso problema. Quando si hanno 100 ZUP in un terminale (tanto per fare un esempio), non è un grosso problema...
È sorta la stessa domanda. A tutti piace discutere solo dal proprio campanile, perché?
Qualcuno vuole sempre più di quello che può gestire. Ma perché così tanti?
Il problema dell'azzeramento dell'indicatore può essere risolto con cinque righe di codice. Ricorda il tempo della prima barra, se è cambiato, hai bisogno di un ricalcolo completo. Memorizza il numero dell'ultima barra, in caso di reset continua il ricalcolo da questa barra ed è tutto.
Non ho paura di dire dal mio campanile, senza confermare nulla con argomenti, che il mio campanile è corretto, punto e basta.
Qualcuno vuole sempre più di quello che può gestire. Ma perché così tanto?
È possibile aggirare il problema dell'azzeramento dell'indicatore con cinque righe di codice. Ricorda il tempo della prima barra, se è cambiato, è necessario un ricalcolo completo. Memorizza il numero dell'ultima barra, in caso di reset continua il ricalcolo da questa barra ed è tutto.
Non ho paura di dire dal mio campanile, senza confermare nulla con argomenti, che il mio campanile è corretto e basta.
Non essere così moralista. Imparate non solo ad ascoltare, ma a sentire gli altri.
La storia può cambiare nel mezzo e il tuo approccio andrà a pezzi. Chiedi a Renat di questo.
L'errore in IndicatorCounted() in MT4, che è stato risolto con il mio suggerimento solo ora, mandava al macero anche gli indicatori scritti correttamente (specialmente ZigZag su piccoli TF).
Per non parlare del suo approccio a questo caso....
Non voglio nemmeno discutere con te perché hai completamente torto in questa situazione.
Non essere così sicuro di te stesso. Imparate non solo ad ascoltare ma anche a sentire gli altri.
La storia può cambiare nel mezzo e il vostro approccio andrà in pezzi. Chiedi a Renat di questo.
L'errore in IndicatorCounted() in MT4, che è stato corretto solo ora con il mio suggerimento, mandava nella spazzatura anche indicatori scritti correttamente (specialmente ZigZag su piccoli TF).
Non voglio nemmeno discutere con te, perché hai completamente torto in questa situazione.
Aggiungete un paio di controlli in più al momento del reset, se il numero di barre è aumentato, ma il tempo della barra non è cambiato o se è stata aggiunta più di una barra.
Per quanto riguarda l'essere troppo sicuro di sé, è il contrario, tu sei quello troppo sicuro di sé, tu sei il terzo che pensa di essere più figo di MQ.
Aggiungere un paio di controlli in più al momento del reset, se il numero di barre è aumentato ma il tempo della barra non è cambiato o se è stata aggiunta più di una barra.
Per quanto riguarda l'autostima, è il contrario, siete tutti voi quelli troppo sicuri di sé qui, tu sei il terzo che pensa di essere più figo di MQ.
Che tipo di assegni? Situazione. Un nuovo segno di spunta appare sulla vecchia barra. Nulla è cambiato - né il numero totale di barre, né l'ora di apertura dell'ultima barra, ma allo stesso tempo
le ultime 30 barre sono state riscritte (i loro prezzi di apertura/chiusura, max, min, sono cambiati, anche se in modo insignificante).
Cosa farete con il vostro algoritmo? Niente! Semplicemente non funzionerà in questa situazione. E l'indicatore sarà completamente sbagliato!
Ciò che era in MT4 prima delle ultime build - nel 70% dei casi non avrebbe reagito a questa situazione.
Ma dopo aver analizzato il problema lo hanno risolto. Stingo ne ha scritto: https://www.mql5.com/ru/forum/132422
Non penso di essere più figo degli altri. Al contrario, io aiuto attivamente a risolvere tutti i bug di MT4 e MT5 - chiedete a qualsiasi rappresentante di MetaQuotes.
E il fatto che alcuni meccanismi non siano implementati nel modo in cui si vuole - non si può accontentare tutti....
È una domanda interessante su cosa sia corretto, cosa era prima o cosa era dopo la correzione della storia. Se non tornate alle barre corrette, l'indicatore continuerà a funzionare come se la storia non fosse stata corretta. Hrenfx ha esattamente questo atteggiamento, considera la vecchia storia corretta, voi avete il contrario.
C'è anche l'opinione che si dovrebbe usare solo prev_calcolato regolare, senza variazioni. Se l'indicatore è pesante, limitate il numero di barre contate all'avvio. Il resto è una danza del tamburello, il risultato è dubbio.
È una domanda interessante su cosa sia corretto, cosa era prima o cosa era dopo la correzione della storia. Se non tornate alle barre corrette, l'indicatore continuerà a funzionare come se la storia non fosse stata corretta. Hrenfx ha esattamente questo atteggiamento, considera la vecchia storia corretta, voi avete il contrario.
C'è anche l'opinione che si dovrebbe usare solo il prev_calcolato standard, senza variazioni. Se l'indicatore è pesante, limitate il numero di barre contate all'avvio. Il resto è ballare con il tamburello, il risultato è dubbio.
Ognuno decide da solo cosa è considerato corretto e cosa no. Per ZigZag la situazione di cui sopra è assolutamente micidiale. Per il MA, ci sarà una deviazione di 0,0001 nel suo valore...
L'opinione può spesso essere imposta (non sto dicendo che sia sbagliata).
In generale, suggerisco di chiudere qui la discussione. Il ragionamento teorico non vi porterà da nessuna parte.
Nel tester, l'ottimizzazione personalizzata dei calcoli dell'indicatore funzionerà perfettamente, ma nel terminale client può causare spiacevoli spostamenti della storia e calcoli errati.
A proposito, mt5 usa un controllo molto efficiente e istantaneo dell'integrità della base storica in rltime, che aumenta la frequenza di azzeramento di prev_counted. Se non si considera correttamente questo contatore, e ci si occupa delle proprie ottimizzazioni, si possono prendere un sacco di problemi nel lavoro reale. Gli aggiornamenti della cronologia dei minuti sono istantaneamente consegnati ai terminali dal server stesso.
Nel tester, l'ottimizzazione personalizzata dei calcoli dell'indicatore funzionerà perfettamente, ma nel terminale client, la storia si sposta e possono apparire calcoli errati.
È quello che voglio dire anch'io.
Forse penserete a come resettare prev_counted non a zero, ma al primo valore invariato?