Erros, bugs, perguntas - página 3131

Novo comentário
 
x572intraday #:

Só posso responder por &= imediatamente:

MQL5 Reference Guide / Language Basics / Operations and Expressions / Assignment Operations:

Em analogia com a variável cumulativa y:


Mas esta é a minha primeira experiência com &=, por isso posso estar errado.

Em primeiro lugar, todas as condições lógicas são resumidas em h_plus acumulativo dentro para e o bool-sum resultante é inserido no se que não tem nada a ver com interno para.
Mas ainda assim, seria mais correcto não 
h_plus&=high[i]>high[i+increment];
mas 
h_plus = h_plus && high[i]>high[i+increment];
 
Alexey Viktorov #:

No seu caso, não é este o caso, pois ambas as condições devem ser satisfeitas. Mas se colocar isto

então, sim. Se a condição "a" for cumprida, a segunda condição não será verificada. Isto tem sido combatido há anos, e agora está a sugerir que voltemos ao século passado.

Embora... eu esteja errado nesta minha declaração. Aparentemente não percebi bem o que está aqui escrito.

x572intraday #:

Não me atrevo a chamar-lhe um insecto. É por isso que vou simplesmente dizer que notei uma peculiaridade do se operador. Suspeito que também possa ser relevante para outras línguas escritas.

Se um se revelar verdadeiro, verifique os saltos para Array[over_index] e aqui o terminal começa a colidir através da parte'array out of range', o que é bem verdade. Mas se um terminal se revelar falso, o terminal não verificará a condição de Array[over_index] e, portanto, a redundância do índice, e se irá saltar mais e o codificador não saberá que existe um array com um índice inexistente no seu programa... ou antes uma existente, mas redundante.

Talvez devesse haver uma correcção para que a verificação de "matriz fora de alcance" fosse efectuada até ao fim do laço e a mesma mensagem fosse emitida? Ou irá reduzir significativamente a velocidade do operador?

Mesmo que a && condição e a primeira condição não sejam cumpridas, a segunda não será verificada. Portanto, desculpem-me se enganei alguém...

 
x572intraday #:

Já tentei tanto quebrar como voltar no calor do momento, mas isso só piorou as coisas. Vou tentar simplificar um pouco mais o código e repensá-lo com pausa.

for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus =  high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

Assim.

 

Ao escalar o gráfico movendo o rato ao longo da linha temporal, o gráfico corre para a esquerda ou para a direita, dependendo da direcção do rato, de modo que tudo o que está no foco de visão do utilizador desaparece frequentemente apenas para além dos limites do gráfico. Isto é terrivelmente inconveniente, porque depois é preciso procurar o lugar certo, e isto tem sido assim desde que estou familiarizado com a MT.

Era lógico supor que talvez ao clicar no ícone da lupa, o gráfico será redimensionado para o centro, mas não, o comportamento é o mesmo que com a escala do rato - o gráfico move-se para a esquerda (compressão) ou para a direita (expansão).

Caros programadores! Pedimos-lhe encarecidamente que altere o comportamento de escala da carta, é necessário deixar o centro da carta no centro.

Todos com quem discuti este inconveniente de trabalhar com o gráfico concordam comigo, por isso tenho uma boa hipótese de ser objectivo em relação a este problema.

Tentou habituar-se a ele durante 14 anos - não conseguiu.

 
JRandomTrader #:
for(int i=start; i<rates_total-n && !IsStopped(); i++)
{
   for(int increment=1, bool h_plus=true ; h_plus && increment<=n ; increment++)
     h_plus = high[i]>high[i+increment]; // можно не накапливать, вылетим из цикла на первом false

   if(h_plus) {...}
   ...
}

É assim.

Nova ideia, vou tentar.

Como para a opção anterior:

for(int i=start; i<rates_total-3 && !IsStopped(); i++)
{
   bool h_plus=true; //false?
   for(int increment=1; increment<=n; increment++)
     {
      h_plus&=high[i]>high[i+increment];
      if(!h_plus)break;
     }
   if(h_plus) {...}
   ...
}

sem sequer o experimentar, já é claro que

if(!h_plus)break;

é após a soma, o que significa que o terminal verá primeiro a linha anterior e compreenderá que existe uma matriz com um índice excessivo e dará a mesma mensagem de"matriz fora de alcance". Isto é a segunda coisa. E a primeira é que devemos verificar não para !h_plus mas para ArraySize(high)<=i+increment e escapar ao laço no caso de o índice ser excedido. Tentei tudo isto ontem, mas falhei em algumas subtilezas. Sim, não havia mensagem, mas o indicador também começou a fazer uma confusão.

 
x572intraday #:

Como para a opção anterior:

sem sequer o experimentar, já é claro que

é após a soma, o que significa que o terminal verá primeiro a linha anterior e compreenderá que existe uma matriz com um índice excessivo e dará a mesma mensagem de"matriz fora de alcance". Esta é a segunda coisa. E a primeira é que devemos verificar não para !h_plus mas para ArraySize(high)<=i+increment e escapar ao laço no caso de o índice ser excedido. Tentei tudo isto ontem, mas falhei em algumas subtilezas. Sim, o mensageiro tinha desaparecido, mas o indicador também começou a fazer uma confusão.

Portanto, o problema aqui é

i<rates_total-3
Escrevi 
i<rates_total-n
por uma razão, e o pontapé de saída precoce do laço é precisamente para simular o cálculo if()
 
x572intraday #:

Não me atrevo a chamar-lhe um insecto. Portanto, direi apenas que notei uma peculiaridade da declaração do "se". Suspeito que isto possa aplicar-se também a outras línguas.

Se um se revelar verdadeiro, verifique os saltos para Array[over_index] e aqui o terminal começa a colidir através da parte'array out of range', o que é bem verdade. Mas se um terminal se revelar falso, o terminal não verificará a condição de Array[over_index] e, portanto, a redundância do índice, e se irá saltar mais e o codificador não saberá que existe um array com um índice inexistente no seu programa... ou antes uma existente, mas redundante.

Talvez devesse haver uma correcção para que a verificação de "matriz fora de alcance" fosse efectuada até ao fim do laçoe a mesma mensagem fosse emitida? Ou irá reduzir significativamente a velocidade do operador?


Se definir a variável a como falsa, o controlo é transmitido e não afecta a matriz ou o código entre parênteses depois se, porque no seu caso

if(a && Array[over_index]>val) {...}

o controlo só será passado para a parte direita da condição se a parte esquerda (a) for verdadeira

se, por exemplo, fizer

if(check(over_index) && Array[over_index]>val) {...}

onde a função de verificação verifica o array Array, nunca obterá "array fora de alcance". Assim, pode verificar o índice do array e endereçá-lo num if. Mas para passar o controlo para a segunda parte do if com && operador, se a primeira parte for falsa, dificilmente será possível em qualquer uma das linguagens de programação existentes...

 

Existe um problema, que parece ser aleatório e ocasional.

Aparece quando se trabalha no testador com várias moedas.

Em cada ciclo solicito preços reais por símbolos. Se por alguma razão o testador não receber citações para um determinado símbolo, utiliza as citações obtidas anteriormente para outro símbolo.

Devo abrir uma posição se o preço for mais elevado do que o especificado. Devo abrir posição se obtiver dados errados de outro símbolo.

O símbolo EURCAD abre se o preço for superior a 1,45117. 1,74425>1,45117? Sim, é mais alto mas é o preço de outro símbolo.

Detectámos 7 ordens erradas em 500.

 
Yury Lemeshev #:

Existe um problema, que parece ser aleatório e ocasional.

Aparece quando se trabalha no testador com várias moedas.

Em cada ciclo solicito preços reais por símbolos. Se por alguma razão o testador não receber citações para um determinado símbolo, utiliza as citações obtidas anteriormente para outro símbolo.

Devo abrir uma posição se o preço for mais elevado do que o especificado. Estou a utilizar dados errados de outro símbolo para a abertura.

Símbolo EURCAD se o preço for superior a 1,45117, então abre-se. 1,74425>1,45117? Sim, é mais alto mas é o preço de outro símbolo.

Detectámos 7 ordens de erro de entre 500.

O problema está no código, mas os telepatas já estão a celebrar e, quando saírem do sono, dirão que o erro está na linha 123652

 
Alexey Viktorov #:

Problemas no código, mas os telepatas já estão a celebrar, e quando saírem do seu binge, dirão que o erro está na linha 123652

Não há erro no código, o código foi reescrito para eliminar o erro, e o erro não aparece regularmente, é completamente caótico

1...312431253126312731283129313031313132313331343135313631373138...3184
Novo comentário