Características da linguagem mql5, subtilezas e técnicas - página 235
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
Se ele parar de funcionar, seria bom saber se está correto.
Se você criar ponteiros em vez de objetos, a versão antiga também funcionará.
Se ele parou de funcionar, é bom saber se é a coisa certa a fazer.
Se você criar ponteiros em vez de objetos, a versão antiga também funcionará.
Ótimo argumento e obrigado pela dica!
Sim, de fato, a situação é perfeitamente resolvida com um ponteiro:
Fãs de algoritmos rápidos. Aqueles que lutam por nanossegundos :)
Tarefa: encontrar o horário de abertura da barra de acordo com o horário e o TF fornecidos, quando se sabe que a barra existe nesse horário. Por exemplo, pelo tempo das posições de abertura e fechamento.
A maioria dos programadores usará uma combinação de iTime e iBarShift. Essa será a implementação mais lenta, especialmente porque requer um histórico atualizado de dados carregados ou matrizes combinadas. Além disso, essa abordagem pode gerar erros se o histórico necessário estiver faltando.
Programadores mais avançados resolverão esse problema com a estrutura MqlDateTime e a função TimeToStruct(). Essa não é uma solução ruim e é rápida o suficiente.
Mas há uma terceira solução, que é várias vezes mais produtiva do que a anterior:
A principal dificuldade desse algoritmo é calcular a hora do início do mês (destacada em verde). Há mágica acontecendo ali, que é o resultado de ir do simples para o complexo. O caminho inverso, de complexo para simples, será muito mais difícil de percorrer.
O ganho de desempenho também é proporcionado pelo algoritmo de obtenção de segundos em uma barra a partir do TF em vez da função PeriodSeconds() padrão - destacada em amarelo.
Anexei um script de teste que calcula e compara o desempenho de todos os três métodos:
A soma de verificação com o iBarShift não coincidirá , porque o iBarShift trabalha com barras reais. A soma de verificação coincidirá apenas nos períodos de tempo MN1 e W1, porque não há buracos no histórico dessas barras.
O desempenho será maior se você usar uma pequena etapa de tempo no loop (menos de um dia) quando o algoritmo começar a funcionar para salvar os cálculos anteriores:
Valores excessivos para o algoritmo via iBarShift (destacados em azul) são causados pela atual falta de histórico necessário ou de TFs calculados pela matriz, que inicia seu carregamento.
Após o carregamento, o resultado será o seguinte:
Fãs de algoritmos rápidos. Aqueles que lutam por nanossegundos :)
...😮😲😳🥴🤪
...
ah...
mmm....
oooh....
gkghm... Não achei que minha simples pergunta sairia assim.
Assim mesmo. Oh.
😮😲😳🥴🤪
...
ah...
mmm.
ohhhh....
ahem. Não achei que minha pergunta simples seria respondida dessa forma.
Ah.
Sim, Artem, você me enganou por um tempo.
Foi um interesse esportivo.
Espero que seja útil para alguém, inclusive para mim. :))
Sim, Artem, você me enganou por um tempo.
Trabalhei com interesse esportivo.
Espero que seja útil para alguém, e para mim, entre outros. :))
É claro que será. Ótimo. Mais uma vez, obrigado!
S.F. Isso me divertiu: "conta corretamente somente até 28.02.2100 !!!!".
O que faremos depois disso?
É claro que será útil. Muito bom. Mais uma vez, obrigado!
S.F. Isso me divertiu: "counts correctly only until 28.02.2100 !!!!".
O que faremos depois disso?
haha.
Duvido que esse algoritmo seja solicitado daqui a 75 anos. Os computadores quânticos provavelmente já estarão dominando o mundo, com uma programação completamente diferente.
Para ser honesto, foi preguiça de levar em conta o calendário gregoriano. 2000 era um ano de alto risco, 2100 não é mais.
haha.
Duvido que esse algoritmo seja solicitado daqui a 75 anos. Os computadores quânticos provavelmente já dominarão o mundo, com uma programação completamente diferente.
Para ser honesto, foi preguiçoso levar em conta o calendário gregoriano completamente. 2000 era um ano de alto risco, 2100 não é mais.
Para o MN, você pode usar uma matriz pré-calculada, não há quase nada nela
Ln2(12 meses * cem anos)... 11 if`s e comparações na pesquisa binária, mas sem outros cálculos.
Você pode usar uma matriz pré-calculada para o MN, pois quase não há dados lá.
Ln2(12 meses * cem anos)... 11 if`s e comparações na pesquisa binária, mas sem outros cálculos.
Você pode usar uma matriz pré-calculada para o MN, pois quase não há dados lá.
Ln2(12 meses * cem anos)... 11 if`s e comparações na pesquisa binária, mas sem outros cálculos.
Ah, eu li errado no início.
Não, você está errado. O aumento de desempenho não funcionará. Você ainda ficará preso nos cálculos. E o acesso aos elementos da matriz torna o algoritmo muito mais lento.