Cualquier pregunta de los recién llegados sobre MQL4 y MQL5, ayuda y discusión sobre algoritmos y códigos - página 520

Nuevo comentario
 
Vitaly Muzichenko:

¿Qué tiene de malo un diseño así?

¿O es mejor hacer deldatetime un tipo largo?

Hasta ahora no veo ningún problema.
Pero hay un evidente afán de precisión (datetime es mayor que time_t, por decirlo suavemente).
y más bien debería ser largo para las comparaciones de tiempo. Si el compilador optimiza algo, lo tira, y queda un depósito para el futuro :-)
 
Maxim Kuznetsov:
Hasta ahora no veo ningún problema.
Pero hay una tendencia obvia a ser más preciso (datetime es suavemente mayor que time_t)
y es más probable que este largo se utilice para comparar los tiempos. Si el compilador optimiza algo, lo tirará y dejará un depósito para el futuro :-)

¿Así que puedes usarlo sin hacer trampa sin consecuencias?

 
Vitaly Muzichenko:

¿Así que puedes usarlo sin hacer trampa sin consecuencias?

Bueno, cómo podría ser sin consecuencias :-)

long x = TimeCurrent(); ya recibe una "bofetada" en buena compañía :-) No sólo los tipos son diferentes en cuanto a la física, sino que también son diferentes en cuanto a la dimensión y se convierte un tipo más grande en uno más pequeño.

Pero sí, todos los segundos de (datetime)TimeCurrent parecen encajar en long

 
Maxim Kuznetsov:

hay una gran función StringFind() - buscar "#" o "de #".

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


¿y qué hacemos con él?

EnStringSubstr, todo está claro, se obtienen dígitos inmediatamente - billete, pero aquí enStringFind , ya sabemos que hay"a #" en el comentario

 
PolarSeaman:
Encontrado


¿y qué hacer con él?

EnStringSubstr todo está claro, obtenemos los números inmediatamente - billete, pero aquí enStringFind qué, ya sabemos que hay"a #" en el comentario

pero no sabemos dónde). StringFind nos dirá si el "to #" que buscamos está en esta posición o no está. Nunca te fíes de algo que viene de la red y que no controlas personalmente :-) Estamos jugando con dinero aquí - esto es serio.

 
Maxim Kuznetsov:

pero no sé dónde :-) StringFind le dirá que el "to #" que está buscando es exactamente de esta posición, o no está allí en absoluto. Nunca te fíes de algo que viene de la red y que no controlas personalmente :-) Estamos jugando con dinero aquí - esto es serio.

necesita resaltar el billete del comentario y tirar el "a #".

el ticket de una posición abierta se compara con el del comentario de una posición cerrada

¿por qué buscamos el"to #"?

 

La funciónStringSubstr devuelve la parte correcta del comentario. ¿Por qué esta función devuelve el beneficio de una posición abierta y no el beneficio de una posición cerrada? Estoy pasando porMODE_HISTORY

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:

¿Cuál es el perjuicio de esta construcción?

¿O es mejor hacer deldatetime un tipo largo?

datetime es ulong - ahí es donde debes ponerlo.
 
PolarSeaman:

el billete debe ser resaltado del comentario y el "to #" debe ser descartado.

el ticket de una posición abierta debe compararse con el ticket del comentario de una posición cerrada

¿por qué buscamos el"to #"?

Lo buscamos para saber si en el comentario hay "hasta# o desde#". Si no lo hay, entonces esta orden no forma parte de una posición cerrada y no la necesitamos.

Si el StringFind(OrderComment(), "#to") es mayor o igual a cero, significa que el comentario contiene la subcadena buscada, y sólo ahora podemos calcular la posición del número de ticket en esta cadena.

 
PolarSeaman:

La funciónStringSubstr devuelve la parte correcta del comentario. ¿Por qué esta función devuelve el beneficio de una posición abierta y no el beneficio de una posición cerrada? Estoy pasando porMODE_HISTORY.

Y esta es la respuesta a esta pregunta.

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Cualquier pregunta de los novatos en MQL4, ayuda y discusión sobre algoritmos y códigos

PolarSeaman, 2018.04.07 00:25

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


¿Y qué hacer con él?

Todo está claro enStringSubstr, se obtienen números - billete, pero aquí enStringFind qué, ya sabemos que hay"a #" en el comentario


Pero si no lo haces, obtendrás algo completamente diferente.

1...513514515516517518519520521522523524525526527...1954
Nuevo comentario