Fragen von Neueinsteigern zu MQL4 und MQL5, Hilfe und Diskussion über Algorithmen und Codes - Seite 520

 
Vitaly Muzichenko:

Was ist an einem solchen Entwurf so schlimm?

Oder ist es besser,datetime zu einem langen Typ zu machen?

Bis jetzt sehe ich kein Problem.
Aber es gibt ein offensichtliches Verlangen nach Genauigkeit (datetime ist größer als time_t, um es gelinde auszudrücken).
und es sollte für Zeitvergleiche eher lang sein. Wenn der Compiler etwas optimiert, wirft er es weg, und es bleibt ein Depot für die Zukunft :-)
 
Maxim Kuznetsov:
Bis jetzt sehe ich kein Problem.
Aber es gibt eine offensichtliche Tendenz, genauer zu sein (datetime ist sanft größer als time_t)
und es ist wahrscheinlicher, dass diese Länge zum Vergleich der Zeiten verwendet werden sollte. Wenn der Compiler etwas optimiert, wirft er es weg und hinterlässt ein Depot für die Zukunft :-)

Sie können es also ohne Konsequenzen nutzen, ohne zu schummeln?

 
Vitaly Muzichenko:

Sie können es also ohne Konsequenzen nutzen, ohne zu schummeln?

Nun, wie könnte es ohne Konsequenzen sein :-)

long x = TimeCurrent(); bekommt schon eine "Ohrfeige" in guter Gesellschaft :-) Die Typen unterscheiden sich nicht nur in der Physik, sondern auch in den Abmessungen, und Sie wandeln einen größeren Typ in einen kleineren um.

Aber ja, alle Sekunden aus (datetime)TimeCurrent scheinen in long zu passen

 
Maxim Kuznetsov:

Es gibt eine großartige Funktion StringFind() - suchen Sie nach "#" oder "von #".

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


und was machen wir damit?

InStringSubstr, ist alles klar, Sie erhalten Ziffern sofort - Ticket, aber hier inStringFind , wissen wir bereits, dass es"zu #" in den Kommentar

 
PolarSeaman:
Gefunden


und was ist damit zu tun?

InStringSubstr ist alles klar, wir bekommen die Zahlen sofort - Ticket, aber hier inStringFind was, wir wissen bereits, dass es"zu #" im Kommentar ist

aber wir wissen nicht, wo.) StringFind sagt uns, ob sich das gesuchte "to #" an dieser Stelle befindet oder nicht. Verlassen Sie sich nie auf etwas, das aus dem Netz kommt und das Sie persönlich nicht kontrollieren :-) Wir spielen hier mit Geld - das ist eine ernste Sache.

 
Maxim Kuznetsov:

aber ich weiß nicht, wo :-) StringFind sagt Ihnen, dass das gesuchte "to #" genau an dieser Stelle steht, oder dass es gar nicht existiert. Verlassen Sie sich nie auf etwas, das aus dem Netz kommt und das Sie persönlich nicht kontrollieren :-) Wir spielen hier mit Geld - das ist eine ernste Sache.

Sie müssen das Ticket im Kommentar hervorheben und das "to #" weglassen.

das Ticket für eine offene Position wird mit dem Ticket im Kommentar für eine geschlossene Position verglichen

Warum suchen wir überhaupt nach dem "to #"?

 

Die FunktionStringSubstr gibt den rechten Teil des Kommentars zurück. Warum gibt diese Funktion den Gewinn einer offenen Position zurück und nicht den Gewinn einer geschlossenen Position? Ich gehe durchMODE_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:

Was ist der Schaden einer solchen Konstruktion?

Oder ist es besser,datetime zu einem langen Typ zu machen?

datetime ist ulong - dort sollten Sie es einfügen.
 
PolarSeaman:

Das Ticket sollte aus dem Kommentar hervorgehoben werden und das "to #" sollte entfallen.

das Ticket für eine offene Position sollte mit dem Ticket im Kommentar für eine geschlossene Position verglichen werden

Warum suchen wir überhaupt nach dem"to #"?

Wir suchen danach, um herauszufinden, ob der Kommentar überhaupt von# oder nach# lautet. Wenn dies nicht der Fall ist, dann ist dieser Auftrag nicht Teil einer geschlossenen Position und wir brauchen ihn nicht.

Wenn StringFind(OrderComment(), "#to") größer oder gleich Null ist, bedeutet dies, dass der Kommentar den gesuchten Teilstring enthält, und erst jetzt können wir die Position der Ticketnummer in diesem String berechnen.

 
PolarSeaman:

Die FunktionStringSubstr gibt den rechten Teil des Kommentars zurück. Warum gibt diese Funktion den Gewinn einer offenen Position zurück und nicht den Gewinn einer geschlossenen Position? Ich gehe durchMODE_HISTORY.

Und das ist die Antwort auf diese Frage.

Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests

Alle Fragen von Neulingen zu MQL4, Hilfe und Diskussion über Algorithmen und Codes

PolarSeaman, 2018.04.07 00:25

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


Und was ist damit zu tun?

Alles ist klar, inStringSubstr, erhalten Sie Zahlen - Ticket, aber hier inStringFind was, wir wissen bereits, dass es"zu #" in den Kommentar


Aber wenn Sie das nicht tun, werden Sie etwas ganz anderes bekommen.

Grund der Beschwerde: