Erros, bugs, perguntas - página 589

 
Ashes:

Tem de olhar para fora da caixa (c)

Não vejo qualquer contra-indicação para correr uma nuvem separada (excepto o preço).

Uma corrida autónoma na nuvem será mais lenta em muitos casos do que no núcleo local.
 
joo:
Uma corrida individual na nuvem será mais lenta em muitos casos do que no núcleo local.
Acima dehttps://www.mql5.com/ru/forum/1111/page598#comment_125691 é um cenário. Note-se a palavra CAN. A limitação parece rebuscada.
 

Surgiu um problema.

No código de indicador em OnCalculate() existe esta linha (ou mais precisamente algumas linhas semelhantes):

ArrayInitialize(FractalsBuffer,EMPTY_VALUE);
O FractalsBuffer não é um tampão de cálculo auxiliar, mas sim o tampão principal responsável directamente pela plotagem gráfica, pelo que deve necessariamente estar ligado:
SetIndexBuffer(0,FractalsBuffer,INDICATOR_DATA);

que tenha sido feito. Mas a função de ligação tem algum efeito directo, que por vezes actua como um efeito secundário (de uma forma má). Através de CopyBuffer(ind_handle,0,0,montante,FractalsBuffer) o buffer é preenchido não durante todo o período de tempo histórico, mas apenas parcialmente, a partir do seu pequeno segmento, pelo montante. Mas o ArraySize(FractalsBuffer) convence-nos claramente que o tamanho do buffer (ou seja, memória física ocupada) corresponderá ao número de barras de toda a história, ou seja, no final estará totalmente ocupado, incluindo a parte ineficaz. Claro que, se quiser trabalhar com os valores tampão mais tarde no ciclo, não tem de procurar em todo o tampão - pode apenas especificar os limites necessários e trabalhar dentro desses limites. Mas, primeiro, não cancela a horrível alocação global da memória e, segundo, a função inevitável no código ArrayInitialize não permite inicializar parcialmente o tampão com o valor necessárioé necessário gastar tempo e potência na reinicialização total. Isto faz com que o indicador funcione visivelmente mais devagar. E terceiro, uma citação da descrição da função ArrayResize: "Edeve ter em mente que . é impossível redimensionar matrizes dinâmicas que são atribuídas como amortecedores indicadores pela função SetIndexBuffer()."Se rejeitarmosSetIndexBuffer a favor da manipulação manual do tamanho do tampão utilizando oArrayResize, o próprio gráfico indicador irá colapsar.

Sugerir uma receita de recuperação. Ou considerar isto como uma aplicação para resolver este problema na própria língua.
 
x100intraday:

É um pouco confuso...

1. faz sentido inicializar o tampão uma vez, no início se(prev_calculated==0)

2. Pode definir a barra a partir da qual os dados serão extraídos, assim: PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);

3. Todos os valores no tampão dentro do montante devem ser atribuídos explicitamente, uma vez ao longo da história, e depois apenas os novos valores serão atribuídos, não sendo então necessário inicializá-los.

4. Nas configurações do terminal, diminuir o número de barras na janela :)

 
Swan:

É um pouco confuso...

1. faz sentido inicializar o tampão uma vez, no início se(prev_calculated==0)

2. Pode definir a barra a partir da qual os dados serão extraídos, assim: PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1);

3. Todos os valores no tampão dentro do montante devem ser atribuídos explicitamente, uma vez ao longo da história, e depois apenas os novos valores serão atribuídos, não sendo então necessário inicializá-los.

4. Nas configurações do terminal, diminuir o número de barras na janela :)

1. De facto: ao nível da ideia - faz sentido fazê-lo apenas uma vez, mas na prática não é assim tão simples, tudo está realmente a funcionar. Acabei de copiar do indicador padrão: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. Como limpar o tampão antes de novos cálculos de uma forma diferente e mais eficaz - não sei.

2. Ainda não estudei esta possibilidade, mas parece não desenhar o indicador numa zona desnecessária, mas não limita o tamanho do buffer do indicador. Além disso, estou muito mais disposto a trabalhar com um buffer que é preenchido com dados úteis, sem qualquer margem livre, caso contrário terei de introduzir limites (sobre os quais falei no post anterior), e não se encaixa no algoritmo ortodoxo: de quatro buffers, três serão digitalizados num loop com os mesmos limites, e para um buffer terei de levar o meu tempo e fazer um loop de curva separado com limites diferentes, que dificilmente conseguirei apertar. Embora sim, também se pode engatinhar de muletas.

3. o que quer dizer explicitamente? Não respondo de forma alguma por não atribuir explicitamente. Pode muito bem ser que eu me esteja a apropriar explicitamente. Explicar? Quanto a carregar apenas novos valores - claro que uso isso, chama-se aqui um algoritmo parsimonioso.

4. Esta ideia foi rejeitada antes de escrever o post anterior, porque o indicador precisa de várias últimas (novas) barras da história, enquanto que para mim pessoalmente (aspecto visual) precisamos de todas ou quase todas as barras. O meu interesse humano pelas barras históricas é mais vasto do que o interesse de um indicador técnico nelas. Quero olhar para as barras e desenhar o indicador dentro de um gráfico. Um capricho? Trata-se de uma necessidade vulgar.

 
x100intraday:

1. A sério: a nível de ideias só faz sentido fazê-lo uma vez, mas na prática não é assim tão simples, tudo está realmente a funcionar. Acabei de copiar do indicador padrão: C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. Como limpar o tampão antes de novos cálculos de uma forma diferente e mais eficaz - não sei.

   if(prev_calculated<7)// if(prev_calculated==0)// if(prev_calculated<1)// вопщем одинаково)
      //Initialize только при первом запуске. нуу или при случае какогнить ахтунга)
      {
      limit=2;//цикл начинается со второго элемента индикаторного массива
      //--- clean up arrays//в принципе здесь не очистка массива, 
                        //а значения EMPTY_VALUE  присваивается 0 и 1 элементу массивов, мм.. и на последних трёх барах)
                        //остальные определяются далее в цикле..
      ArrayInitialize(ExtUpperBuffer,EMPTY_VALUE);
      ArrayInitialize(ExtLowerBuffer,EMPTY_VALUE);
      }
   else limit=rates_total-5;//иначе - в цикле пересчитываются только два последних значения

//зы: при появлении нового бара - новый элемент массива вроде как не определен, насколько мне известно не гарантируется, что он будет  ==EMPTY_VALUE
2. Ainda não estudei esta possibilidade, mas parece não desenhar o indicador numa zona desnecessária, mas não limita o tamanho do tampão indicador. Além disso, estou muito mais disposto a trabalhar com um buffer que é preenchido com dados úteis, sem qualquer margem livre, caso contrário terei de introduzir limites (sobre os quais falei no post anterior), e não se encaixa no algoritmo ortodoxo: de quatro buffers, três serão digitalizados num loop com os mesmos limites, e para um buffer terei de levar o meu tempo e fazer um loop de curva separado com limites diferentes, que dificilmente conseguirei apertar. Embora sim, também se pode rastejar de muletas...

Bem, sim, deveria.

O tamanho do tampão indicador é definido apenas pelo número de barras.

De uma forma ou de outra, algum tamanho terá de ser definido. Porquê fazer um laço curvo com limites diferentes, quando se pode fazer um laço recto com os mesmos limites)

Por outras palavras, deve especificar o tamanho do laço, não o tamanho da matriz... Caso contrário, o indicador será baseado nas muletas


3) O que quer dizer com "explicitamente"? Não posso de forma alguma garantir que não o atribuo explicitamente. Pode muito bem ser que o faça explicitamente. Explicar? Quanto a carregar apenas novos valores - claro que uso isso, chama-se aqui um algoritmo parsimonioso.
      //---- Upper Fractal
      if(High[i]>High[i+1] && High[i]>High[i+2] && High[i]>=High[i-1] && High[i]>=High[i-2])
         ExtUpperBuffer[i]=High[i];//условие выполняется - присваиваем значение
      else ExtUpperBuffer[i]=EMPTY_VALUE;//не выполняется - таки тоже присваиваем значение)
//нет зависимости от Initialize, всем элементам в цикле явно присваивается значение.

Sobre o algoritmo parcimonioso - não tenho a certeza de que o utilize.

O indicador é calculado uma vez para todas as barras - ou seja, pode ser um pouco lento quando lançado sobre uma história agromádica.

Posteriormente são recalculados alguns valores - tudo deve funcionar :)

 
Cmu4:

O que é o erro com os indicadores? Eles vêm e vão. E apenas os que estão numa janela separada!!!

Aqui está uma captura de ecrã de quando os indicadores desapareceram. Desaparecem de vez em quando... arbitrariamente. Também há um vídeo...

Atenção, os indicadores básicos estão a desaparecer!!! Significa que o insecto é significativo. Há o mesmo problema com os indicadores personalizados.

Cavalheiros desenvolvedores, corrijam este bug, por favor, não é agradável de alguma forma...

Infelizmente, a imagem do ecrã não aparece.

Que servidor? Que servidor de acesso? Qual a data/hora? A paginação da história estava na altura?

Está a acontecer de novo agora? Pode anexar os registos do terminal para esta data?

 

Caros programadores, encontrei um erro (falha) desagradável no compilador MQL5.

Se utilizar uma construção condicional da seguinte forma

se (Condição) ;

{ operador_1

......

Operador_N }

Não são gerados erros ou avisos aquando da compilação do código.

Mas como existe um " ; " (com ou sem espaços) logo após a condição, {operator_1...operator_N} será executado o tempo todo.

A MQL4 mostra um aviso. Quero que a MQL5 mostre também um erro ou aviso! (perdi meio dia a tentar descobrir o que está errado com o meu código)

Obrigado pelo seu feedback!

 
Fia:

Caros programadores, encontrei um erro (falha) desagradável no compilador MQL5.

Se utilizar uma construção condicional da seguinte forma

se (Condição) ;

{ operador_1

......

Operador_N }

Não são gerados erros ou avisos aquando da compilação do código.

Mas como existe um " ; " (com ou sem espaços) logo após a condição, {operator_1...operator_N} será executado o tempo todo.

A MQL4 mostra um aviso. Quero que a MQL5 mostre também erro ou aviso! (perdi meio dia a tentar descobrir o que está errado com o meu código)

Obrigado pelo seu feedback!


Tudo é válido neste caso. ; é um operador vazio.

Pensaremos na sua sugestão (emitir um vorning), mas não é a mais alta prioridade neste momento.

Документация по MQL5: Основы языка / Операторы / Оператор-выражение
Документация по MQL5: Основы языка / Операторы / Оператор-выражение
  • www.mql5.com
Основы языка / Операторы / Оператор-выражение - Документация по MQL5
 
alexvd:

Neste caso, tudo é válido. ; é um operador vazio.

Pensaremos na sua sugestão (emitir vorning), mas não é a mais alta prioridade neste momento.

Espero que não se esqueça de o fazer em MQL4, como foi logicamente feito em MQL4.


Pode aconselhar-nos a considerar duas ordens pendentes (preço, tipo e volume da sua execução são os mesmos)?

Quando o preço for atingido, ambos os eventos serão desencadeados, e como funcionará o evento OnTrade() neste caso?

Em particular, ordens pendentes que tenham sido executadas irão para a história num evento OnTrade() ou haverá duas chamadas? (os meus registos mostram uma chamada por alguma razão)

Obrigado pela sua resposta!