Características da linguagem mql4, sutilezas e técnicas - página 6

[fxsaber]

fxsaber:
Ao contrário da MQL5, nas matrizes estáticas MQL4 as matrizes podem mudar de tamanho.

Nem sempre

Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial

Nova versão da plataforma MetaTrader 5 build 1595: acesso ao histórico de preços

fxsaber, 2017.05.01 16:36

#property strict

template <typename T>
struct ARRAY
{
  T Simple[100];
};

void OnStart()
{
  int ArraySimple[100];
  ARRAY<int> Array;

  Print(ArrayResize(Array.Simple, 10)); // MQL4: -1
  Print(ArrayResize(ArraySimple, 10));  // MQL4: 10
  
  Print(ArraySize(ArraySimple));        // MQL4: 10
  Print(ArraySize(Array.Simple));       // MQL4: 100
}

[Konstantin Erin]

Sempre houve um bug no MT4 na Trailing Stop. Se você observar durante um forte movimento de preços para cima e para baixo,
você pode ver o SL se movendo para cima e para baixo. Aqui, um pequeno movimento, acontece muitas vezes maior
2017.05.22 10:53:38.563 '9898616': parada móvel #1465775202 -> 1.29765
2017.05.22 10:53:38.483'9898616': parada móvel #1465775202 -> 1.29764
2017.05.22 10:53:33.236'9898616': parada móvel #1465775202 -> 1.29763
2017.05.22 10:53:33.130'9898616': parada móvel #1465775202 -> 1.29764
2017.05.22 10:53:32.813 '9898616': parada móvel #1465775202 -> 1.29762
Obtive-o quando SL = 2 (último dígito para simplificar), no próximo sinal o preço subiu e o terminal deu uma ordem para aumentar SL para 4.
No próximo tick, o preço caiu, mas SL ainda está em 2. O terminal emite uma ordem para elevar o SL para 3.
O servidor, como uma girafa de pescoço comprido, processou o primeiro pedido e elevou o SL para 4. O servidor processou o segundo pedido e diminuiu o SL para 3.
Portanto, o terminal envia ordens sem sentido extra e aumenta a carga no servidor.
Além disso, há o risco de perdas desnecessárias para o comerciante por causa do movimento inverso do SL.
Isto também se aplica ao rastreamento de programas pela EA ou roteiro . Em parte, nós o corrigimos movendo SL em passos de 3...5 pips.

O que fazer. Salvando o valor do SL, emitido na última OrderModify.
E então calcular a próxima ordem com base neste valor.
Seria assim: dois pedidos a menos para o servidor, movendo o SL apenas para frente, reduzindo a carga da CPU no computador
2017.05.22 10:53:38.563 '9898616': parada móvel #1465775202 -> 1.29765
2017.05.22 10:53:33.130 '9898616': parada móvel #1465775202 -> 1.29764
2017.05.22 10:53:32.813 '9898616': parada móvel #1465775202 -> 1.29762

[Vasiliy Pushkaryov]

Ao modificar os pedidos, muitas vezes é necessário comparar o TP/SL anterior com o novo valor a ser modificado. Se tentarmos modificá-lo com o valor antigo, teremos o erro nº 1.

Tomemos o exemplo de comparar o antigo SL (100,03) e o novo SL (100,02) por USDJPY (Dígitos = 2). Está escrito na ajuda:

O segundo método envolve a comparação da diferença normalizada de dois números reais com um valor zero. Comparar a diferença de números normalizados com zero é inútil, pois como resultado de qualquer operação matemática com números normalizados, o resultado é não-normalizado.

Ou seja, a comparação deve ser feita desta forma:

if(NormalizeDouble(100.03 - 100.02, Digits) != 0) // можно модифицировать

Mas às vezes o corretor pode dar preços não-normalizados. E por exemplo, temos o preço 100.025, não 100.02. Tendo comparado de acordo com o esquema acima, obteremos a diferença de 0,01, ou seja, podemos modificá-lo. Mas tendo passado para modificação normalizada para os dígitos 100.025, na verdade passaremos 100.03 e, conseqüentemente, teremos o erro número 1.

Em geral, pela experiência até agora, cheguei à conclusão de que em Dígitos iguais para modificações é melhorcomparar a diferença de números normalizados com zero (o que a ajuda não recomenda fazer).

Roteiro a ser verificado:

void OnStart()
{
  double a = 0.02;
  double b = 0.015;
  
  Print(" norm1 dif=", ND(a - b));            // результат = 0.01
  Print(" norm2 dif=", ND(a) - ND(b));        // результат = 0.0
}

double ND(double d) {return NormalizeDouble(d, 2);}

[Yurij Kozhevnikov]

if(MathAbs(a-b)>=Point)

[Vasiliy Pushkaryov]

Yurij Kozhevnikov:

Sim, você pode fazer isso. Esta é a primeira forma de comparação dada na ajuda. Eu estava apenas apontando a verdadeira armadilha da normalização numérica em que eu mesmo caí, usando o segundo método recomendado na documentação.

[Artyom Trishkin]

Comentários não relevantes para este tópico foram movidos para "Organização do ciclo do pedido".

[fxsaber]

Ao contrário do OrderProfit() no MT4 OrderComission() armazena dados não arredondados para centavos.

SZZ In OrderPrint() a comissão é arredondada (como na GUI).

[Artyom Trishkin]

fxsaber:

Ao contrário do OrderProfit() no MT4 OrderComission() armazena dados não arredondados para centavos.

SZZ In OrderPrint() a comissão é arredondada (como na GUI).

Portanto, o que devo fazer para obter o valor correto de OrderProfit()+OrderComission()+OrderSwap()?

[fxsaber]

Artyom Trishkin:

Assim, para obter o valor correto de OrderProfit()+OrderComission()+OrderSwap(), o que deve ser feito?

Nada! Este é o valor mais correto. Graças a esta comissão, podemos ver na GUI que a comissão total difere em um centavo da soma dos números mostrados pela GUI.

[Artyom Trishkin]

fxsaber:

Nada! Este é o valor mais correto. Graças a esta comissão, você pode observar na GUI que a comissão total difere em um centavo da soma dos números que a GUI mostra.

Então eu não entendo nada disso. O que você quer dizer com "OrderCommission() armazena dados não arredondados a centavos"? Onde eles são arredondados? E como eles são arredondados?