Comparação da média móvel (e quaisquer outros indicadores) e erro - página 2
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
Isto não tem nada a ver com o mql em princípio. Vamos pegar uma linguagem de programação abstrata. Neste exemplo particular que dei, o principal problema é que os valores da diferença de muwings em uma mesma barra não são iguais (2e-16 no primeiro cálculo e exatamente 0 no segundo). Neste caso, esta interseção não pode ser determinada de forma alguma. Se voltarmos ao mql, a normalização implica em arredondar o número(ou melhor, simplesmente deixar cair todos os números após um certo sinal, como no piso de função Sish, mas a uma certa casa decimal). Então, como posso saber qual dígito normalizar? Se o dígito errado for escolhido, todos os valores podem SEMPRE ser arredondados para exatamente 0. Portanto, a normalização é perigosa aqui e geralmente não resolve o problema.
Quanto ao que Alexey Lebedev escreveu. Sim, eu estava pensando nesta direção. Mas se compararmos as duas diferenças por mais ou igual a 0, há uma probabilidade de obter um sinal falso (por exemplo, a situação teoricamente possível quando os muvings entre barras vizinhas têm exatamente os mesmos valores). Então sua diferença não muda o sinal (não há crossover), mas o sinal para o crossover será determinado programmaticamente. Você poderia colocar apenas uma comparação em mais ou igual, como você sugeriu. Mas então o problema é que no cálculo nesta situação primeiro não será igual a 0 (2e-16), e na próxima barra será exatamente 0, mas será uma comparação rigorosa.
É importante entender porque a mesma diferença, quando calculada em barras diferentes, NÃO produz o mesmo resultado. Se o resultado fosse o mesmo, o problema seria sempre resolvido com a introdução de uma comparação não restritiva.
Quando se normaliza, sim, há arredondamento para uma determinada casa decimal. Não descartando todos os números após um certo sinal, mas arredondando.
Se eu o entendo exatamente nesse contexto (eu levo tanto seu primeiro posto com captura de tela quanto o segundo), várias experiências com esse método, inclusive levando em conta o DoubleToString ao imprimir, eu suponho, ainda podem ajudá-lo. Rosomah o mencionou diante de mim para você.
Incluindo, ajude a definir para si mesmo qual valor normalizar em qualquer tarefa, ou se em alguns casos a normalização é necessária (em casos de dúvidas, aplicação ou não aplicação em conjunto de fatores relacionados, inclusive, esse programa então pode ser aplicado em diferentes CD e, conseqüentemente, os valores de cálculo obtidos podem ser diferentes).
Do meu ponto de vista, o perigo de obter sinais que podem ser considerados falsos, dependendo da tarefa em mãos, pode ser apenas quando a normalização não é aplicada (ou quando não há comparação de primeira mão devido a algum valor pequeno), onde não seria um problema.
Além disso, se a DoubleToString não for aplicada à impressão, pode simplesmente haver uma concepção errônea de que a mesma diferença ou os mesmos valores não são o mesmo resultado.
/* Só por precaução, gostaria de mencionar novamente que ao imprimir números do tipo duplo, é necessário usar o DoubleToString, pois a saída de impressão converte um valor numérico em um valor de texto. Assim, se esta função não for utilizada, você poderá ver erros que não estão realmente presentes.
O número de casas decimais nesta função, naturalmente, com não menos casas decimais do que os valores normalizados. E para valores não-normalizados, o número de casas decimais é maior.
O cálculo da função iMA é muito provavelmente otimizado. Primeiro valor = soma(fechamento)/N, segundo = valor anterior de MA+(novo fechamento fechado)/N.
Então iMAs em geral para a mesma barra podem dar valores diferentes dos dois muwings em horários de chamada diferentes?
Quando se normaliza, sim, há arredondamento para a casa decimal especificada. É arredondamento, não descartando todos os números após uma certa casa decimal.
Se eu o entendo exatamente nesse contexto, o que você quer dizer (levo em conta tanto seu primeiro post com captura de tela quanto o segundo post), então várias experiências com esse método, inclusive levando em conta o DoubleToString ao imprimir, acredito, ainda podem ajudá-lo.
Incluindo, ajude a definir para si mesmo qual valor normalizar em qualquer tarefa, ou se a normalização é necessária em alguns casos (em caso de dúvida, usar ou não usar em conjunto de fatores de acompanhamento, incluindo aquele programa então pode ser aplicado em diferentes DC e, respectivamente, os valores de cálculo obtidos podem ser diferentes).
Do meu ponto de vista, o perigo de obter sinais que poderiam ser considerados falsos, dependendo da tarefa em mãos, pode ser apenas quando a normalização não é aplicada (ou quando o primeiro método não é comparado devido a algum valor pequeno) onde não faria mal.
Além disso, se o DoubleToString não for aplicado na impressão, pode simplesmente haver uma concepção errônea de que a mesma diferença ou os mesmos valores não são o mesmo resultado.
/* Só por precaução, gostaria de mencionar novamente que ao imprimir números do tipo duplo, é necessário usar DoubleToString, pois a saída converte um valor numérico em um valor de texto. Assim, quando esta função não é utilizada, podem ocorrer os seguintes erros
O número de casas decimais nesta função, naturalmente, com não menos casas decimais do que os valores normalizados. E para valores não-normalizados, o número de decimais é maior.
É claro que o último dígito significativo é arredondado. Mas se, por exemplo, se você colocar 5 dígitos significativos para o número 0,000016, será 0,00002, e se houver dígitos menos significativos, será sempre 0. Portanto, o arredondamento para um dígito específico nem sempre é possível. Os valores de MA não dependerão apenas do prazo, mas também das próprias barras. Portanto, não está claro como definir o número de dígitos significativos durante a normalização no caso geral.
O que eu não consigo entender sobre o valor infinitesimal é como aplicá-lo. Infinitesimal (erro) é usado para comparar um número real com 0. Eu, por outro lado, preciso comparar a diferença. A situação aqui pode ser ainda pior. Por exemplo, eu estabeleci um epsilon. Quando a diferença é maior que a do epsilon, eu a considero positiva. Quando é menos do que menos o epsilon, é negativo. Quando está dentro dos limites, é 0. Mas então como você determina a mudança no sinal da diferença? Por exemplo, a diferença entre os muvings em duas barras está dentro do epsilon. Mas no primeiro caso é positivo, no segundo é negativo (ou seja, a travessia aconteceu PRONTAMENTE). E eu, levando em conta a introdução do erro, considerarei a diferença como 0. Então a condição de mudança de sinal deve ser mudada. Condicionalmente, o sinal de duas passagens de MA de cima para baixo neste caso será tanto uma simples comparação de <0 (foi) e >0 (tornou-se), e =0 (foi) e >0 (tornou-se). E o mais importante, no caso descrito (quando os valores no mesmo ponto são diferentes para chamadas diferentes), a introdução deste erro não ajuda. Esta diferença pode sempre ser tal que, qualquer que seja o epsilon que você escolher, você não receberá um sinal.
É claro que o último dígito significativo é arredondado. Mas se, por exemplo, para um número 0,000016 você colocar a normalização com 5 dígitos, será o número 0,00002, e se menos dígitos, será sempre 0. Portanto, o arredondamento para um dígito específico nem sempre é possível. Os valores de MA não dependerão apenas do prazo, mas também das próprias barras. Portanto, não está claro como definir o número de dígitos significativos durante a normalização no caso geral.
O que eu não consigo entender sobre o valor infinitesimal é como aplicá-lo. Infinitesimal (erro) é usado para comparar um número real com 0. Eu, por outro lado, preciso comparar a diferença. A situação aqui pode ser ainda pior. Por exemplo, eu estabeleci um epsilon. Quando a diferença é maior que a do epsilon, eu a considero positiva. Quando é menos do que menos o epsilon, é negativo. Quando está dentro dos limites, é 0. Mas então como você determina a mudança no sinal da diferença? Por exemplo, a diferença entre os muvings em duas barras está dentro do epsilon. Mas no primeiro caso é positivo, no segundo é negativo (ou seja, a travessia aconteceu PRONTAMENTE). E eu, levando em conta a introdução do erro, considerarei a diferença como 0. Então a condição de mudança de sinal deve ser mudada. Condicionalmente, o sinal de duas passagens de MA de cima para baixo neste caso será tanto uma simples comparação de <0 (foi) e >0 (tornou-se), e =0 (foi) e >0 (tornou-se). E o mais importante, no caso descrito (quando os valores no mesmo ponto são diferentes em chamadas diferentes), a introdução deste erro não ajuda. Esta diferença pode sempre ser tal, que qualquer que seja o epsilon que você escolher, você não receberá sinal.
Penso que ao resolver qualquer problema em particular, você também pode confiar na precisão dos dígitos decimais significativos. Ao dobro são 15 dígitos significativos, de acordo com a Documentação. O formato de precisão da normalização, de 0 a 8, de acordo com a Documentação. A DoubleToString tem suas próprias peculiaridades de formatos de precisão.
Além disso, o iMA é, do meu ponto de vista, uma função que leva em conta que os valores derivados com ele serão aplicados em diferentes situações e para resolver diferentes problemas. Assim, os valores que ela produz podem ser processados de forma diferente, também com relação a tarefas específicas.
Além disso, o cálculo de médias é um cálculo matemático. Por exemplo: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... De forma correspondente, os valores calculados com arredondamentos pequenos ou estendidos aumentam as opções para a aplicação dos cálculos.
Por precaução, quero mencionar que ao invés do iMA, você pode usar as funções da biblioteca MovingAverages, que está incluída no pacote de terminais padrão. Ou você pode usar suas próprias funções com base nas que estão nesta biblioteca.
/* Nos cálculos matemáticos, pode haverpeculiaridades de trabalhar com números do tipo duplo */.
Sobre o epsilons, por outro lado, vou passar.
P./S.: Quer dizer, experimentos, eu acho, podem ajudá-lo. O raciocínio teórico sem experiências práticas (sobre grande quantidade de dados) para tarefas específicas, inclusive, pode confundir e afastar soluções aceitáveis.
Dina Paches:
...
Que bagunça. Há 300 dias que estamos comparando os AM... Normalizar para os dígitos e não se incomodar...
Você pode normalizar os valores diretamente (a diferença - não há como). Mas novamente, o código de referência ala dado para a comparação de MA deve ser alterado e deve-se inserir uma desigualdade não restrita de qualquer forma. Além disso, a questão dos diferentes valores de MA em uma mesma barra quando calculados em momentos diferentes permanece em aberto. Se isso se repetir mais, não é certo que mesmo a normalização e a introdução de uma desigualdade não restrita resolvam completamente o problema. Mais o caso quando os muwings dentro de uma barra se cruzam duas vezes, você não pode pegar, se analisar não por carrapatos, mas pela abertura de uma nova barra. Talvez você possa compartilhar sua experiência, como você age nesta situação?
Bem, em primeiro lugar, a diferença de dois valores normalizados eventualmente dará um valor não-normalizado. Você precisa verificar a diferença normalizada.
Em segundo lugar, se você quiser pegar crossovers dentro de uma barra, pegue valores de todos os carrapatos no zero e na primeira barra - você vai pegar muito ... ...apenas cuidado ...
Se você testar pela abertura de um bar, então o consultor especializado deve monitorar claramente a abertura de um novo bar e, após o fato, verificar a existência de crossovers.
Primeiro decida por si mesmo - negocie na abertura do bar ou a cada tique, depois escreva seu código. E, portanto, testá-lo da mesma forma.
Dina, estou surpreso com sua paciência angelical ...
Obrigado, Artem, mas infelizmente acontece que ela também pode ter limites.