Quaisquer perguntas de recém-chegados sobre MQL4 e MQL5, ajuda e discussão sobre algoritmos e códigos - página 520

Novo comentário
 
Vitaly Muzichenko:

Qual é o mal de uma construção desse tipo?

Ou é melhor tornar adata um tipo longo?

Não vejo um problema até agora.
Mas há um desejo óbvio de precisão (a data é maior que o tempo_t, para dizer de forma suave).
e deve ser um pouco longo para comparações no tempo. Se o compilador otimizar algo, ele irá jogá-lo fora, e um depósito para o futuro permanece :-)
 
Maxim Kuznetsov:
Não vejo um problema até agora.
Mas há uma tendência óbvia para ser mais preciso (a data é suavemente maior que o tempo_t)
e é mais provável que este longo tempo seja usado para comparar os tempos. Se o compilador otimizar algo, ele o jogará fora e deixará um depósito para o futuro :-)

Então você pode usá-lo sem trapacear sem conseqüências?

 
Vitaly Muzichenko:

Então você pode usá-lo sem trapacear sem conseqüências?

Bem, como poderia ser sem consequências :-)

longo x = TimeCurrent(); já recebe um "tapa no rosto" em uma boa empresa :-) Não só os tipos são diferentes em física, mas também são diferentes em dimensão e você converte um tipo maior para um tipo menor.

Mas sim, todos os segundos a partir de (data/hora)TimeCurrent parecem caber em longo

 
Maxim Kuznetsov:

há uma grande função StringFind() - procura pela ocorrência da corda "#" ou imediatamente "de #".

Encontrado
StringFind(OrderComment(),"to #",0)


e o que fazemos com ele?

NoStringSubstr, tudo está claro, você recebe dígitos imediatamente - bilhete, mas aqui noStringFind , já sabemos que há"para #" no comentário

 
PolarSeaman:
Encontrado


e o que fazer com ele?

EmStringSubstr tudo está claro, recebemos os números imediatamente - bilhete, mas aqui emStringFind o que, já sabemos que há"para #" no comentário

mas não sabemos onde). StringFind nos dirá se o "to #" que estamos procurando está nesta posição ou não está de forma alguma lá. Nunca confie em algo que vem da rede e você, pessoalmente/pessoalmente, não o controla :-) Estamos jogando dinheiro aqui - isto é sério.

 
Maxim Kuznetsov:

mas não sei onde :-) StringFind lhe dirá que o "até #" que você está procurando é exatamente desta posição, ou não existe de todo. Nunca confie em algo que vem da rede e você, pessoalmente/pessoalmente, não o controla :-) Estamos jogando dinheiro aqui - isto é sério.

precisam destacar o bilhete do comentário e jogar fora o "to #".

o bilhete para uma posição aberta é comparado com o do comentário para uma posição fechada

por que estamos procurando o "to #"?

 

A funçãoStringSubstr retorna a parte correta do comentário. Por que esta função devolve o lucro de uma posição aberta e não o lucro de uma posição fechada? Estou passando porMODE_HISTÓRIA

double prof_cl_pos(string sy="0", int op=-1, int mn=-1) {
  datetime ta;
  int      i, k=OrdersHistoryTotal();
  double profit_=0;
  string comment="";
  string substr="";

  if (sy=="" || sy=="0") sy=Symbol();
  for (i=0; i<k; i++) {
    if (OrderSelect(i, SELECT_BY_POS, MODE_HISTORY)) {
      if (OrderSymbol()==sy) {
        if (OrderType()==OP_BUY || OrderType()==OP_SELL) {
          if (op<0 || OrderType()==op) {
            if (mn<0 || OrderMagicNumber()==mn) {
              comment=OrderComment();
               substr = StringSubstr(comment, 4, 9);
              if (ticket_op_pos(Symbol(), -1,mn)==substr)
              profit_=OrderProfit();
            }
          }
        }
      }
    }
  }
  return(profit_);
}
 
Vitaly Muzichenko:

Qual é o mal de uma construção desse tipo?

Ou é melhor tornar adata um tipo longo?

data é ulong - é aí que você deve colocá-la.
 
PolarSeaman:

o bilhete deve ser destacado do comentário e o "até #" deve ser descartado.

o bilhete para uma posição aberta deve ser comparado com o bilhete no comentário para uma posição fechada

por que estamos procurando o"to #"?

Estamos procurando por ela para descobrir "existe mesmo para# ou de#" no comentário. Se não houver, então esta ordem não faz parte de uma posição fechada e nós não precisamos dela.

Se o StringFind(OrderComment(), "#to") for maior ou igual a zero, significa que o comentário contém a sub-cordenação procurada, e só agora podemos calcular a posição do número do bilhete nesta string.

 
PolarSeaman:

A funçãoStringSubstr retorna a parte correta do comentário. Por que esta função devolve o lucro de uma posição aberta e não o lucro de uma posição fechada? Estou passando porMODE_HISTORY.

E esta é a resposta a esta pergunta.

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

Qualquer pergunta de novatos sobre MQL4, ajuda e discussão sobre algoritmos e códigos

PolarSeaman, 2018.04.07 00:25

Encontrado
StringFind(OrderComment(),"to #",0)


E o que fazer com ele?

Tudo está claro noStringSubstr, você recebe números - bilhete, mas aqui noStringFind what, já sabemos que há"to #" no comentário


Mas se não o fizer, você terá algo completamente diferente.

1...513514515516517518519520521522523524525526527...1953
Novo comentário