Erros, bugs, perguntas - página 672
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
E as barras na janela são quanto?
O problema é que nenhuma memória está a ser libertada no terminal quando a TF é trocada. Start Task Manager, atirar o indicador no gráfico e ver a memória crescer. Depois mude para outra TF e verá a memória começar a crescer novamente. Mas logicamente, quando se muda para outra TF, os dados da TF anterior devem ser descarregados da memória. Como os dados do TF anterior não são apagados, a memória cresce até ser reiniciada e gerar um erro. Se remover o seu indicador do gráfico, verá que após um certo período de tempo a memória é apagada. Mas não é apagado enquanto o indicador estiver a funcionar.
A minha opinião: A solução para este problema é ServiceDec.
Obrigado, apagarei primeiro o indicador antes de mudar a TF. Além disso, reduzi as barras máximas na janela de 2000000 para 1000000, aparentemente MetaDriver quer dizer-me isso.
Até agora parece estar a funcionar.
Obrigado, vou apagar o indicador antes de trocar a TF primeiro. Além disso, reduzi o número máximo de barras na janela de 2000000 para 1000000, aparentemente o MetaDriver quer dizer-me isso.
Até agora parece estar a funcionar.
Porque precisa de 100.000? 100.000 é suficiente para mim. É isso que estou a tentar dizer-lhe.
Não limita os testes a qualquer profundidade de forma alguma.
Limita apenas (1) a visualização em janelas (2) o tamanho dos amortecedores indicadores.
Limitei longa e deliberadamente a "história visível". O resultado - não tenho problemas com a memória.
Porque é que precisa de um milhão? 100.000 é suficiente para mim, que é exactamente o que eu estava a sugerir.
Não limita, de forma alguma, os testes a qualquer profundidade.
Limita apenas (1) a visualização nas janelas (2) o tamanho dos amortecedores indicadores.
Restringi longa e deliberadamente a "história visível". O resultado é que não tenho problemas com a memória.
Sim, obrigado, vou utilizar ainda mais 108 pares na InstaForex, por isso não tenho problemas de memória.
Isso é um tema e tanto. Nos primeiros tempos do MT5 eu gritava que todos os indicadores deveriam ter um novo parâmetro padrão - o número de barras a calcular.
Caso contrário, obtemos o único limitador - TERMINAL_MAXBARS. Isto não é aceitável para Consultores Especialistas que analisam muitos símbolos em tempo real utilizando indicadores. Na maioria dos casos (99%) necessito em Expert Advisors de um número estritamente especificado dos últimos bares E TODOS. Tudo o resto é demasiado para mim. Claro que não só para mim...
Foi ignorado. Como resultado, transferi tais cálculos para o código do meu Conselheiro Especialista.
Ah sim! E o aparecimento de muitas manchas autoescritas. Alguns artigos inteligentes foram mesmo escritos e publicados, como por exemplo o seguinte:
Diminuir o consumo de memória para os indicadores auxiliares
Implementação de Indicadores como Classes por Exemplos de Zigzag e ATR
...
Se separar os indicadores apresentados regularmente e os indicadores calculados a curto prazo, será fácil obter divergências sobre os indicadores acumulados a longo prazo.
Também isto levará a muletas perigosas do nosso lado.
Uma boa maneira é definir 100000 barras por gráfico ou mudar para x64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
Em geral, nada muda. Os pedidos para a possibilidade de limitar o tamanho dos buffers indicadores em MQL5 são rejeitados, e se o seu programa começar a consumir uma enorme quantidade de memória devido aos muitos buffers indicadores utilizados - então chama-se "erro de programação".
"Em Expert Advisors, eu mais frequentemente (99%) preciso de um número estritamente específico de últimos bares E TODOS. Todas as coisas desnecessárias são demasiadas para mim. Não só eu, claro..." (с)
2) Os indicadores não podem ser contados com um breve histórico, porque são um recurso partilhado entre todos os processos (terminal, janelas, peritos). E há muitas regras de actualização, sincronização e recálculo do ambiente do mercado sobre indicadores.
3. Se separar os indicadores apresentados regularmente dos indicadores calculados a curto prazo, será fácil obter divergências sobre os indicadores cumulativos longos.
Também isto levará a muletas perigosas do nosso lado.
1. uma boa maneira é definir 100000 barras por gráfico ou mudar para x64.
1. Foi o que eu fiz. Ainda assim, é um compromisso incómodo. Idealmente, se eu tirar completamente da mente os problemas de desenvolvimento (puramente como utilizador) gostaria de ter uma escolha ao definir a duração do cálculo. Para o gráfico - o comprimento total (embora nem sempre, há excepções graves e grandes), para peritos - exactamente o tempo necessário. 3.
2. Como programador, compreendo as dificuldades e limitações simultâneas desta abordagem de, mas o consumo de memória é também um problema meu, e teimosamente não quer cair em segundo plano. Tenho uma sugestão-solução concreta - para considerar o período de cálculo (chamemos-lhe assim) como um parâmetro igual - não pior do que outros. Depois, dois indicadores com todos os parâmetros semelhantes, mas com um período de cálculo diferente, são simplesmente dois indicadores diferentes. Sim, teoricamente existem casos estúpidos de utilização que podem levar a despesas adicionais (se o utilizador multiplicar os períodos de cálculo), mas na prática é improvável. Se alguém quiser alinhar com isto, é culpado. Tal como agora TODOS os utilizadores são culpados de "terem aberto demasiados indicadores e não se importaram em reduzir TERMINAL_MAXBARS".
Sei que no cálculo da EMA são utilizadas todas as barras desde o início dos tempos, mas também sei que nos estocásticos, no RSI, e num número enorme(predominante) de outros indicadores, o cálculo é efectuado sobre um comprimento orgânico . E este conhecimento permite-me a flexibilidade para escolher o período de cálculo (MaxBar). Basta dar-me uma escolha.
Tanto quanto é agora culpa de TODOS os utilizadores por "abrirem demasiados indicadores e não terem o cuidado de reduzir TERMINAL_MAXBARS".
Sim, especialmente em condições de campeonato quando não se pode influenciar o tamanho do TERMINAL_MAXBARS de forma alguma.
1. Já o fiz. Ainda assim, é um compromisso incómodo. Idealmente, se nos afastarmos completamente das questões de desenvolvimento (puramente como utilizador), gostaria de ter uma escolha ao definir a duração do cálculo. Para o gráfico - o comprimento total (embora nem sempre, há excepções graves e grandes), para peritos - exactamente o tempo necessário. 3.
2. Como programador, compreendo as dificuldades e limitações simultâneas desta abordagem de, mas o consumo de memória é também um problema meu, e teimosamente não quer cair em segundo plano. Tenho uma sugestão-solução concreta - para considerar o período de cálculo (chamemos-lhe assim) como um parâmetro igual - não pior do que outros. Depois, dois indicadores com todos os parâmetros semelhantes, mas com um período de cálculo diferente, são simplesmente dois indicadores diferentes. Sim, teoricamente, existem variantes idiotas que podem levar a despesas adicionais (se o utilizador multiplica os períodos de cálculo), mas na prática é improvável. Se alguém quiser rever esta colisão - a culpa é sua. Tal como agora, TODOS os utilizadores são culpados de "terem aberto demasiados indicadores e não se terem preocupado em diminuir TERMINAL_MAXBARS".
Sei que no cálculo da EMA são utilizadas todas as barras desde o início dos tempos, mas também sei que nos estocásticos, o RSI, e um número enorme(predominante) de outros indicadores são calculados sobre um comprimento orgânico . E este conhecimento permite-me a flexibilidade para escolher o período de cálculo (MaxBar). Basta dar-me uma escolha.
A mensagem é clara.
Nós próprios queremos reduzir o consumo de recursos. Talvez a solução possa ser alguma função IndicatorMaxDepth(uint len) que actuará apenas em indicadores criados nesta EA.
Mas o problema é que durante os testes, os amortecedores de indicadores em modo de acumulação crescerão juntamente com a história e não haverá poupança. Recortar o histórico do indicador em tempo real, mantendo ao mesmo tempo a profundidade especificada é repleto de belas falhas e rebenta com a mente dos programadores, que contam/utilizam o sincronismo das barras do gráfico e do buffer do indicador.
Uma melhor opção é passar para x64.
Vamos rever o cache de indicadores, que agora utiliza o princípio da máxima eficiência versus o princípio da poupança de memória. Vamos tentar descarregar os indicadores que foram rejeitados imediatamente, em vez de os mantermos na memória durante algum tempo, como fazemos agora. Isto tornará possível chamar centenas de indicadores em fila com uma descarga directa através do IndicatorRelease.
Naturalmente, se alguém chamar centenas de indicadores no modo de varrimento do mercado sem os descarregar, então deve ir directamente para a versão de 64 bits + instalação de memória adicional.
Agora é estranho estar a fazer testes massivos sentado em x32. Qualquer computador x64 decente com 16GB de memória (sem ser fanático por placas gráficas e monitores) pode ser comprado por 15.000 rublos.