Mt4 Ende der Unterstützung. - Seite 29
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
Der Hauptnachteil: OOP zwingt Sie dazu, den Code in viele Funktionen zu fragmentieren.
Für Menschen ist es einfacher, fragmentierten Code zu akzeptieren, aber Fragmentierung ist für jeden Mechanismus kontraindiziert.
Na gut, aber was ist der Nachteil?
Das ist der Hauptvorteil, gerade weil es für eine Person einfacher ist, fragmentierten Code zu erkennen!
Der Computer muss sich an den Menschen anpassen, nicht der Mensch an den Computer.
Das ist richtig, aber was ist der Nachteil?
Das ist der Hauptvorteil, weil es für eine Person einfacher ist, fragmentierten Code zu erkennen!
Der Computer sollte sich an den Menschen anpassen, nicht der Mensch an den Computer.
Leider sollte ein Entwickler in erster Linie an die Effizienz seines Mechanismus denken und nicht an seine Bequemlichkeit)).
Andernfalls wird der Mechanismus "schlapp" machen.
Der Entwickler sollte sich auf den Computer einstellen.
Wenn die Kurse von demselben Server stammen, spielt es keine Rolle, um welches Instrument es sich handelt. Schließlich werden die Balken bei jedem Instrument gleichzeitig geöffnet.
Anders verhält es sich, wenn die Quellen der Zitate in verschiedenen Teilen der Welt liegen. Für Minuten spielt das keine Rolle, aber es kann ein Problem mit höheren Zeitrahmen geben. Vielleicht müssen die Zeitfunktionen genauer untersucht und eine genaue Zeitkorrektur vorgenommen werden. Aber das ist die nächste Stufe in der Entwicklung dieser Lösung...
Sie müssen eine Kalibrierung für diese Funktion vornehmen...
Zuerst wollte ich alles lesen, was ohne mich geschrieben wurde, für den Fall, dass es bereits eine Frage und eine Antwort gibt, aber ich fürchte, es wird schwierig sein, den Beitrag zu finden, der später zitiert werden muss.
Im Moment gibt es nur 1 Frage: Wie jeder weiß, erscheint ein neuer Balken erst mit dem ersten Tick im neuen Zeitintervall. Wenn es also einen Balken um Millisekunden geben sollte, dieser aber nicht vorhanden ist, können Sie Indikatorwerte vom falschen Balken erhalten.
Ich hoffe, eine Antwort auf die zweite Frage zu finden, sie wurde von Artem gestellt.
Zuerst wollte ich alles lesen, was ohne mich geschrieben wurde, für den Fall, dass es bereits eine Frage und eine Antwort gibt, aber ich fürchte, es wird schwierig sein, den Beitrag zu finden, der zitiert werden muss.
Bisher nur 1 Frage: Wie jeder weiß, erscheint ein neuer Balken erst mit dem ersten Tick im neuen Zeitintervall. Wenn es also einen Balken um Millisekunden geben sollte, dieser aber nicht vorhanden ist, können wir Indikatorwerte aus dem falschen Balken erhalten.
Ich hoffe, eine Antwort auf die zweite Frage zu finden, sie wurde von Artem gestellt.
Ja, das haben wir gestern besprochen.
Ich hatte früher mit einer anderen Plattform zu tun, und dort wurden die Balken unabhängig von der Ankunft der Kurse nach der Zeit gebildet (siehe TWS).
Mir wurde gesagt, dass dies bei MT nicht der Fall ist.
Ich werde ein Zitat Ankunft Kontrolle hinzufügen, um das Ereignis der neuen Bar Aussehen zu bestätigen.
Ich habe bereits geantwortet, dass die Bars unabhängig vom Eingang eines Angebots geöffnet werden. Wenn es keine Notierung gibt, ist der Preis des neuen Balkens der Schlusskurs des vorherigen Balkens. Die Tatsache, dass ein neuer Balken entsteht, wird unabhängig vom Eintreffen von Kursen durch die Zähler selbst festgelegt, die nach einem Zeitplan laufen.
Der spezifische Zeitrahmen spielt keine Rolle, da es sich nur um einen Zähler handelt, der seinen Wert erreicht und das Ereignis des neuen Balkens dieses Zeitrahmens setzt. Dies ist einfach eine Methode zur Synchronisierung mit dem Erscheinen neuer Balken in verschiedenen Zeitrahmen. SYNCHRONISIERUNG.
Auch das Instrument spielt keine Rolle. Wenn die Kurse von einem Server stammen, bedeutet dies, dass sie zum gleichen Zeitpunkt wie die neuen Balken erscheinen. Daher ist es egal, welches Instrument, solange diese Instrumente von einem Punkt der Erde stammen.
Ich werde zu Ende bringen, was ich gesagt habe, und andere Dinge tun. Ein kleines bisschen was Gutes).
Und wie lässt sich die Tatsache erklären, dass der Schlusskurs vom Freitag, der vorherige Barren eines beliebigen Zeitraums, 1,20333 und der Eröffnungsschluss vom Montag eines beliebigen Zeitraums 1,20142 beträgt?
Natürlich ist dies das Angebot des einen Maklers, das des anderen könnte etwas anders ausfallen, aber es gibt insgesamt einen Unterschied.
Und wie erklären Sie sich die Tatsache, dass der Schlusskurs vom Freitag, der vorherige Barren eines beliebigen Zeitraums, bei 1,20333 liegt und der Eröffnungskurs des Montags eines beliebigen Zeitraums ebenfalls bei 1,20142?
Dies sind natürlich die Angebote des einen Brokers, die anderen können etwas anders sein, aber sie haben alle Unterschiede.
Sie wird durch die Lücke erklärt. Dies geschieht bei der Eröffnung der Sitzung.
Ich bin kein Handelsexperte, also beurteilen Sie meine Meinung nicht zu streng).
Und ich weiß noch weniger darüber, was auf dem Devisenmarkt passiert.)
Leider muss der Konstrukteur zuerst an die Effizienz seines Mechanismus denken, nicht an seinen Komfort).
Andernfalls wird der Mechanismus "schlapp" machen.
Der Entwickler muss sich auf den Computer einstellen.
Nein.
Der Computer soll sich auf mich einstellen. Ich habe genug andere Probleme. Der Entwickler kann nur dort nachbessern, wo der Computer die Aufgabe nicht bewältigen kann, z. B. bei Engpässen in der Leistung oder im Speicher. Dann, ja, ist der Entwickler an der Reihe, sich anzupassen. Aber bisher bin ich noch nicht auf Stellen gestoßen, an denen OOP den Computer so stark zusätzlich belasten würde, dass er irgendwie reduziert werden müsste.
So ähnlich (Code für MQL5):
Aber ich wiederhole: Ich bin ein OOP-Befürworter.
Es ist nur ein wirklich unglückliches Beispiel, um zu zeigen , was in der prozeduralen Programmierung unmöglich ist.
Als ich damit anfing, wollte ich nicht zeigen, dass alles möglich/unmöglich ist, sondern nur, dass es in Zukunft bequemer ist, wenn ich meinen eigenen Code schreibe.
Aber es kam, wie V.S. sagte, ich wollte das Beste, aber es kam, wie es kommen musste.
Oh, nein.
Es ist der Computer, der sich auf mich einstellt. Ich habe genug andere Probleme. Der Entwickler kann nur dort nachjustieren, wo der Computer "nicht klarkommt", z. B. bei "Engpässen", wo nicht genügend Leistung oder Speicher vorhanden ist. Dann, ja, ist der Entwickler an der Reihe, sich anzupassen. Aber bisher bin ich noch nicht auf Stellen gestoßen, an denen OOP eine so erhebliche zusätzliche Belastung für den Computer darstellt, dass sie irgendwie reduziert werden muss.
Die Belastung des Computers wird durch die nachlässige Haltung des Entwicklers gegenüber der Frage der Kohärenz seines Mechanismus verursacht. Der Wunsch, Energie zu sparen, um das System zu verbessern. Eine unangemessene Verschwendung von Computerressourcen im Namen der Arbeitserleichterung.
Solange der Computer erfolgreich mit ineffizient geschriebenem Code zurechtkommt, wird der Entwickler weiterhin auf der Rechenleistung "schmarotzen". Dies ist eine Sackgasse.
Früher oder später wird sich der unwirksame Mechanismus nicht mehr weiterentwickeln und durch ein besseres Gegenstück ersetzt werden.
Die Zeit und die Mühe des Menschen werden vergeudet, und sein Geistesprodukt wird im Mülleimer landen.
In der Welt des Wettbewerbs besteht dieses Risiko ständig.
Bei der Entwicklung von Maschinen sollten wir in erster Linie an ihre Leistung denken und erst in zweiter Linie an den Komfort und die Bequemlichkeit, mit der wir unsere Arbeitszeit verbringen).
Die Last wird dem Computer durch die nachlässige Haltung des Entwicklers gegenüber der Kohärenz seines Mechanismus aufgebürdet. Der Wunsch, bei der Verbesserung des Systems Energie zu sparen. Unvernünftiger Verbrauch von Computerressourcen im Namen der Arbeitserleichterung.
Solange der Computer erfolgreich mit ineffizient geschriebenem Code zurechtkommt, wird der Entwickler weiterhin auf der Rechenleistung "schmarotzen". Dies ist eine Sackgasse.
Früher oder später wird sich der unwirksame Mechanismus nicht mehr weiterentwickeln und durch ein besseres Gegenstück ersetzt werden.
Die Zeit und die Mühe des Menschen werden vergeudet, und sein Geistesprodukt wird im Mülleimer landen.
In der Welt des Wettbewerbs besteht dieses Risiko ständig.
Bei der Entwicklung von Mechanismen sollten wir in erster Linie an ihre Leistungsfähigkeit und in zweiter Linie an den Komfort und die Bequemlichkeit unserer Arbeitszeiten denken).
Dies wird als Programm geschrieben ist. Deshalb sollte man zuerst einen korrekt funktionierenden (und für jeden anderen Entwickler lesbaren) Code schreiben und ihn erst dann optimieren, wenn es überhaupt etwas zu optimieren gibt.