Comparação da média móvel (e quaisquer outros indicadores) e erro - página 4
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
Obrigado pelo conselho, é claro, mas eu mesmo posso ler a Ajuda. E repito, a matemática computacional não está ligada a uma linguagem de programação particular. São apenas os erros de cálculo com os quais tenho que lidar, com os quais você vai passar.
Se você não só pode ler a Ajuda, mas também compreendê-la, então você está se engajando em demagogia deliberada, continuando teimosamente a falar sobre a normalização e suas potenciais aplicações num espírito menosprezador. Incluindo a demagogia deliberada sobre os perigos de sua aplicação.
E não estou sendo esperto, mas dando contra-exemplos (inclusive para sua amada normalização).
A demagogia estava lá. Não houve contra-exemplos sobre a normalização.
Além do fato de que alguém pode aplicá-lo erroneamente.
Portanto, os epsilons podem ser aplicados incorretamente. Sim e a demagogia já foi mencionada.
P./S.: O posto é sobre normalização, portanto não menciono médias móveis.
E eu acho que a Artem pode ajudá-lo melhor com EAs usando MAs do que com aqueles difíceis.
Procure por crossovers em cada carrapato. Qual é o problema?
Nunca é necessário normalizar nada ao comparar dois números reais.
Se os números são realmente iguais, eles são armazenados na memória igualmente. Na verdade, é precisamente por causa dessa propriedade que as máquinas de computação podem existir.
Portanto, as comparações do formulário se(a<b) ou se(a==b) estão corretas em qualquer caso e nenhuma normalização é necessária.
Se a mente inquisitiva de um pesquisador encontrar contradição a esta regra, significa que ou sua máquina está fora de ordem, ou sua mente está fora de ordem. Um dos dois.
Ajuda e documentação, claro, devem ser lidas pelo menos às vezes (também foram escritas por humanóides como nós), mas é necessário ter seu próprio raciocínio sensato.
Se você não só pode ler a Ajuda, mas também compreendê-la, então você está se engajando em demagogia deliberada, continuando teimosamente a falar sobre a normalização e suas potenciais aplicações num espírito menosprezador. Incluindo a demagogia deliberada sobre os perigos de sua aplicação.
A demagogia estava lá. Não houve contra-exemplos de normalização.
Não incluindo o fato de que alguém pode não usá-lo corretamente.
Portanto, os epsilons podem ser aplicados incorretamente. E a demagogia já foi mencionada.
Houve contra-exemplos (pelo menos em termos de normalização também de diferença, como aqui foi dito). Vou repetir: a normalização é o caminho mais fácil para aqueles que não querem se aprofundar nos meandros. Ele leu a documentação e acredita piedosamente em tudo isso. Mais uma vez, repito que a linguagem de programação dentro da matemática computacional é irrelevante. Se estiver escrito nisto no helpe, isso não significa que seja verdade (caso contrário não haveria matemática computacional e problemas de epsilon que você não gosta tanto). Há muita coisa escrita na cerca também, mas isso não significa que seja a verdade em último recurso. Você está feliz com a opção Halp, você tem todo o direito de estar. Mas é a sua escolha pessoal. E isso não significa que resolva todos os problemas que tenho tentado deixar claro aqui. E considerar como demagogia algo que você simplesmente não quer entender (novamente, seu direito), não significa que seja demagogia em si. Não estou fazendo perguntas retóricas sobre o sentido da vida (cujas respostas são apenas demagogia), estou apenas tentando lidar com algo que ainda não encontrei. Novamente, digamos que os valores são sempre os mesmos sempre que você os calcula. Lá você poderia obter algo da mesma matemática computacional. Mas quando os valores também são diferentes, você não será capaz de inventar um algoritmo universal, mesmo se você for um mega-guru.
Além disso, eu só quero ter certeza de que meu entendimento de que se um robô não funciona por carrapatos, obter múltiplas interseções dentro de uma barra é basicamente impossível. Ela já pode ser atribuída puramente aos meandros do mql.
P.S. Eu não estou tentando discutir com alguém sem fundamento, eu não acho que sou um gênio certo o tempo todo. Eu simplesmente não gosto quando as pessoas tentam ser espertas e escrever algo sem realmente lê-lo. Não tem nada a ver com você pessoalmente. Obrigado por sua ajuda e por suas reflexões sobre o assunto. Mas ainda assim, IMHO é errado escrever algo sobre paciência quando você insiste em apenas um ponto de vista na documentação (que você acredita de todo coração e não aceita nenhum ponto de vista e exemplos alternativos), e os epsilons não são do seu agrado. Espero que Artyom também entenda o que escrevi no pós-escrito antes disso. Obrigado a todos vocês por suas respostas e me perdoem se eu fiquei um pouco irritado em algum lugar.
P.P.S. A normalização até certa casa decimal é na verdade análoga à introdução do epsilon apenas pela ordem do mesmo sinal.
P.P.P.S. Se tivermos uma discussão tão acalorada, eu ficaria muito grato se você compartilhasse suas experiências neste tópico, porque as respostas adequadas (especialmente sobre os 2 e 3 itens que me incomodam), de fato, não obtiveram. Apesar de ter sido verificado em muitos fóruns, quase chegou-se à conclusão de que, sim, 2 pontos é impossível. Os desenvolvedores da mql poderiam pensar sobre isso e proporcionar mais flexibilidade, pois é muito inconveniente (em qualquer outra linguagem de programação tem a capacidade de mudar dinamicamente a interface do programa, e aqui acontece que não há nenhuma ((()))
Houve contra-exemplos (pelo menos em termos de normalização também de diferença, como aqui foi dito). Vou repetir: a normalização é o caminho mais fácil para aqueles que não querem se aprofundar nos meandros. Ele leu a documentação e acredita piedosamente em tudo isso. Mais uma vez, repito que a linguagem de programação dentro da matemática computacional é irrelevante. Se estiver escrito nisto no helpe, isso não significa que seja verdade (caso contrário não haveria matemática computacional e problemas de epsilon que você não gosta tanto). Há muita coisa escrita na cerca também, mas isso não significa que seja a verdade em último recurso. Você está feliz com a opção Halp, você tem todo o direito de estar. Mas é a sua escolha pessoal. E isso não significa que resolva todos os problemas que tenho tentado deixar claro aqui. E considerar como demagogia algo que você simplesmente não quer entender (novamente, seu direito), não significa que seja demagogia em si. Não estou fazendo perguntas retóricas sobre o sentido da vida (cujas respostas são apenas demagogia), estou apenas tentando entender algo que ainda não encontrei. Novamente, digamos que os valores são sempre os mesmos sempre que você os calcula. Lá você poderia obter algo da mesma matemática computacional. Mas quando os valores também são diferentes, você não será capaz de inventar um algoritmo universal, mesmo se você for um mega-guru.
Além disso, eu só quero ter certeza de que meu entendimento de que se um robô não funciona por carrapatos, obter múltiplas interseções dentro de uma barra é basicamente impossível. Ela já pode ser atribuída puramente aos meandros do mql.
P.S. Eu não estou tentando discutir com alguém sem fundamento, eu não acho que sou um gênio certo o tempo todo. Eu simplesmente não gosto quando as pessoas tentam ser espertas e escrever algo sem sequer lê-lo. Isto não tem nada a ver com você pessoalmente. Obrigado por sua ajuda e por suas reflexões sobre o assunto. Mas ainda assim, IMHO é errado escrever algo sobre paciência quando você insiste em apenas um ponto de vista na documentação (que você acredita de todo coração e não aceita nenhum ponto de vista e exemplos alternativos), e os epsilons não são do seu agrado. Espero que Artyom também entenda o que escrevi no pós-escrito antes disso. Obrigado a todos vocês por suas respostas e me perdoem se eu fiquei um pouco irritado em algum lugar.
P.P.S. A normalização até certa casa decimal é na verdade análoga à introdução do epsilon apenas pela ordem do mesmo sinal.
P.P.P.S. Se tivermos uma discussão tão acalorada, eu ficaria muito grato se você compartilhasse suas experiências neste tópico, porque as respostas adequadas (especialmente sobre os 2 e 3 itens que me incomodam), de fato, não obtiveram. Apesar de ter sido verificado em muitos fóruns, quase chegou-se à conclusão de que, sim, 2 pontos é impossível. Os desenvolvedores de mql poderiam ter pensado nisso e proporcionar mais flexibilidade, pois é muito desconfortável (em qualquer outra linguagem de programação tem a capacidade de mudar dinamicamente a interface do programa, e aqui acontece que não há nenhuma ((()))
Para mim, usar a conversão de dados usando a função NormalizeDouble ao comparar duplas é uma das duas formas, estipuladas na Documentação, de conseguir que as condições do programa funcionem exatamente onde e como foi pretendido ao escrever condições específicas em código. Era sobre isso que eu estava falando antes. Portanto, não se trata apenas da eliminação de quaisquer erros. São também várias formas ponderadas de transformar dados para atender a quaisquer condições.
Eu já lhe falei e estou lhe falando sobre isso, com base em minha experiência prática pessoal na linguagem de programação que você está começando a aprender. Por este motivo, e sugerido repetidamente neste tópico, para utilizar de forma tão prática.
A propósito, direi, em parte, concordando com você, que não vou contestar que a normalização com esta função pode ser a maneira mais fácil para qualquer tarefa em termos de transformação de dados do tipo real
Mas cabe a todos decidir qual dos dois métodos recomendados na Documentação deve ser usado na conversão de dados de tipos reais.
E escolher qualquer uma destas formas não é determinante se se trata do tipo de pessoa que tenta descobrir qualquer sutileza necessária ou não.
Que eu não gosto de epsilons não foi uma palavra da minha parte. Não aplicar nenhum método não é necessariamente amor/desinteresse. Tampouco insisti em aplicar apenas a segunda via das duas.
Minhas palavras literais em termos de aplicação prática das peculiaridades de trabalhar com números do tipo duplo, isso:
P./S.: Acontece que o primeiro método da Documentação acabou sendo menos conveniente para mim, inclusive, baseado em tarefas, que, via de regra, eu resolvo por mim mesmo. Consequentemente, não tenho muita experiência com o primeiro caminho.
Mas ao aplicar a segunda via (isto é, comparar a diferença normalizada de dois números reais com valor zero na expressão do operador condicional), nenhum problema surgiu sem ambigüidade.
Mas se eu fiz uma comparação de números não normalizados (aqui quero dizer, sem usar a primeira maneira também), então sim, foi que encontrei um funcionamento incorreto das condições com base em comparações de números do tipo duplo.
Além disso, eu também dei tal esclarecimento:
P./S.: Dito isto, por precaução, esclarecerei mais uma vez, que comparando números reais pelo primeiro método dos dois aqui listados ,comparando a diferença de números com algum valor pequeno, não posso chamar pior do que usar a normalização, quando você precisa ajustar o nível de comparação (incl., já que para mim o segundo método era mais conveniente, não considerei para mim mesmo mais detalhado para a aplicação prática).
Isto é, em termos de normalização ao converter dados do tipo duplo, eu simplesmente não precisava da primeira maneira. Em particular, devido à conveniência de usar a função NormalizeDouble na solução de vários problemas (e não apenas em comparações).
Este site tem uma enorme base de conhecimentos acumulados.
As pessoas têm resolvido e estão resolvendo todos os tipos de tarefas de complexidade diferente usando MQL4.
Depois que a MQL4 foi aproximada da MQL5, as possibilidades da primeira aumentaram ainda mais.
Acho que você deveria conhecer melhor esta linguagem de programação e não ignorar a base de conhecimento acumulada nos sites aqui. Ganhe experiência prática na sua utilização. E só então você pode dizer algo confiante em termos de quaisquer aplicações nesta linguagem de programação e suas capacidades.
Tenho um ToR diferente) E mais uma vez, já escrevi sobre os problemas com carrapatos. Não há como explicar ao cliente por que o robô entrou no comércio se ele não vê o cruzamento no gráfico.
Pegue os valores de MA no zero e a primeira barra em cada tic - então e só então você pode encontrar cruzamentos de MA na barra de zero. Você os tira da primeira barra no momento da abertura da barra zero - e ali os valores de MA são aqueles que estavam presentes quando a primeira barra foi fechada, não quando ela foi formada. Você simplesmente lê МАšek valores atrasados e, portanto, não os vê atravessando. A normalização não tem nada a ver com isso. E, a propósito, se os MA mostram valores de preços, então os valores devem ser normalizados para _Dígitos, em vez de adivinhar a que valor a normalização é necessária...
Prezados participantes do fórum. Por favor, não estabeleça brigas no fórum. Somente sobre o assunto do fio.
Acho que o assunto pode ser encerrado. Os autores (não o tópico) das declarações não chegaram a um consenso. Houve momentos isolados de chauvinismo, o que não é bem-vindo.
Mas nem um nem outro foram capazes de provar seu caso. É por isso que eu fecho o fio. Outras discussões podem ser punidas (proibição máxima diária).
Embora, se houver provas normais, é bem-vindo.
Os juízes serei eu e Volodya.
Isto não é uma discussão.
Eu não vi tudo isso aqui, então não sei que argumentos foram apresentados dentro do tópico. Mas como suponho que se trata de provar minha posição, que é semelhante à posição da Artem neste posto (e antes aqui no tópico), vou dar um dos exemplos abaixo, em relação a se a normalização deve ser aplicada de uma forma ou de outra quando se trabalha com números de tipo real.
Com screenshots e uma variante do código de teste.
Artyom escreveu no post acima:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
E como também acredito (como penso que muitos outros acreditam) que esta é uma maneira simples e eficaz nas direções mais comuns dos problemas, farei apenas esta pequena adição minha:
com quantas casas decimais é concebido para exibir a linha MA, ou apenas realizou cálculos com base em qualquer número de casas decimais (a mesma comparação), com tantas casas decimais e normalização (arredondamento para uma determinada casa decimal).
/*Para algumas tarefas individuais, pode haver "exceções", e você pode variar para obter o resultado desejado, por exemplo, comparando um valor com uma casa decimal inferior, com um valor com uma casa decimal superior. Mas se isto for necessário para a tarefa em questão, então, em minha opinião, pode ser bem aconselhável, se necessário, como no método acima, imprimir os valores obtidos e comparar os valores obtidos com a renderização exibida visualmente no gráfico.
Se precisarmos emitir valores de tipo duplo como texto (através de Impressão, Comentário, OBJ_LABEL etc.), então devemos usar DoubleToString, pois queremos converter número em texto.
Agora, da explicação introdutória à clareza:
Nas capturas de tela:
Os dados do roteiro de teste são valores de MA obtidos usando a função iMA (com e sem transformações usando as funções descritas para trabalhar com tipos reais na Documentação).
Você pode ver na janela de dados e no gráfico que as linhas com uma casa decimal inferior se igualaram em valores na terceira barra, sem contar com a atual, do gráfico. Você também pode ver que os valores de MA do conjunto padrão até o terminal, desenhados nas casas decimais da carta, não são iguais e visualmente eles foram equalizados na carta um pouco antes.
Ou seja, se você ampliar as telas ou realizar seus próprios experimentos usando o roteiro de teste anexo ou seus próprios códigos, você verá que as linhas MA, com o número de casas decimais como no gráfico, cruzam-se um pouco mais cedo.
E isso é compreensível. Por analogia, as linhas com decimais são linhas a menos do que linhas desenhadas com citações de dois dígitos em um gráfico de três dígitos. Permite vê-las em pontos "antigos" do tempo quando as cotações de três ou cinco dígitos nos terminais não são muito espalhadas e, ao mesmo tempo, têm as vantagens de estender as cotações decimais para negociação (incluindo spreads mais estreitos).
Ou seja, as linhas baseadas em valores com menos casas decimais têm menos "ruído".
Mas se o arredondamento não fosse aplicado (neste caso, usando a função de normalização), um número claramente limitado a uma casa decimal específica seria mais problemático.
Ou, se apenas em números:
123.4561 e 123.4556 não são iguais. E sua diferença não é zero.
Entretanto, se você arredondá-los para cima, tanto o primeiro como o segundo número, serão o mesmo e igual a 123.456. Assim, a diferença entre eles será 0.
É até o ponto decimal para arredondar os valores resultantes, dependendo das tarefas a serem realizadas.
Nas telas da revista "Experts", você pode ver a saída dos valores de MA usando o iMA com as conversões descritas na Documentação, e sem as conversões dos valores resultantes. As configurações de MA no roteiro de teste são iguais às dos indicadores no gráfico.
Na segunda captura de tela, você pode ver os deltas entre dois valores de MA com e sem transformações.Abaixo, como mencionei, há um pequeno código de teste. Ela não é otimizada, mas permite fazer várias experiências com valores de MA, incluindo a mudança de alguns parâmetros.
O número de barras é definido nesta linha:
P./S.: Eu substituí o roteiro de teste anexo. Enganei-me na variante do meu posto. Errado. Desculpe.
As screenshots anteriormente anexadas não são necessárias, por isso as deixo da mesma forma.