Die Strategie muss mit JS umgesetzt werden, weil die Sprache selbst begrenzt ist.
Seit der Neuausführung der MAC-Strategien in JS wurden viele Probleme entdeckt. Im realen Betrieb wurde festgestellt, dass auf derselben K-Linie aufgrund von Volatilität 1-2 Käufe und Verkäufe zurückkommen. Dies führt zu Verlusten.
Wie ist es in der Ma-Sprache entworfen, um das zu vermeiden, und was ist die allgemeine Logik?
Oder: Wie kann ich mit JS verhindern, dass ich zweimal auf derselben K-Linie kaufe und verkaufe? Wie löst man das Problem, wenn man einen Auftrag mit einem Zeitfenster bearbeitet und feststellt, dass der Auftrag ohne Zeitfenster ist? Wie ist die logische Idee?
Weiwei, das ist nicht wahr.Ein weiteres Problem besteht darin, dass man mit dem folgenden Code verhindern kann, dass ein ständiger Handel auf der gleichen K-Linie durch einen kleinen Schwank verursacht wird. Aber es gibt ein neues Problem, dass man, wenn die gleiche K-Linie gerade ist, sofort einen Rückgriff machen möchte, der begrenzt ist, und man muss warten, bis die nächste K-Linie frei ist. Oder wenn man gerade ist, wenn man mehr auf der gleichen K-Linie zurückgreifen möchte, der auch begrenzt ist, muss man warten, bis die nächste K-Linie frei ist, und oft verpasst man den besten Kaufpunkt. Der Code lautet: if (before_record_time!= now_records.Time) // Die Zeit der letzten K-Zeile ist nicht gleich der falschen Zeit dieser K-Zeile, also für eine andere K-Zeile - Was ist los? Wenn wir hier die Geschäftslogik für das Ausgleichsverfahren schreiben, dann können wir nicht wiederholt das gleiche Ausgleichsverfahren auf der K-Linie durchführen. Wir sind hier. Meine Lösung ist die folgende: Die K-Zeitlinie, die zuvor eine Variablenspeicherung hatte, wird jetzt in zwei Variablen gespeichert. Eine mehrseitige Zeitschrift duo_before_record_time Eine Zeit, die in die leere Richtung geht Kong_before_record_time Wenn wir mehr machen, dann verwenden wir diese Einschränkung, dass die gleichen K-Linien, die Positionen, die in die gleiche Richtung gehen, nach dem Gleichgewicht, nicht in die gleiche Richtung gehen. Der Code lautet: if (duo_before_record_time!= now_records.Time) // Die Zeit der letzten K-Zeile ist nicht gleich der Zeitfehler dieser K-Zeile. - Was ist los? Wenn wir hier die Geschäftslogik für das Ausgleichsverfahren schreiben, dann können wir nicht wiederholt das gleiche Ausgleichsverfahren auf der K-Linie durchführen. Wir sind hier. Wenn wir das machen, dann beschränken wir es auch, dass wir nicht die gleichen Positionen in die entgegengesetzte Richtung nehmen, wenn wir auf derselben K-Linie ausgerichtet sind. if (kong_before_record_time!= now_records.Time) // Die Zeit der letzten K-Zeile ist nicht gleich der Zeitfehler dieser K-Zeile, also für eine andere K-Zeile - Was ist los? Wenn wir hier die Geschäftslogik für das Ausgleichsverfahren schreiben, dann können wir nicht wiederholt das gleiche Ausgleichsverfahren auf der K-Linie durchführen. Wir sind hier. So kann die gleiche K-Linie nach einem Ausgleich sofort eine Position in der entgegengesetzten Richtung eröffnen, wenn die Bedingungen für die Eröffnung erfüllt sind. Aber keine Position in derselben Richtung wird eröffnet. Ich hoffe, meine Frage hilft auch meinen späteren Freunden.
Das GrasDie Anzeige antwortet dir.
Ein kühler GeistDie Querschnittsachse der K-Linie ist die Zeit, also sollte man sie mit Zeit lösen.
Weiwei, das ist nicht wahr.Der Code lautet: if (before_record_time!= now_records.Time) // Die Zeit der letzten K-Zeile ist nicht gleich der Zeitfehler dieser K-Zeile, also für eine andere K-Zeile. - Was ist los? Wenn wir hier die Geschäftslogik für das Ausgleichsverfahren schreiben, dann können wir nicht wiederholt auf derselben K-Linie ausgleichsweisen. Wir sind hier.
Weiwei, das ist nicht wahr.Es wurde eine bessere Lösung gefunden, indem man zunächst eine Variable deklariert, die für die Zeitstange der aktuellsten K-Linie verwendet wird, die zum Zeitpunkt der Auftragserteilung gespeichert wird (unabhängig davon, ob man mehrere Leerstandsöffnungen macht, solange die Auftragserstellung diese Variable überdeckt), und dann entscheidet, dass die Zeitstange der letzten Auftragsöffnung nicht gleich der Zeitstange der aktuellen K-Linie ist.
Weiwei, das ist nicht wahr.Übrigens, mit exchange.GetOrders (().length>0 wird festgestellt, dass es keine ausstehenden Bestellungen gibt und die Bestellzeit gespeichert.
Weiwei, das ist nicht wahr.Nach langer Suche wurde die Lösung gefunden, und der Code lautet: wenn (Math.abs ((before_order_time - now_records.Time)/1000 > now_period)) // Die Zeitstärke des letzten Auftrags subtrahiert die Zeitstärke der aktuellen K-Linie und subtrahiert sie durch 1000, um die Anzahl der Sekunden zu erhalten, und subtrahiert den Abstand zwischen beiden, wenn sie größer als die Anzahl der Sekunden der Periode sind und nicht auf derselben K-Linie sind. // muss die Variable before_order_time selbst einstellen, und speichert jedes Mal nur die vorgeordnete Zeitleiste. before_order_time = Date.parse ((new Date)))); // zeichnet die aktuelle Zeitleiste auf // die Anzahl der Sekunden für die Periodenzahl, die durch var now_period = _C ((exchange.GetPeriod) ermittelt wird); // die aktuelle Periode, z. B. 5 Minuten, 15 Minuten, 1 Tag, erhält und die Anzahl der Ergebnisse als Sekunden zurückgibt.
Der Sommer schlägt dich nicht.Es sollte möglich sein, die Interception durch eine Zeitstange in den K-Strangdaten durchzuführen.