Indicadores: Regressão Linear
Sua versão parece ser a mesma matemática que:
https://www.mql5.com/pt/code/429
Executei ambas por um período de 20 anos no NZDUSD,D1 e elas se alinham exatamente.
Diferenças:
- A sua codifica a inclinação com cores.
-
- O seu tem a capacidade de "deslocar" barras e pontos.
-
- O seu tem a capacidade de mudar o APPLIED_PRICE.
Sua versão parece ser a mesma matemática que:
https://www.mql5.com/pt/code/429
Executei ambas por um período de 20 anos no NZDUSD, D1, e elas se alinham exatamente.
Diferenças:
- O seu codifica a inclinação com cores.
-
- O seu tem a capacidade de "deslocar" barras e pontos.
-
- O seu tem a capacidade de mudar o APPLIED_PRICE.
Esse método (o 3*lwma-2*sma) é explicado no link da postagem (verifique esse link também, este link https://www.mql5.com/pt/articles/270) e existe há muito, muito tempo e foi apresentado pela primeira vez neste fórum (francamente, não me lembro exatamente quem apresentou esse algoritmo pela primeira vez, acho que foi "mathemat", mas não acredite em minha palavra).
Quanto ao código: o código que postei é um código de passagem única (por isso é rápido) e não tem nada em comum com o código de Nikolays, que você também pode verificar por si mesmo. O objetivo da postagem foi publicar a maneira rápida (rápida do ponto de vista da CPU) que é flexível o suficiente para ser usada em qualquer tipo de código. E, de acordo com todos os testes, ele é rápido o suficiente para ser usado no metatrader 5 e também é flexível o suficiente
Tudo de bom
- www.mql5.com
Quanto ao código: o código que publiquei é um código de passagem única (por isso é rápido) e não tem nada em comum com o código Nikolays, que você também pode verificar por si mesmo. O objetivo da postagem foi publicar a maneira rápida (rápida do ponto de vista da CPU) que é flexível o suficiente para ser usada em qualquer tipo de código. E, de acordo com todos os testes, ele é rápido o suficiente para ser usado no Metatrader 5 e também é flexível o suficiente
OK. Rápido é bom. Na verdade, não comparei o código, apenas os resultados, por isso disse erroneamente a "mesma matemática".
Estou usando o código Nikolays há algum tempo e, sim, ele é o indicador mais lento que tenho. Rápido é bom.
Continue com seu bom trabalho!
Boa implementação. Parabéns.
- Qual é o objetivo disso? Ofuscação? :-D
#define ¤ instance #define _functionInstances 1
- Há algum motivo para não usar >= no código abaixo?)
if(i>period)
Bela implementação. Parabéns.
- Qual é o objetivo disso? Ofuscação? :-D
- Há alguma razão para não usar >= no código abaixo?)
Sem ofuscação:
De "¤": simplesmente gosto mais dessa forma (uma convenção que uso para mim mesmo - para mim, o código é mais legível assim - uma olhada no código da função e posso ver exatamente o que é usado onde). Eu poderia usar isso diretamente como um nome de parâmetro, mas seria "muito enigmático" quando eu digitasse o nome da função e quando o preenchimento automático mostrasse os nomes dos parâmetros
De "_functionInstances": como será traduzida em uma diretiva de tempo de compilação, ela serve para o planejamento - se eu quiser usar mais de uma instância de função (ou seja, parâmetros diferentes por qualquer motivo), simplesmente altero o valor definido e, em seguida, ele é compilado para o número correto de alocação de matriz a ser usado com parâmetros diferentes - e não preciso pensar se o alterei em todos os locais do código onde isso precisa ser feito. E, por ser uma diretriz de tempo do compilador, não há custo de tempo de execução
Quanto a ">=", há dois motivos:
- uma condição a menos (que é executada em toda e qualquer chamada de função), a menos que o compilador a traduza para outra coisa (o ">="), mas, a julgar pelos resultados do profiler, ele está usando isso como 2 condições, e não 1, nesse caso
- isso não prejudica em nada a velocidade final e garante que tudo esteja devidamente configurado para processamento posterior (um processamento extra de somas iniciais garante isso)
Sem ofuscação:
De "¤": simplesmente gosto mais dessa forma (uma convenção que uso para mim mesmo - para mim, o código é mais legível dessa forma - uma olhada no código da função e posso ver exatamente o que é usado onde). Eu poderia usar isso diretamente como um nome de parâmetro, mas seria "muito enigmático" quando eu digitasse o nome da função e quando o preenchimento automático mostrasse os nomes dos parâmetros
De "_functionInstances": como será traduzida em uma diretiva de tempo de compilação, ela serve para o planejamento - se eu quiser usar mais de uma instância de função (ou seja, parâmetros diferentes por qualquer motivo), simplesmente altero o valor definido e, em seguida, ele é compilado para o número correto de alocação de matriz a ser usado com parâmetros diferentes - e não preciso pensar se o alterei em todos os locais do código onde isso precisa ser feito. E, sendo uma diretriz de tempo do compilador, não há custo de tempo de execução
Quanto ao ">=", há dois motivos:
- uma condição a menos (que é executada em toda e qualquer chamada de função), a menos que o compilador a traduza para outra coisa (o ">="), mas, a julgar pelos resultados do profiler, ele está usando isso como 2 condições, e não 1, nesse caso
- Isso não prejudica em nada a velocidade final e garante que tudo esteja configurado corretamente para o processamento posterior (um processamento extra de somas iniciais garante isso).
É claro que ">" está funcionando. Minha observação foi apenas para dizer que você está perdendo "1 loop", é claro que isso não altera muito a velocidade final. "Ter certeza disso" parece mais uma superstição ;-)
Alain Verleyen:
You should try an OOP approach.
...
Você quer dizer algo assim :)
É um pouco (mas apenas um pouco) mais lento - estou usando a abordagem de buffer em anel no modo OOP e isso adiciona uma instrução mod a todo o cálculo, é por isso. Acho que o postado também será suficientemente bom :)
Você quer dizer algo assim :)
É um pouco (mas apenas um pouco) mais lento - estou usando a abordagem de buffer em anel no modo OOP e isso adiciona uma instrução mod a todo o cálculo, por isso. Acho que o postado também será suficientemente bom :)
Sim, é sempre um compromisso entre velocidade e memória.
E, é claro, a principal vantagem da OOP é a manutenção e a reutilização, não a velocidade.
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Regressão Linear:
Regressão Linear
Autor: Mladen Rakic