![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
2. flutuador estático protegido fMicron = 0,000075f; // Coef usado quando comparamos dois flutuadores
3. Construtor de Base Indicador:
4. preço base:
6. Eu tenho a ponte NET <-> MT funcionando. Seu tempo para fazer comércio de FSB através da MT. Claro que será apenas para contas demo até se tornarem "sólidas como rocha".
Como eu acho que o indicador Aroon usa apenas: bIsDescreteValues = true;
Sobre a RSI, lembro-me que estava me perguntando sobre a fórmula. Foi há 5-6 anos. Acho que usei esta fórmula de um popular livro de AT. Não lembro exatamente qual deles.
"Use valor de barra anterior"
Pessoalmente acho que esta é uma das características mais importantes da FSB.
Para ver os valores indicadores em sua precisão total, pressione F12 na janela do gráfico.
Outra opção é usar o "Command Console". ind xxxx mostra os indicadores para a barra xxxx
Eu não me aprofundo nas fórmulas de MT. Provavelmente eles não são muito diferentes. Aqui estão os FSB RSI e MT RSI padrão.
___________________--
Editar:
Eu tentei calcular a LER sem este alisamento adicional:
Mas neste caso, o valor RSI para 2009.3.24 salta para 74.800.
----------------------
Obrigado Stellarator pelas boas palavras!
Eu não vou abandonar o Forex Strategy Builder, e apenas por causa de pessoas como você. Mesmo em oposição, estou aberto à discussão, a fim de tornar a FSb mais robusta e amigável ao usuário.
Nessa direção, acho que posso acrescentar indicadores MT na FSB. Algo como modo de compatibilidade MT:)
MT_MACD, MT_RSI, ... Estes devem estar com os mesmos parâmetros que os da norma MT.
Temos que encontrar uma solução para os pontos de abertura e fechamento de bares de entrada/saída. Eles são vitais para a integração FSB -> MT.
.........Combiná-los (dois amortecedores) em um só (estava pensando... Pode haver não apenas 1/0 (que pode ser transformado em uma bitmask), mas também etiquetas de preço). Muito provavelmente, terei de fazer algo com os próprios valores indicadores. Veremos... Enquanto eu vou...
Por que não pode funcionar(?).
Há muito tempo eu venho usando uma única chamada icustom para obter vários valores de diferentes buffers de indicadores, é um desperdício demais usar esta função várias vezes no código, especialmente durante a otimização, e mesmo com indicadores "pesados". Na verdade, tudo o que precisamos (no máximo) é obter a direção comercial e o nível de SL & TP..... o problema é resolvido por uma simples aritmética.
Aqui está um fragmento de código indicador com apenas um buffer adicional (Sinal):
E aqui está a conversão inversa no código do Expert Advisor:
Assim, obtemos 3 valores do indicador (direção, TP e SL) com uma única chamada do indicador. Os resultados obtidos podem ser ainda mais manipulados como você quiser :)
Espero que você entenda o princípio.
Bom dia a todos!
Miroslav_Popov писал(а) >>
1. Posso reescrever os indicadores a fim de substituir a bóia pelo dobro.
Miroslav - é importante! Já dei algumas das razões em meus postos. Mas também estou bem ciente da mão-de-obra envolvida... E que agora (muito provavelmente) você está trabalhando na ponte que está procurando ou algo substancial.
Mas o tempo tem que ser encontrado. Minha previsão não é mais do que um número de horas (dentro de um dia). Porque não se trata apenas de substituir uma pela outra ao declarar variáveis (o que também implicará pelo menos uma verificação e correção visual "para beleza" (onde as variáveis são descritas com tabulações, por exemplo, etc.) :) - embora não se trate de uma questão de princípio).
Em primeiro lugar, pode haver casos em que a bóia é usada propositadamente (para forçar uma diminuição da precisão). Você precisa ver o código inteiro aqui.
Em segundo lugar, há uma questão de comparar tais números ("novos") e seu mapeamento com o FSB (sobre isso, na seção 2 abaixo).
Mais curto - precisaremos analisar cuidadosamente todos os códigos e pelo menos pensar em possíveis inconvenientes associados à transição da matemática real para a matemática dupla.
Miroslav_Popov escreveu (a) >>.
2. flutuador estático protegido fMicron = 0,000075f; // Coef usado quando comparamos dois flutuadores
(e abaixo):
Para ver os valores indicadores em sua prensa de precisão total, pressione F12 na janela do gráfico.
E este é um dos problemas! Por que 0,000075? E não 0,00005? Ou 0,000001? (como eu fiz).
Um problema prolongado (para os interessados) e uma pergunta:
Como você sabe, a comparação de dois números reais para a igualdade nunca deve ser feita por tais construções:
Isto porque após os resultados de alguns cálculos (especialmente variações na multiplicação/divisão), os valores destas variáveis podem ser visualmente semelhantes (1,0 e 1,0, por exemplo), mas na verdade NÃO são os mesmos. (1.000001 e 1.000000, de fato). Esta propriedade deriva de alguma discrepância na representação de números reais em computadores e com alguma discrepância (finita) de computação (precisão). Em geral, a comparação para a igualdade é feita por variações sobre um tema clássico (que, a propósito, Miroslav utiliza):
Esta é a comparação "clássica" de dois números reais para igualdade com alguma precisão finita, definida pelo fMicron, neste caso.
E aqui reside um dos problemas potenciais. Como, quem e para que casos deve determinar o valor deste mesmo fMicron? É sempre uma boa constante, como a de Miroslav (a questão de qual valor ainda está em discussão, também)?
Em geral, se não para acrescentar intrigas - sou a favor da seguinte teoria:
1. Em geral, existem dois tipos de comparação de tais variáveis, para igualdade e para desigualdade (<, >).
2. Há dois tipos de variáveis em si: variáveis com precisão fixa garantida (preços, lotes, etc.) e valores abstratos sem precisão definida (como valores indicadores).
Para desigualdade, as variáveis (de qualquer tipo) são comparadas (em geral) "cabeça a cabeça" (se (Valor1 < Valor2) { ...})). Se for necessário limitar a precisão (o que é bastante raro), você pode usar uma construção como a de Miroslav:
4. para a igualdade, porém, o problema é (geralmente) abordado de forma diferente, dependendo dos dados em questão.
4.1 Se precisarmos comparar dois números com precisão fixa (por exemplo, dois valores de preço para decidir se devemos ou não modificar o pedido (para evitar obter um "Sem Resultado"), geralmente o fazemos dessa forma (também "clássico"):
A função é redundante em nosso caso, mas não é essa a questão. A construção chave nela é Ponto / 2.0 . É este fMicron que nos dá a precisão de cálculo necessária, correta e suficiente... NESTE CASO EM PARTICULAR! Quando dois preços são comparados (com os mesmos Dígitos e, consequentemente, Ponto ). ou seja, no caso de (Ponto = 0,0001), por exemplo
fMicron = 0,00005
e comparando 1,2345 (preço do pedido) com 1,23451 (valor indicador) - obtemos igualdade, e 1,2345 com 1,23456 - desigualdade... Adivinhe o que acontece no último caso quando fMicron = 0,000075? ;) Você poderia, é claro, pré-normalizar as variáveis com uma (menor) precisão. Mas esse não é o nosso método :D...
Mais uma vez - a escolha deste parâmetro é importante, e para cada caso "um pouco único" :)1
Eu sugeriria o seguinte paradigma:
1. As variáveis de precisão fixa são comparadas com um valor fMicron calculado (Ponto / 2, por exemplo, para o caso do preço)
2. Valores de indicadores e outras coisas similares "infinitamente precisos" :), são comparados à constante fMicron igual ao valor mínimo de Ponto, instrumentos usados, divididos por 10. Isto é, no caso de instrumentos em que Dígitos não excedam 4 - fMicron = 0,00001, se Dígitos = 5, fMicron = 0,000001 e de forma semelhante.
Miroslav - opinião de especialista necessária :)?!
Agora uma pergunta para o público:
PORQUÊ em todos os tipos de DataWindow (em MT ou em FSB (Gráficos Indicadores)) - os valores indicadores são sempre mostrados com uma precisão fixa (Dígitos = 4)? Por que não 3 casas decimais? Ou 5, 6, 7, ...? :)?! Não, realmente?
Miroslav tinha uma "característica oculta? ;)) - Quero dizer F12! E na MT o que pressionar?
E em geral, bem, quem definiu esta constante? (4 casas decimais).
Meu palpite é que está quase diretamente relacionado à dimensão das cotações recebidas (1,2345), para a maioria dos instrumentos (alguém acabou de preenchê-lo). Mas não é um segredo que muitas corretoras passam para valores maiores (5 por exemplo). Então, por que não mostrar os valores indicadores na dimensionalidade, que coincide com a dimensão das aspas do instrumento (Dígitos)?
Ou talvez eu não "consiga" algo em princípio no assunto (por favor - alguém explique, talvez seja "necessário" porque...)!
Miroslav_Popov escreveu (a) >>.
3. Construtor de Base Indicador:
4. preço base:
Miroslav, entendi muito bem o código na página Fonte :). Entendo bem o que faz a flutuação estática protegida[] Price( BasePrice price). Se isto é uma dica sobre a inabilidade de meu código - respondo que intencionalmente me recusei a usar buffers adicionais para armazenamento (no caso geral - ou cópias de buffers de preço ou cópias calculadas dos mesmos (Típico, etc.)). E o espaço é economizado, e onde há todos os tipos de Typicals, eles SEMPRE precisam ser calculados!
Aqui precisamos mencionar a diferença crítica na abordagem de cálculo dos valores indicadores em FSB e MT:
1. Primeiro, pelo menos no momento - as citações que são carregadas em FSB são estáticas, uma vez as carregou, calculou UMA VEZ os valores indicadores necessários para toda a gama de barras e depois apenas "aciona" por elas, emulando o comportamento do robô comercial. Mais uma vez, os valores indicadores são calculados apenas uma vez, ANTES de executar a virtualização do robô comercial. Isto, em particular, explica a rapidez da emulação das transações comerciais. Mas as citações em MT vêm o tempo todo e o testador de estratégia nativo não vê o futuro, ou seja, temos que calcular os valores do indicador a cada vez. E se eu usar apenas a abordagem de Miroslav (cálculo de buffer inteiro)... Vou ser jogado com ovos podres :). Portanto, é dada atenção especial ao uso do IndicatorCounted()! Os indicadores são calculados com quase a máxima velocidade possível em cada caso (se todas as barras precisarem ser contadas, ou apenas uma). Em algum lugar, algumas coisas ainda podem ser otimizadas, mas a seu bel-prazer...
2. Portanto, cada vez (quando um novo tick chega), é redundante gerar valores de preço em buffers adicionais. Você tem que calculá-las todas de qualquer maneira, então deixe as funções (a mesma MovingAverage, etc.) fazerem elas mesmas. Ele economiza espaço, simplifica a lógica (não há necessidade de analisar sempre, quais barras devem ser recalculadas nestes amortecedores), e economiza velocidade (mesmo em algum lugar mais alto, no caso geral). "Parece-me que sim" (c) Winnie the Pooh
Se vamos discutir novamente minhas conversões de indicadores, talvez o importante seja que eu preserve completamente a lógica das funções (e dos próprios indicadores), mas a modifique ligeiramente para um caso específico de uso em MT. Eu também guardo a ordem e os nomes dos parâmetros para controlar o próprio indicador.
Pessoal, olhem o código fonte, no entanto. Eu tentei fazer "nice" :).
A idéia final da minha conversão é a seguinte. Por exemplo, temos um Ponto de Abertura da Posição e três indicadores para lógica adicional. Aqui está como será o código para a colocação de pedidos (bem, grosso modo, é claro):
Algo parecido com isto. Você alimenta iCustom com seus valores de parâmetro e espera até que todos eles dêem um sinal. Isso é tudo. Não há análise dos próprios valores indicadores. Para quê?
Parece legal... ou não :)?
Sobre os indicadores:
Sobre (Aroon e bIsDescreteValues = verdadeiro;) levado em conta.
Sobre a RSI...
Miroslav - a construção que você está procurando o confundiu :). Não seja preguiçoso para colocar comentários mais uma vez e use o indicador CORRETAMENTE TRABALHADO para obter valores "correspondentes" :). Deixe-me lembrá-lo - a fórmula clássica para calcular a LER é baseada na variedade exponencial da MA (alisada, especificamente). Portanto, especifique este modo de alisamento (alisado) nos parâmetros indicadores... e você ficará "agradavelmente surpreso" com os resultados :) (por padrão, eu lembro, Simple é usado, o que dá uma discrepância com o clássico)! Eu mesmo não posso fazer o procedimento acima - mas estou 100% certo do que estou dizendo. Convença-me :)?
Como resultado dos testes, temos a seguinte sugestão, para remover o código requerido e fazer o valor padrão do parâmetro maMethod no Smoothed em todos os indicadores, que usam RSI (e o próprio RSI, respectivamente). Que, por padrão, os usuários não teriam tais perguntas. Mas ao fazer isso, faremos a seleção deste parâmetro nos indicadores TRABALHÁVEL! (por exemplo, converti o oscilador RSI MA, que, baseado no resultado dos cálculos do RSI, também, com o comportamento atual do próprio RSI - não importa o que está especificado no parâmetro apropriado)
"Use valor de barra anterior"
Pessoalmente acho que esta é uma das características mais importantes da FSB.
OH, SIM!
É realmente uma das características mais importantes da FSB. E eu tentei prestar a devida atenção ao teste da correção da lógica dos indicadores, considerando esta característica.
Obrigado pelo código que mostra o cálculo do valor "padrão"! Levarão isso em conta...
Por que não pode funcionar(?).
Há muito tempo eu venho usando uma única chamada de icustom para obter vários valores de diferentes buffers indicadores, é um desperdício demais usar esta função várias vezes no código, especialmente durante a otimização, e mesmo com índices "pesados". Na verdade, tudo o que precisamos (no máximo) é obter uma direção comercial e níveis SL & TP..... o problema é resolvido por uma simples aritmética.
...
O princípio, espero, é claro.
), você o terá (intencionalmente fiz minha declaração mais grosseira), sei do problema de colapso de valores em um parâmetro :). E obrigado pelo código citado (pergunta rápida - já houve diferenças nos valores originais e "posteriormente expandidos"? tudo o mesmo duplo...)
A questão-chave é... É NECESSÁRIO, NESTE CASO PARTICULAR.
Pode haver duas razões:
1. 1... O propósito da utilização de amortecedores adicionais (é importante para mim) - os indicadores não têm tantos deles. Tenho o suficiente deles MAS Por enquanto (parece que já preciso usar Ishimoku - e tudo se tornará claro :)))
2. A velocidade de chamar o indicador a partir de seu código (seu exemplo). Minha resposta é: Não é essencial! Declaro-o com toda a responsabilidade. Motivação:
A cada novo tick - você terá que (terá que) olhar para o indicador de qualquer maneira. Certo? (por exemplo - para tomar preços ou algo mais) Mesmo que não a cada tique, mas quando você precisar. A principal dica, talvez, é que uma chamada múltipla de iCustom dentro de uma iteração da EA leva a um recálculo múltiplo do indicador? Sou obrigado a dissuadi-la! O ponto-chave é "um limite de uma iteração do Expert Advisor". Portanto, dentro desta faixa, o indicador é calculado UMA VEZ (na primeira chamada)! Declaro isto com 100% de confiança. Todas as chamadas subseqüentes não começam() de forma alguma, mas apenas tomam os valores necessários dos amortecedores necessários. A condição é 100% se os parâmetros de entrada permanecerem inalterados (exceto para o buffer e o offset). A regra é válida para cálculos dentro dos limites de uma ferramenta. Mas eu acho que o princípio se aplica mesmo quando o iCustom se refere a outras TFs e ferramentas.
De qualquer forma, vou dar uma olhada no Ishimoku esta noite e decidir com certeza se vou usar dois amortecedores para a lógica... ou um :)
De qualquer forma, nos vemos todos hoje à noite (foram trabalhar).
Sobre o problema.
Vou pensar sobre isso.
Mas o mais provável (dada a falta de sinais da MT sobre este tópico) - o código acima (modelo na página anterior) é mais ou menos ótimo (pode precisar de um pouco de afinação... Vou tentar "aprofundar" o problema à noite)