Fragen von Neueinsteigern zu MQL4 und MQL5, Hilfe und Diskussion über Algorithmen und Codes - Seite 1857
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
alles sammeln (oder sich erinnern/wissen), nach offener Zeit sortieren. Das ist so, aber die Öffnungszeit ändert sich nicht :-)
Wenn die EA-Logik mehr als 1 Auftrag enthält (z. B. Gitter), müssen Sie sich alle merken. Oder Sie müssen bei jedem Niesen langsamer werden und versuchen, sich alle zu merken.
Können Sie mir sagen, ob der blau eingekreiste Gewinn in der Historie Provisionen und Swaps enthält?
Die Zeit und der Preis des Auftrags, der mit der Funktion OrderSelect() ausgewählt werden soll, werden ermittelt.
Soweit ich weiß, wird dies in der Dokumentation nicht erwähnt. Es ist also besser, auf Nummer sicher zu gehen. Das macht die Sache nicht schlimmer.
Es gab Beschwerden, dass dieses Verfahren viel CPU-Zeit in Anspruch nimmt.
Was SL und TP betrifft, so werden sie berechnet. Daher sollten sie auf jeden Fall auf den Ziffernwert normiert werden.
Hier ist es auf jeden Fall notwendig, die Absicht des Autors herauszufinden.
Es gab Beschwerden, dass dieses Verfahren viel CPU-Zeit in Anspruch nimmt.
Die Normalisierung der berechneten SLs und TAs dauert doppelt so lange. Aber ich würde nicht sagen, dass es so viel Einfluss auf die Optimierung hat und noch weniger auf die Robotertests.
In der Dokumentation steht schwarz auf weiß, dass die berechneten Werte normalisiert werden sollen! Und was könnte die "Absicht des Autors" sein? Was ist nicht zu normalisieren SL und TP? Ich werde nicht mit Ihnen streiten, denn die Tatsachen sind hier offensichtlich!
Wenn dies eine Frage ist, dann holen Sie sich das Ticket des ersten, wählen Sie das erste und die folgenden, die das Ticket !=first haben.
Es dauert doppelt so lange, die berechneten SLs und TAs zu normalisieren. Aber ich würde nicht sagen, dass es einen großen Einfluss auf die Optimierung und noch weniger auf die Robotertests hat.
Ja, und es gab in diesem Forum Fragen zur Vereinfachung dieses Verfahrens.
Mir ist kein Fall bekannt, in dem empfangene Preise, die nicht normalisiert sind, einen Fehler verursacht haben.
Als Referenz:
Und was könnte in diesem Fall die "Absicht des Autors" sein? Dass SL und TP nicht zu normalisieren? Ich werde nicht mit Ihnen streiten, denn die Fakten sind offensichtlich!
Ein nachträglicher Gedanke könnte die Rundung sein. Theoretisch wird dies nicht gemacht, aber im Falle einer Rundung auf weniger Ziffern , wenn die Preise für SL und TP korrekt sind, wird dies funktionieren. Sie müssen also in jedem Fall herausfinden, was beabsichtigt ist.
Ich habe versucht, es selbst zu lösen, etwa in den Code dieses Indikators hinzufügen, aber es funktioniert nicht. Obwohl es kompiliert und keine Fehler.
Vielleicht sollten wir iCustom und handle indicator verwenden?
Wenn Sie versuchen, das Problem zu benennen und dann genauer beschreiben, was genau Sie nicht können, ist die Wahrscheinlichkeit, eine Antwort zu erhalten, viel höher.
Es dauert doppelt so lange, die berechneten SLs und TAs zu normalisieren. Aber ich würde nicht sagen, dass es sich so sehr auf die Optimierung auswirkt, geschweige denn auf Robotertests.
Darüber hinaus vernachlässigen manche Menschen so einfache Kontrollen wie
weil ich denke, dass es viel CPU-Zeit verbrauchen könnte :)
Aber eigentlich sind es Funktionen wie ObjectCreate und ObjectDelete, die Prozessorzeit verbrauchen. Wenn ein Programmierer z. B. ein Array mit grafischen Objekten hat und dieses bei jedem Tick gelöscht und neu erstellt wird, muss etwas dagegen unternommen werden. Während einfache Überprüfungen und Berechnungen wenig Zeit in Anspruch nehmen. Aus diesem Grund suchen viele Programmierer einfach an der falschen Stelle.
Ja, und es gab in diesem Forum Fragen zur Vereinfachung dieses Verfahrens.
Ich weiß nicht, auf wen oder was sie sich auswirkt. Ich habe nie Probleme mit NormaizeDouble gehabt. Wenn überhaupt, wirkt sich jeder Code auf die Geschwindigkeit einer Anwendung aus. Aber wenn alles so kritisch ist, können Sie die Handler OnTick oder OnCalculate leer lassen. In diesem Fall wird Ihre Bewerbung überhaupt nicht fliegen. :) Oder schreiben Sie die Funktionen in Assembler um, kompilieren Sie sie in eine DLL und verbinden Sie sie mit der Anwendung.
Mir sind keine Fälle bekannt, in denen empfangene und nicht normalisierte Preise einen Fehler verursacht haben.
Aber die Dokumentation schon! Und Sie ignorieren die Hinweise in der Dokumentation. Wie Sie wollen. Das ist Ihre Sache. Ich denke, es ist offensichtlich und ich werde nicht mit Ihnen darüber streiten, ich sage es noch einmal!
DieRundung kann ein nachträglicher Einfall sein.
Es wird nicht gerundet, sondern alles, was über zwei Dezimalstellen hinausgeht, wird abgeschnitten.
Ich kenne die Idee des Autors auch nicht. Aber ich brauche es nicht. Ich denke, er kann es selbst herausfinden.