Um pouco surpreendido :) Pensei em partilhar e fazer uma pergunta NÃO retórica. - página 7
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
A questão não está no testador, outra vez! Não no testador, mas em condições reais onde a história é descarregada e ocorrem falhas de ligação.
Se, em condições reais, ocorrer um reset e um recálculo do indicador, não há nada de errado com isto.
Surgiu outra questão. A maioria das pessoas não tem nada para fazer aqui? Estão a reescrever a funcionalidade padrão do terminal para mql5. Talvez, alguém escreva um terminal inteiro em mql5 muito em breve.
Se, em condições reais, ocorrer um reset e um recálculo do indicador, não há nada de errado com isto.
Surgiu outra questão. A maioria das pessoas não tem nada para fazer aqui? Estão a reescrever a funcionalidade padrão do terminal para mql5. Talvez, alguém escreva um terminal inteiro em mql5 muito em breve.
É claro que não é assim tão mau. Quando se tem 100 ZUP num terminal (só por exemplo), não é um problema...
Surgiu a mesma questão. Toda a gente gosta de falar apenas do seu ponto de vista, porquê?
Há mais do que um indicador utilizado aqui:
A influência da função padrão IndicatorCount é simplesmente mortal para ela (verifiquei-a pessoalmente). E quando implementadas como aulas, as descontinuidades de comunicação são mesmo roxas
P.S. Para um MA não é, naturalmente, um grande problema
Claro que não é nada de especial. Quando se tem 100 ZUPs num terminal (só para lhe dar um exemplo), não é nada de mais...
Surgiu a mesma questão. Todos gostam de discutir apenas a partir da sua própria torre sineira, porquê?
Alguém quer sempre mais do que pode aguentar. Mas porquê tantos?
O problema de reiniciar o indicador pode ser resolvido com cinco linhas de código. Lembre-se do tempo da primeira barra, se tiver mudado, é necessário um recálculo completo. Armazenar o número da última barra, no caso de um reset continuar o recálculo a partir desta barra e ponto final.
Não tenho medo de dizer da minha própria torre sineira, sem confirmar nada com argumentos de que a minha torre sineira está correcta, paragem total.
Alguém quer sempre mais do que pode aguentar. Mas porquê tanto?
Pode contornar o problema de reiniciar o indicador com cinco linhas de código. Lembre-se do tempo da primeira barra, se tiver mudado, é necessário um recálculo completo. Armazenar o número da última barra, no caso de um reset continuar o recálculo a partir desta barra e ponto final.
Não tenho medo de dizer da minha torre sineira, sem confirmar nada com argumentos de que a minha torre sineira está correcta e é tudo.
Não sejas tão presunçoso. Aprender não só a ouvir, mas também a ouvir os outros.
A história pode mudar no meio e a sua abordagem irá para os farrapos. Pergunte a Renat sobre isto.
O erro em IndicatorCounted() em MT4, que só agora foi corrigido com a minha dica, enviou até indicadores correctamente escritos para a sucata (especialmente ZigZag em pequenas TFs).
Para não mencionar a sua abordagem a este caso....
Nem sequer vai discutir consigo porque está completamente errado nesta situação.
Não tenha tanta autoconfiança em si mesmo. Aprender não só a ouvir, mas também a ouvir os outros.
A história pode mudar no meio e a sua abordagem irá entrar em farrapos. Pergunte a Renat sobre isto.
O erro em IndicatorCounted() em MT4, que só agora foi corrigido com a minha dica, enviou até indicadores correctamente escritos para o lixo (especialmente ZigZag em pequena TF).
Nem sequer vou discutir consigo, porque está completamente enganado nesta situação.
Adicionar mais algumas verificações no momento do reset, se o número de barras aumentou, mas o tempo da barra não mudou ou se foi adicionada mais do que uma barra.
Quanto a ser demasiado confiante, é o contrário, você é o demasiado confiante, você é o terceiro que pensa que ele é mais fixe que o MQ.
Adicionar mais algumas verificações no momento do reset, se o número de barras aumentou mas o tempo da barra não mudou ou se foi adicionada mais do que uma barra.
Sobre a autoconfiança, é o contrário, são todos os excessivamente confiantes, já o terceiro que se acha mais fixe que o MQ.
Que tipo de verificações? Situação. Um novo tick aparece no antigo bar. Nada mudou - nem o número total de bares, nem o último bar aberto, mas ao mesmo tempo
as últimas 30 barras foram reescritas (os seus preços de abertura/fecho, máximo, mínimo, mudaram, embora de forma insignificante).
O que vai fazer com o seu algoritmo? Nada! Simplesmente não vai funcionar nesta situação. E o indicador será completamente incorrecto!
O que estava no MT4 antes da última construção - em 70% dos casos não reagiria a esta situação.
Mas depois da análise deste problema eles corrigiram-no. Stingo escreveu sobre ele: https://www.mql5.com/ru/forum/132422
Acho que não sou mais fixe do que outros. Pelo contrário, ajudo activamente a corrigir todos os bugs em MT4 e MT5 - perguntar a qualquer representante da MetaQuotes.
E o facto de alguns mecanismos não serem implementados da forma que se pretende - não se pode agradar a todos....
É uma questão interessante quanto ao que é correcto, o que foi antes ou o que foi depois da correcção da história. Se não se voltar às barras corrigidas, o indicador continuará a funcionar como se o histórico não tivesse sido corrigido. Hrenfx tem exactamente esta atitude, ele considera a velha história correcta, você tem o oposto.
Há também a opinião de que só se deve utilizar o cálculo prévio regular, sem variações. Se o indicador for pesado, limitar o número de barras contadas no arranque. O resto é uma dança de tamborim, o resultado é duvidoso.
É uma questão interessante quanto ao que é correcto, o que foi antes ou o que foi depois da correcção da história. Se não se voltar às barras corrigidas, o indicador continuará a funcionar como se o histórico não tivesse sido corrigido. Hrenfx tem exactamente esta atitude, ele considera a velha história correcta, você tem o oposto.
Há também a opinião de que só se deve utilizar o cálculo prévio regular, invariavelmente. Se o indicador for pesado, limitar o número de barras contadas no arranque. O resto é dançar com tamborim, o resultado é duvidoso.
Cada um decide por si próprio o que é considerado correcto e o que não é. Para o ZigZag a situação acima referida é totalmente fatal. Para MA, haverá um desvio de 0,0001 no seu valor.
A opinião pode muitas vezes ser imposta (não estou a dizer que está errada).
Em geral, sugiro que se encerre aqui a discussão. O raciocínio teórico não o levará a lado nenhum.
No testador, a optimização personalizada dos cálculos dos indicadores funcionará perfeitamente, mas no terminal do cliente pode causar mudanças desagradáveis do histórico e cálculos incorrectos.
A propósito, o mt5 utiliza um controlo muito eficaz e instantâneo da integridade histórica da base em tempo rl, o que aumenta a frequência de reinicialização pré_contada a zero. Se não considerar este contador correctamente, e lidar com as suas próprias optimizações, pode apanhar muitos problemas no trabalho real. As actualizações do histórico dos minutos são imediatamente entregues nos terminais pelo próprio servidor.
No testador, a optimização personalizada dos cálculos dos indicadores funcionará perfeitamente, mas no terminal do cliente, os turnos do histórico e os cálculos incorrectos podem aparecer.
É a isso que me refiro também.
Talvez pense em como reiniciar prev_contado não para zero, mas para o primeiro valor inalterado?