Vergleich von gleitendem Durchschnitt (und anderen Indikatoren) und Fehler - Seite 4
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
Danke für den Rat, aber ich kann die Hilfe selbst lesen. Und ich wiederhole: Computermathematik ist nicht an eine bestimmte Programmiersprache gebunden. Es sind nur die Berechnungsfehler, mit denen ich zurechtkommen muss, die Sie übergehen werden.
Wenn Sie die Hilfe nicht nur lesen, sondern auch verstehen können, dann betreiben Sie bewusste Demagogie, indem Sie hartnäckig und abwertend über die Normalisierung und ihre Anwendungsmöglichkeiten sprechen. Dazu gehört auch die absichtliche Demagogie über die Gefahren ihrer Anwendung.
Und ich bin nicht schlau, sondern gebe Gegenbeispiele (auch für Ihre geliebte Normalisierung).
Die Demagogie war da. Es gab keine Gegenbeispiele zur Normalisierung.
Abgesehen von der Tatsache, dass jemand sie falsch anwenden kann.
Die Epsilons können also falsch angewendet werden. Ja, und die Demagogie wurde bereits erwähnt.
P./S.: In diesem Beitrag geht es um Normalisierung, daher erwähne ich keine gleitenden Durchschnitte.
Und ich denke, dass Artem Ihnen besser mit EAs helfen kann, die MAs verwenden, als ich es mit diesen schwierigen EAs kann.
Achten Sie bei jedem Tick auf Überkreuzungen. Wo liegt das Problem?
Beim Vergleich zweier reeller Zahlen ist es nie notwendig, etwas zu normalisieren.
Wenn Zahlen wirklich gleich sind, werden sie auch gleich im Speicher abgelegt. Tatsächlich ist es gerade diese Eigenschaft, die die Existenz von Rechenmaschinen ermöglicht.
Daher sind Vergleiche der Form if(a<b) oder if(a==b) in jedem Fall korrekt und es ist keine Normalisierung erforderlich.
Wenn der wissbegierige Geist eines Forschers einen Widerspruch zu dieser Regel findet, bedeutet dies, dass entweder seine Maschine nicht in Ordnung ist oder sein Geist. Einer von beiden.
Hilfe und Dokumentation sollten natürlich zumindest ab und zu gelesen werden (sie wurden auch von Humanoiden wie uns geschrieben), aber es ist notwendig, seine eigenen vernünftigen Überlegungen anzustellen.
Wenn Sie die Hilfe nicht nur lesen, sondern auch verstehen können, dann betreiben Sie bewusste Demagogie, indem Sie hartnäckig und abwertend über die Normalisierung und ihre Anwendungsmöglichkeiten sprechen. Dazu gehört auch die absichtliche Demagogie über die Gefahren ihrer Anwendung.
Die Demagogie war da. Es gab keine Gegenbeispiele zur Normalisierung.
Ganz zu schweigen von der Tatsache, dass jemand es vielleicht nicht richtig benutzt.
Die Epsilons können also falsch angewendet werden. Und die Demagogie wurde bereits erwähnt.
Es gibt Gegenbeispiele (zumindest in Bezug auf die Normalisierung auch der Differenz, wie hier geäußert). Ich sage es noch einmal: Die Normalisierung ist der einfachste Weg für diejenigen, die sich nicht mit den Feinheiten befassen wollen. Er hat die Unterlagen gelesen und glaubt fromm alles. Ich wiederhole, dass die Programmiersprache in der Computermathematik irrelevant ist. Wenn es so in der Hilfe steht, heißt das noch lange nicht, dass es wahr ist (sonst gäbe es keine Rechenaufgaben und Epsilon-Probleme, die Sie so sehr hassen). Es wird auch viel über den Zaun geschrieben, aber das bedeutet nicht, dass es in letzter Konsequenz die Wahrheit ist. Wenn Sie mit der Halp-Option zufrieden sind, haben Sie allen Grund dazu. Aber das ist Ihre persönliche Entscheidung. Und es bedeutet auch nicht, dass es alle Probleme löst, die ich hier versucht habe, deutlich zu machen. Und etwas als Demagogie zu bezeichnen, das man einfach nicht verstehen will (auch das ist Ihr Recht), bedeutet nicht, dass es selbst Demagogie ist. Ich stelle keine rhetorischen Fragen über den Sinn des Lebens (deren Antworten nur Demagogie sind), ich versuche nur, etwas zu verstehen, das mir noch nicht begegnet ist. Nochmals: Nehmen wir an, die Werte sind immer gleich, wenn Sie sie berechnen. Dort könnte man etwas aus der gleichen Berechnungsmathematik herausholen. Aber wenn auch die Werte unterschiedlich sind, wird man nicht in der Lage sein, einen universellen Algorithmus zu entwickeln, selbst wenn man ein Mega-Guru ist.
Außerdem möchte ich nur sicherstellen, dass mein Verständnis, dass, wenn ein Roboter nicht durch Ticks arbeiten, immer mehrere Schnittpunkte innerhalb einer Bar ist im Grunde unmöglich. Sie ist bereits rein auf die Feinheiten von mql zurückzuführen.
P.S. Ich versuche nicht, mit jemandem grundlos zu streiten, ich halte mich nicht immer für ein rechtes Genie. Ich mag es einfach nicht, wenn Leute versuchen, clever zu sein und etwas zu schreiben, ohne es überhaupt zu lesen. Das hat nichts mit Ihnen persönlich zu tun. Ich danke Ihnen für Ihre Hilfe und Ihre Gedanken zu diesem Thema. Dennoch ist es IMHO falsch, etwas über Geduld zu schreiben, wenn Sie in der Dokumentation nur auf einem Standpunkt bestehen (den Sie von ganzem Herzen vertreten und keine alternativen Ansichten und Beispiele akzeptieren), und Epsilons sind nicht nach Ihrem Geschmack. Ich hoffe, Artyom versteht auch, was ich in dem Postskriptum davor geschrieben habe. Ich danke Ihnen allen für Ihre Antworten und bitte um Verzeihung, wenn ich irgendwo ein wenig gereizt war.
P.P.S. Die Normalisierung auf eine bestimmte Dezimalstelle ist in der Tat analog zur Einführung von Epsilon, nur in der Reihenfolge desselben Vorzeichens.
P.P.P.S. Wenn wir so eine hitzige Diskussion haben, wäre ich sehr dankbar, wenn Sie Ihre Erfahrungen in diesem Thema zu teilen, weil richtige Antworten (vor allem auf die 2 und 3 Punkte, die mich stören), in der Tat, nicht bekommen. Obwohl ich viele Foren durchforstet habe, bin ich fast zu dem Schluss gekommen, dass 2 Punkte unmöglich sind. Entwickler von mql könnte darüber nachdenken, und bieten mehr Flexibilität, denn es ist sehr unbequem (in jeder anderen Programmiersprache hat die Fähigkeit, dynamisch die Programmoberfläche zu ändern, und hier stellt sich heraus, es gibt keine ((()))
Es gibt Gegenbeispiele (zumindest in Bezug auf die Normalisierung auch von Unterschieden, wie hier geäußert). Ich sage es noch einmal: Die Normalisierung ist der einfachste Weg für diejenigen, die sich nicht mit den Feinheiten befassen wollen. Er hat die Unterlagen gelesen und glaubt fromm alles. Ich wiederhole, dass die Programmiersprache in der Computermathematik irrelevant ist. Wenn es so in der Hilfe steht, heißt das noch lange nicht, dass es wahr ist (sonst gäbe es keine Rechenaufgaben und Epsilon-Probleme, die Sie so sehr hassen). Es wird auch viel über den Zaun geschrieben, aber das bedeutet nicht, dass es in letzter Konsequenz die Wahrheit ist. Sie sind mit der Halp-Option zufrieden, und Sie haben auch allen Grund dazu. Aber das ist Ihre persönliche Entscheidung. Und es bedeutet auch nicht, dass es alle Probleme löst, die ich hier versucht habe, deutlich zu machen. Und etwas als Demagogie zu bezeichnen, das man einfach nicht verstehen will (auch das ist Ihr Recht), bedeutet nicht, dass es selbst Demagogie ist. Ich stelle keine rhetorischen Fragen über den Sinn des Lebens (deren Antworten nur Demagogie sind), ich versuche nur, etwas zu verstehen, das mir noch nicht begegnet ist. Nochmals: Nehmen wir an, die Werte sind immer gleich, wenn Sie sie berechnen. Dort kann man etwas von der gleichen Computermathematik lernen. Wenn aber auch die Werte unterschiedlich sind, wird man nicht in der Lage sein, einen universellen Algorithmus zu entwickeln, selbst wenn man ein Mega-Guru ist.
Außerdem möchte ich nur sicherstellen, dass mein Verständnis, dass, wenn ein Roboter nicht durch Ticks arbeiten, immer mehrere Schnittpunkte innerhalb einer Bar ist im Grunde unmöglich. Sie ist bereits rein auf die Feinheiten von mql zurückzuführen.
P.S. Ich versuche nicht, mit jemandem grundlos zu streiten, ich halte mich nicht immer für ein rechtes Genie. Ich mag es einfach nicht, wenn Leute versuchen, clever zu sein und etwas zu schreiben, ohne es überhaupt zu lesen. Das hat nichts mit Ihnen persönlich zu tun. Ich danke Ihnen für Ihre Hilfe und Ihre Gedanken zu diesem Thema. Dennoch ist es IMHO falsch, etwas über Geduld zu schreiben, wenn Sie in der Dokumentation nur auf einem Standpunkt bestehen (den Sie von ganzem Herzen vertreten und keine alternativen Ansichten und Beispiele akzeptieren), und Epsilons sind nicht nach Ihrem Geschmack. Ich hoffe, Artyom versteht auch, was ich in dem Postskriptum davor geschrieben habe. Ich danke Ihnen allen für Ihre Antworten und entschuldige mich, wenn ich irgendwo ein wenig gereizt war.
P.P.S. Die Normalisierung auf eine bestimmte Dezimalstelle ist in der Tat analog zur Einführung von Epsilon, nur in der Reihenfolge desselben Vorzeichens.
P.P.P.S. Wenn wir so eine hitzige Diskussion haben, wäre ich sehr dankbar, wenn Sie Ihre Erfahrungen in diesem Thema zu teilen, weil richtige Antworten (vor allem auf die 2 und 3 Punkte, die mich stören), in der Tat, nicht bekommen. Obwohl ich viele Foren durchforstet habe, bin ich fast zu dem Schluss gekommen, dass 2 Punkte unmöglich sind. Die mql-Entwickler könnten darüber nachgedacht haben, und bieten mehr Flexibilität, denn es ist sehr unbequem (in jeder anderen Programmiersprache hat die Fähigkeit, dynamisch die Programmoberfläche zu ändern, und hier stellt sich heraus, es gibt keine ((()))
Für mich ist die Datenkonvertierung mit der Funktion NormalizeDouble beim Vergleich von Doubles eine von zwei Möglichkeiten, die in der Dokumentation angegeben sind, um Programmbedingungen so zu gestalten, dass sie genau dort und so funktionieren, wie es beim Schreiben bestimmter Bedingungen im Code vorgesehen war. Das ist es, was ich vorhin meinte. Es geht also nicht nur um die Beseitigung von Fehlern. Es gibt auch verschiedene durchdachte Möglichkeiten, Daten umzuwandeln, um beliebige Bedingungen zu erfüllen.
Ich habe Ihnen davon erzählt und erzähle Ihnen davon, basierend auf meiner persönlichen praktischen Erfahrung in der Programmiersprache, die Sie gerade erst lernen. Aus diesem Grund, und schlug wiederholt in diesem Thread, um eine solche praktische Art und Weise zu verwenden.
Im Übrigen stimme ich Ihnen teilweise zu, dass ich nicht bestreiten werde, dass die Normalisierung mit dieser Funktion der einfachste Weg für alle Aufgaben in Bezug auf die Transformation von Daten des realen Typs ist
Es ist jedoch jedem selbst überlassen, welche der beiden in der Dokumentation empfohlenen Methoden er bei der Konvertierung von Daten realer Typen verwendet.
Und die Wahl eines dieser Wege ist nicht ausschlaggebend dafür, ob man zu den Menschen gehört, die versuchen, die notwendigen Feinheiten herauszufinden oder nicht.
Dass ich Epsilons nicht mag, war kein Wort von mir. Die Nichtanwendung einer Methode bedeutet nicht unbedingt Liebe/Abneigung. Ich habe auch nicht darauf bestanden, nur die zweite der beiden Möglichkeiten anzuwenden.
Meine wörtlichen Worte in Bezug auf die praktische Anwendung der Besonderheiten der Arbeit mit Zahlen des Typs double, dass:
P./S.: Es hat sich herausgestellt, dass die erste Methode aus der Dokumentation für mich weniger geeignet ist, auch im Hinblick auf Aufgaben, die ich in der Regel selbst löse. Daher habe ich mit dem ersten Weg nicht viel Erfahrung.
Bei der Anwendung der zweiten Methode (d. h. dem Vergleich der normierten Differenz zweier reeller Zahlen mit dem Wert Null im Ausdruck des bedingten Operators) traten jedoch keine Probleme auf.
Aber wenn ich einen Vergleich von nicht-normalisierten Zahlen (hier meine ich, ohne die erste Art und Weise zu verwenden), dann ja, es war, dass ich gefunden falsche Arbeit der Bedingungen auf der Grundlage von Vergleichen von Zahlen des Typs double.
Außerdem habe ich auch eine solche Klarstellung gegeben:
P./S.: Das heißt, nur für den Fall, werde ich noch einmal klarstellen, dass der Vergleich von reellen Zahlen durch die erste der beiden hier aufgeführten Methoden, durch denVergleich der Differenz von Zahlen mit einigen kleinen Wert, kann ich nicht als schlechter als mit Normalisierung, wenn Sie brauchen, um das Niveau des Vergleichs (inkl., da für mich die zweite Methode war bequemer, habe ich nicht für mich mehr detailliert für die praktische Anwendung).
Das heißt, im Hinblick auf die Normalisierung bei der Konvertierung von Doppeldaten brauchte ich die erste Möglichkeit nicht. Insbesondere wegen der Bequemlichkeit für mich bei der Verwendung der Funktion NormalizeDouble bei der Lösung verschiedener Probleme (und nicht nur bei Vergleichen).
Diese Website verfügt über einen riesigen Wissensschatz.
Mit MQL4 wurden alle Arten von Problemen unterschiedlicher Komplexität gelöst.
Nachdem MQL4 an MQL5 angenähert wurde, haben sich die Möglichkeiten der ersten Version noch mehr erweitert.
Ich denke, Sie sollten sich mit dieser Programmiersprache besser vertraut machen und das auf den Seiten hier angesammelte Wissen nicht ignorieren. Sammeln Sie praktische Erfahrungen mit der Anwendung des Systems. Und erst dann kann man getrost etwas zu den Anwendungen dieser Programmiersprache und ihren Möglichkeiten sagen.
Ich habe eine andere ToR) Und wieder habe ich bereits über die Probleme mit Zecken geschrieben. Sie können dem Kunden nicht erklären, warum der Roboter den Handel eingegangen ist, wenn er den Crossover nicht auf dem Chart sieht.
Nehmen Sie die MA-Werte am Nullpunkt und am ersten Balken auf jedem Tick - dann und nur dann können Sie Kreuzungen von MAs am Nullpunkt finden. Man nimmt sie vom ersten Balken zum Zeitpunkt der Eröffnung des Nullbalkens - und dort sind die MA-Werte diejenigen, die vorhanden waren, als der erste Balken geschlossen wurde, nicht als er gebildet wurde. Sie lesen die МАšek-Werte einfach zu spät und sehen daher nicht, wie sie sich kreuzen. Die Normalisierung hat damit nichts zu tun. Und übrigens, wenn MAs Preiswerte anzeigen, dann sollten die Werte auf _Digits normalisiert werden, anstatt zu raten, auf welchen Wert die Normalisierung erforderlich ist...
Liebe Forumsteilnehmer. Bitte fangen Sie keine Streitereien im Forum an. Nur zum Thema des Threads.
Ich denke, das Thema kann geschlossen werden. Die Autoren (nicht das Thema) der Stellungnahmen kamen zu keinem Konsens. Es gab vereinzelte Momente von Chauvinismus, der nicht willkommen ist.
Aber weder die einen noch die anderen konnten ihre Argumente beweisen. Deshalb schließe ich den Thread. Weitere Diskussionen können bestraft werden (maximal tägliches Verbot).
Wenn jedoch ein normaler Nachweis erbracht wird, ist dies zu begrüßen.
Die Richter werden ich und Wolodja sein.
Dies wird nicht diskutiert.
Ich habe das alles hier nicht gesehen und weiß daher nicht, welche Argumente innerhalb des Themas vorgebracht wurden. Aber da es wohl darum geht, meine Position zu beweisen, die der von Artem in diesem Beitrag (und früher hier im Thread) ähnelt, werde ich eines der folgenden Beispiele anführen, das mit der Frage zusammenhängt, ob die Normalisierung auf die eine oder andere Weise angewendet werden sollte, wenn man mit Zahlen vom reellen Typ arbeitet.
Mit Bildschirmfotos und einer Variante des Testcodes.
Artyom schrieb in seinem obigen Beitrag:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
Und da ich auch der Meinung bin (wie wohl viele andere auch), dass dies ein einfacher und wirksamer Weg in die gängigsten Richtungen von Problemen ist, werde ich nur diesen kleinen Zusatz von mir machen:
mit wie vielen Nachkommastellen die Zeile MA angezeigt werden soll, oder nur Berechnungen auf der Grundlage einer beliebigen Anzahl von Nachkommastellen (derselbe Vergleich), mit so vielen Nachkommastellen und Normalisierung (Rundung auf eine bestimmte Nachkommastelle) durchgeführt werden.
/*Bei einzelnen Aufgaben kann es "Ausnahmen" geben, und man kann variieren, um das gewünschte Ergebnis zu erhalten, z. B. indem man einen Wert mit einer niedrigeren Dezimalstelle mit einem Wert mit einer höheren Dezimalstelle vergleicht. Wenn dies jedoch für die jeweilige Aufgabe erforderlich ist, kann es meines Erachtens sinnvoll sein, gegebenenfalls wie bei der obigen Methode die ermittelten Werte auszudrucken und mit der visuellen Darstellung auf dem Diagramm zu vergleichen.
Wenn wir Werte vom Typ Double als Text ausgeben müssen (über Print, Comment, OBJ_LABEL usw.), dann sollten wir DoubleToString verwenden, da wir Zahlen in Text umwandeln wollen.
Nun von der einleitenden Erklärung zur Klarheit:
In den Bildschirmfotos:
Die Daten des Testskripts sind MA-Werte, die mit der iMA-Funktion ermittelt wurden (mit und ohne Transformationen unter Verwendung der in der Dokumentation beschriebenen Funktionen für die Arbeit mit reellen Typen).
Sie können im Datenfenster und im Diagramm sehen, dass die Linien mit einer niedrigeren Dezimalstelle im dritten Balken des Diagramms, den aktuellen nicht mitgerechnet, die gleichen Werte haben. Sie können auch sehen, dass die MA-Werte vom Standard-Set bis zum Terminal, die auf den Dezimalstellen des Diagramms eingezeichnet sind, nicht gleich sind und sich visuell auf dem Diagramm ein wenig früher angeglichen haben.
D.h. wenn Sie die Screenshots vergrößern oder Ihre eigenen Experimente mit dem beigefügten Testskript oder Ihren eigenen Codes durchführen, werden Sie sehen, dass sich die MA-Linien mit der Anzahl der Dezimalstellen wie im Chart etwas früher kreuzen.
Und das ist verständlich. Analog dazu sind Linien mit Dezimalzahlen um eins kleiner als Linien mit zweistelligen Anführungszeichen auf einer dreistelligen Tabelle. Sie ermöglicht es, sie in "alten" Zeiten zu sehen, als drei- oder fünfstellige Kurse in Terminals nicht weit verbreitet waren und gleichzeitig die Vorteile erweiterter Dezimalquotierungen für den Handel (einschließlich engerer Spreads) hatten.
Das heißt, dass Linien, die auf Werten mit weniger Dezimalstellen basieren, weniger "Rauschen" aufweisen.
Wenn jedoch nicht gerundet wurde (in diesem Fall mit Hilfe der Normalisierungsfunktion), wäre eine Zahl, die eindeutig auf eine bestimmte Dezimalstelle begrenzt ist, problematischer.
Oder, wenn auch nur in Zahlen:
123.4561 und 123.4556 sind nicht gleich. Und ihr Unterschied ist nicht gleich Null.
Wenn man sie jedoch aufrundet, sind die erste und die zweite Zahl gleich und ergeben 123,456. Dementsprechend wird die Differenz zwischen ihnen 0 sein.
Die Rundung der sich ergebenden Werte ist je nach den auszuführenden Aufgaben dem Dezimalpunkt überlassen.
In den Screenshots im Journal "Experten" sehen Sie die mit iMA ausgegebenen MA-Werte mit den in der Dokumentation beschriebenen Umrechnungen und ohne Umrechnung der resultierenden Werte. Die MA-Einstellungen im Testskript entsprechen denen der Indikatoren auf dem Chart.
Auf dem zweiten Screenshot sehen Sie die Deltas zwischen zwei MA-Werten mit und ohne Transformationen.Nachstehend finden Sie, wie bereits erwähnt, einen kleinen Testcode. Es ist nicht optimiert, ermöglicht aber verschiedene Experimente mit MA-Werten, einschließlich der Änderung einiger Parameter.
Die Anzahl der Takte wird in dieser Zeile festgelegt:
P./S.: Ich habe das beigefügte Testskript ersetzt. Ich habe in meinem Beitrag die falsche Variante gewählt. Falsch. Entschuldigung.
Die zuvor angehängten Screenshots sind nicht erforderlich, daher lasse ich sie unverändert.