[ARQUIVO] Qualquer pergunta de novato, de modo a não desorganizar o fórum. Profissionais, não passem por aqui. Em nenhum lugar sem você - 3. - página 248

Novo comentário
 
Roman.:
ERR_INVALID_TRADE_VOLUME 131 Volume incorreto - conheça esta forma e defina o volume "certo" de acordo com seu tipo de conta, por exemplo, em contas micro o volume é normalmente 0,01 lote, em contas "clássicas" 0,1 lote... Digite um valor constante de 0,1 lote em sua função de abertura de pedidos e verifique se o volume...
A EA comercializa um % específico do lote ekvit, ou seja, só posso entrar com porcentagens como 10, 5, não há opção de entrar com o lote 0,1 ou 0,01. Este problema só ocorreu com um corretor de 4 dígitos.
 
MeTrade:
MaxZ:
Você já testou em dias de semana? O spread está flutuando?
Otimizado durante toda a semana, testado hoje à noite e esta manhã. Isso é um problema?
Você não respondeu à minha pergunta sobre a propagação.
 
Por que este alerta está surgindo? Eu gastei muito esforço para descobrir que ao comparar um dígito com uma peça fracionária, eu preciso normalizá-lo com NormalizeDouble(). Mas decidi experimentar hoje por diversão e o alerta surge! O que são essas falhas? Ou não há falhas?
      if (1.3320 == 1.3320)
         Alert("Ku!");
 
ScioMe:
Por que este alerta está surgindo? Eu gastei muito esforço para descobrir que ao comparar um dígito com uma peça fracionária, eu preciso normalizá-lo com NormalizeDouble(). Mas decidi experimentar hoje por diversão e o alerta surge! Que tipo de falhas? Ou não há falhas?
Que falhas existem? Estas constantes são iguais. A condição está satisfeita.
 
MeTrade:
A EA negocia com uma certa % do ekvit, ou seja, só posso entrar com uma porcentagem, por exemplo, 10, 5, não há opção de entrar com um lote de 0,1 ou 0,01. Este problema só ocorreu com um corretor de 4 dígitos.
este problema ocorre apenas em corretores de 4 dígitos: "...só posso inserir uma porcentagem, por exemplo 10, 5" - assim seu cálculo é feito sem normalização de volume antes de abrir um pedido, ou seja, no final, seus 10 ou 5% resultam em 0,123 ou 1,548 lotes, o que causa o erro número 131, favor corrigir a função de cálculo de lotes ou pedir a um telepata, já que não há dados suficientes de "entrada" (brutos) sobre o assunto ...
 
ScioMe:
Por que este alerta está surgindo? Eu gastei muito esforço anteriormente para tentar descobrir que ao comparar um dígito com uma peça fracionada, eu precisava normalizá-lo usando a função NormalizeDouble(). Mas decidi experimentar hoje por diversão e o alerta surge! Que tipo de falhas? Ou não há falhas?

1). O compilador pode simplesmente ignorar esta condição (se declaração).

2). Se, no entanto, o compilador não ignorar esta condição, ele escreverá cada número na memória e alocará 8 bits para cada número. Ele compara os números, não como nós fazemos com nossos olhos, mas pouco a pouco. Os números na memória são os mesmos e a condição vai se manter.

Estou muito surpreso com sua pergunta, porque não consigo entender como esses dois números (dois registros) não são percebidos como iguais?

 
MaxZ:
Você não respondeu à minha pergunta sobre a propagação.
Experimentei em um terminal de 4 dígitos com um spread fixo, tudo está bem. Mas outro problema apareceu, o erro número 131, que não aconteceu no terminal de 5 dígitos.
 
MeTrade:
Após seu comentário, experimentei em um terminal de 4 dígitos com um spread fixo, tudo está bem. Mas outro problema apareceu, o erro número 131, que não aconteceu no terminal de 5 dígitos.
Eu tenho que sentar aqui e adivinhar! :))) Tenho certeza de que você também vai resolver os outros problemas.
 

Por favor, informe como fazer isso corretamente. Minha função de cálculo MM é complexa e em uma parte dela, ao calcular o lote, a função retorna 0,18 como um lote máximo possível e você pode abrir 0,1, 0,2 ou 0,3, ou seja, o passo é 0,1.

Se eu normalizar o lote, ele é arredondado para 0,2 e a ordem não é mais permitida, embora o lote máximo permitido seja 0,18.

 
MaxZ:

""""...
Я очень удивлён был Вашему вопросу, так как не могу понять как можно два эти числа (две записи) воспринять не равными??""""


Já há algum tempo que estamos lutando contra este problema. Quase quebrou meu cérebro! O problema era o seguinte: eu precisava realizar uma condição de igualdade no se (). Estávamos comparando números reais. Não consegui obter um alerta, eu estava me perguntando o que diabos estava acontecendo. Estes números, você pode ver a olho nu que eles são iguais! Mas o terminal não o imprimiria. Eu finalmente suspeitei que algo estava errado, mas não conseguia descobrir o que estava errado. Eu preciso da ajuda da comunidade mql4. Eu fiz uma pergunta aqui, e obrigado, os especialistas (parece que romanos e outras pessoas boas) responderam que ao comparar números reais, eu preciso normalizá-los com a função NormalizeDouble(). Isso ajudou. Mas hoje eu tentei e o que está errado? Eles são comparados com segurança sem normalização. De qualquer forma, cheguei à conclusão que às vezes eles são comparados e às vezes não são, por isso é melhor normalizá-los para estar seguro.
1...241242243244245246247248249250251252253254255...652
Novo comentário