Fehler, Irrtümer, Fragen - Seite 257

 
alexvd:

Es sieht nicht danach aus.

Es stellte sich heraus, dass es nur 2 (von 45) Verlustgeschäften gab, die beide Käufe waren.

Vielleicht suche ich an der falschen Stelle?


Rot markiert: Short-Positionen sind 5 von 45. Nehmen wir an, 40 ist 95%. Frage - Warum 5 = 100 %, es ist logisch, - 5 % anzunehmen.

Obwohl es mir scheint, dass es in diesem Fall 5 (11,11 %) und 40 (88,89 %) sein sollten.

alexvd:

Versuchen Sie, den Cache zu löschen. Ich habe es mit verschiedenen Optionen und Browsern versucht - die Hinzufügung war erfolgreich.

Sie fügen ein Bild direkt in einen Kommentar ein und nicht als Anhang, nicht wahr?

Ja, im Text. Das werde ich versuchen, obwohl es in diesem Forum ohne Probleme hinzugefügt wurde... :)
 
Interesting:

Rot markiert: Short-Positionen sind 5 von 45. Sagen wir, 40 ist 95%. Frage - Warum 5 = 100%, es ist logisch, 5% anzunehmen.

Obwohl ich der Meinung bin, dass es 5 (11,11 %) und 40 (88,89 %) Abschlüsse geben sollte.

Insgesamt 45 Berufe:

  1. 5 beim Verkauf, 40 beim Kauf
  2. 2 unrentabel (2 zu kaufen), 43 rentabel (insgesamt).

Hier haben wir die folgenden Ergebnisse

5 Verkaufsgeschäfte - 5, und 100 % davon waren gewinnbringend (keine Verluste) (d. h. alle Geschäfte waren gewinnbringend).

Kaufgeschäfte - 40, 38 davon sind profitabel, d.h. 38*100%/40=95%.

Weitere

Gewinnbringende Geschäfte - 43 von 45, d. h. 43*100%/45 = 95,56%.

Verlustgeschäfte - 2 von 45, d.h. 2*100%/45 = 4,44%.

 
alexvd:

Insgesamt 45 Berufe:

  1. 5 beim Verkauf, 40 beim Kauf
  2. 2 Verlustgeschäfte (2 Kaufgeschäfte), 43 Gewinngeschäfte (insgesamt)

Die Gesamtzahl der Geschäfte, die wir

Verkauf von Geschäften - 5, davon gewinnbringende (nicht verlorene) Geschäfte - 100% (d.h. alle waren profitabel)

Kaufgeschäfte - 40, 38 davon sind profitabel, d.h. 38*100%/40=95%.

Weitere

Gewinnbringende Geschäfte - 43 von 45, d. h. 43*100%/45 = 95,56%.

Verlustgeschäfte - 2 von 45, d. h. 2*100%/45 = 4,44%.

Danke, jetzt ist es klar, was was ist...
 

Ich habe diesen Effekt festgestellt. Wenn ich den Indikator zum Diagramm(in einem separaten Fenster) hinzufüge, wird das Hauptkerzenchart nicht mehr aktualisiert (der Preis bleibt stehen), obwohl im Fenster mit den Kursen alles in Ordnung ist - der Preis wechselt von rot zu grün. Obwohl der Indikator nur dem Fenster eines Symbols hinzugefügt wurde, friert der Preis auch im anderen Fenster ein. Initialisierung und Berechnung des Indikators befinden sich innerhalb des Körpers: if(prev_calculated==0). Schlusskurse, die nicht vom Vortag stammen, nehmen an der Berechnung teil (der aktuelle Schlusskurs nimmt nicht teil). Nachdem die Berechnung des Indikators abgeschlossen ist, beginnt sich der Preis zu bewegen und verändert sich synchron mit dem Fenster.
Sie können es auf dem Bild sehen:

 
-Alexey-:

Ich habe diesen Effekt festgestellt. Wenn ich den Indikator zum Chart(in einem separaten Fenster) hinzufüge, wird der Haupt-Candlestick-Chart nicht mehr aktualisiert (der Preis bleibt stehen), während im Fenster mit den Kursen alles in Ordnung ist - der Preis wechselt von rot zu grün. Obwohl der Indikator nur dem Fenster eines Symbols hinzugefügt wurde, friert der Preis auch im anderen Fenster ein. Initialisierung und Berechnung des Indikators befinden sich innerhalb des Körpers: if(prev_calculated==0). Schlusskurse, die nicht vom Vortag stammen, nehmen an der Berechnung teil (der aktuelle Schlusskurs nimmt nicht teil). Nachdem die Berechnung des Indikators abgeschlossen ist, beginnt sich der Preis zu bewegen und verändert sich synchron mit dem Fenster.
Sie können es auf dem Bild sehen:

Die erste Berechnung erweist sich als sehr ressourcenintensiv. Prüfen Sie es, vielleicht ist der Code des Indikators nicht optimal geschrieben.

 
alexvd:

Die erste Berechnung erweist sich als sehr ressourcenintensiv. Prüfen Sie, ob der Code des Indikators nicht optimal geschrieben ist.

Sehr geehrte alexvd, leider hat der Indikator jetzt mehr als 3000 Zeilen Code mit mehr als 20 Klassen und es ist schwierig, den Code zu optimieren (mehrere hundert Milliarden Rechenoperationen in Schleifen), und diese Zahl kann bis zu 10000 ungefähr wachsen. Ich meinte, dass es möglich ist, die Aktualisierung der Kurse im Candlestick-Chart in einem separaten Programm-Thread und das Laden der Indikatorberechnungen in einem separaten Thread zu trennen. Ehrlich gesagt, hätte ich zu Beginn meiner Arbeit nicht gedacht, dass das Leistungsproblem auf einem Desktop-Computer so dringend auftreten würde, während ich auch einen kleinen Laptop verwenden möchte.
 
-Alexey-:
Ich meinte, dass es möglich ist, die Aktualisierung der Kurse im Candlestick-Diagramm in einem separaten Programmablauf und das Laden der Indikatorberechnungen in einem anderen Ablauf zu trennen.
Die Aktualisierung der Kurse im Diagramm ist lediglich eine Anzeige der Basisdaten des Terminals, auf deren Grundlage auch die Indikatoren berechnet werden. Um Ressourcen zu sparen, werden die Basisdaten des Terminals als Eingabedaten an den Indikator übergeben, d.h. sie können nicht geändert werden, bevor die Berechnung des Indikators abgeschlossen ist.
 
antt:
Die Aktualisierung der Kurse auf dem Chart ist lediglich eine Anzeige der Daten der Terminal-Datenbank, die auch zur Berechnung der Indikatoren verwendet wird. Um Ressourcen zu sparen, werden die Basisdaten des Terminals als Eingabedaten an den Indikator übergeben, d.h. sie können nicht geändert werden, bevor der Indikator berechnet wird.
Verstanden, danke!
 
-Alexey-:
Sehr geehrte alexvd, leider hat der Indikator jetzt mehr als 3000 Zeilen Code, die aus mehr als 20 Klassen bestehen, und es ist ziemlich schwierig, den Code zu optimieren (mehrere hundert Milliarden Rechenoperationen in Schleifen), während diese Zahl bis zu 10000 ungefähr wachsen kann. Ich meinte, dass es möglich ist, die Aktualisierung der Kurse im Candlestick-Chart in einem separaten Programm-Thread und das Laden der Indikatorberechnungen in einem separaten Thread zu trennen. Ehrlich gesagt hatte ich zu Beginn meiner Arbeit nicht erwartet, dass das Leistungsproblem auf einem Desktop-Computer so dringend auftreten würde, während ich auch ein kleines Notebook verwenden möchte.

Versuchen Sie, die Leistung des Indikators zu optimieren, die Anzahl der Objekte und Linien ist nicht wichtig. Höchstwahrscheinlich ist es möglich, den bestehenden Indikator (mit 3000 Zeilen) mit der erforderlichen Geschwindigkeit arbeiten zu lassen.

Eine interessante Variante ist, alle ressourcenintensiven Berechnungen in einen Timer zu packen (wenn es möglich erscheint), dann werden diese Berechnungen nicht bei jedem Tick ausgeführt.

Und ich möchte die Box des Rechners so weit wie möglich optimieren (in vernünftigen Grenzen).

 
Interesting:

Versuchen Sie, den Indikator zu optimieren, die Anzahl der Objekte und Linien ist nicht wichtig. Höchstwahrscheinlich ist es möglich, den bestehenden Indikator (mit 3000 Zeilen) mit der erforderlichen Geschwindigkeit arbeiten zu lassen.

Eine interessante Variante ist, alle ressourcenintensiven Berechnungen in einen Timer zu packen (wenn möglich), dann werden diese Berechnungen nicht bei jedem Tick ausgeführt.

Und der Rechnerblock sollte so weit wie möglich optimiert werden (innerhalb vernünftiger Grenzen).

Im Prinzip ist es möglich, die Arbeit ein wenig zu optimieren, da einige identische Daten in Objekten verschiedener Klassen, also nicht nur einmal, berechnet werden. Aber hier stehen wir vor einem anderen Problem, nämlich - weg von dem Konzept der vielen Blackboxen, von denen jeder kann debuggt werden und sicher sein, in ihm (dh jedes Objekt ist eine völlig autonome Einheit, und wenn die Berechnung einiger Zwischendaten, die in verschiedenen Objekten identisch ist, bewegen sich außerhalb von Objekten, Autonomie verloren gehen wird, so dass jede Klasse separat debuggen. In diesem Fall geht die Strukturierung des Programms verloren, d.h. ich kann nicht mehr nachvollziehen, was ich geschrieben habe, und der kleinste Fehler ist nicht mehr zu finden. Auch die Debugging-Geschwindigkeit wird sich drastisch erhöhen, da ich den gesamten Algorithmus ausführen muss und nicht nur einen kleinen Teil davon. So beeinflusst die Anzahl der Objekte die Geschwindigkeit.

Deshalb denke ich, dass eine ähnliche Optimierung in der Endphase versucht werden kann, wenn der Indikator vollständig erstellt, debuggt und getestet ist, aber leider ist es noch ein langer Weg (ich habe in der Anfangsphase seit etwa 4 Monaten gearbeitet, da ich endlich erkannt habe, dass ich bereit bin, es zu versuchen). In Büchern über Ökonometrie und Mathematik ist alles in Fragmenten in verschiedenen Büchern verstreut (es gibt keine praktisch einheitliche Darstellung des Materials im Detail), die Autoren haben Fehler und Unstimmigkeiten in Begriffen und Algorithmen, die von Anfängern nur durch Nachschlagen in enzyklopädischen Wörterbüchern gefunden werden, theoretische Informationen geraten in Konflikt mit der Möglichkeit ihrer praktischen Umsetzung, d.h. Umsetzung als numerische Methoden, und numerische Methoden selbst stellen ihrerseits Anforderungen an die Funktionalität der Softwareumgebung), der Prozess ist langwierig und zähflüssig.

Nach der Logik der Berechnung muss sie nach der Bildung jeder Kerze auftreten, daher sollte sie ursprünglich im Körper der Funktion "is new bar" platziert werden, aber die Tatsache, dass ihre Zeit dieses Intervall überschreiten kann, veranlasste mich, sie in den Körper der Funktion if(prev_calculated==0) zu platzieren, damit sie in der Phase der Fehlersuche nur einmal auftreten würde. Ich werde über Ihren Vorschlag für die Zeitschaltuhr nachdenken - danke.

Документация по MQL5: Основы языка / Функции
Документация по MQL5: Основы языка / Функции
  • www.mql5.com
Основы языка / Функции - Документация по MQL5
Grund der Beschwerde: