CopyTicksRange () funktioniert nicht korrekt in MQL5. a - Seite 5
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
Ja, ich lese die Funktionsbeschreibungen ganz durch, und im Zweifelsfall stöbere ich auch in den Foren. Jeder hat eine andere Vorstellung von schnell. Dynamik ist per definitionem langsamer, da der Speicher ständig umverteilt wird. Der zweite Nachteil ist die Fragmentierung - manchmal macht man einen Fehler mit der Dynamik und dann reicht der Speicher nicht aus, um das Terminal zu schließen :)))
Ping hat damit nichts zu tun, nach dem ersten Download werden die Ticks schon von der Basis vorgegeben, theoretisch natürlich :) Mir wurde beigebracht, dass das Programm durch Optimierung beschleunigt werden soll, aber nicht durch die Hardwarebasis - das ist automatisch. Und was macht es für einen Unterschied, was ist der Zusammenhang - heute ist es der eine, morgen ein anderer - es kommt nicht auf den Algorithmus an.
Ich habe meinen eigenen Makler, deshalb arbeite ich seit mehr als einem Jahr mit ihm zusammen. Meine Aufgabe besteht nun darin, die Mathematik der Zecken zu beherrschen, nicht den Handel oder die Freiberuflichkeit.
Nochmals, für Sehbehinderte:
Aus der Referenz
Функция CopyTicksRange() предназначена для запроса тиков из строго указанного диапазона, например, за конкретный день истории.Von
Die Funktion CopyTicksRange() ist dazu gedacht, Ticks aus einem genau festgelegten Bereich abzufragen, z. B. für einen bestimmten Tag der Historie.
Die Funktion CopyTicksRange() erhält nicht die Ticks aus dem streng spezifizierten Bereich "2021.01.29 23:57:00:000, 2021.01.31 23:59:00:000". Gibt Ticks aus einem völlig anderen Bereich zurück.
Bitte geben Sie die Maße für diese Behauptung an. Ich gebe Leistungsproblemen bei Kampfberatern eine große Rolle.
Hier ist ein Beispielcode. Ich habe in Eile geschrieben, es kann Fehler geben. Messungen für die folgenden Optionen:
1) am hässlichsten, wenn das Array nach Bedarf erweitert wird
2) leicht optimiert - wenn auf den beabsichtigten Teil erweitert
3) etwas optimierter - erweitert sich mit einem Spielraum von mehreren Portionen
4) statischer Speicher, der offensichtlich immer Null sein wird
Es ist klar, dass, wenn Sie dynamisch eine große Menge an Speicher für alles auf der Welt zuweisen, die Geschwindigkeit wie bei Statik sein wird, aber das passiert selten
Bei dynamisch expandierenden Arrays ist das Schlimmste die Speicherfragmentierung, die dabei alles verschlingt. Nun, die immer größer werdende Zeit für die nächste Erweiterung – denn. in einem stark fragmentierten speicher dauert die suche nach einem passenden stück länger
Ergebnisse in Mikrosekunden. Der starke Anstieg der benötigten Zeit in der ersten Spalte gegen Ende liegt höchstwahrscheinlich daran, dass das Terminal Speicher für Arrays wahrscheinlich in kleinen Blöcken allokiert, optimiert für uns ein wenig. Aber wenn das Array größer als der Block wird, beginnt es dummerweise, nach dem ersten passenden leeren Stück zu suchen. Ich habe viel weiter gedreht, da wird es sehr lang ... mehrere Sekunden. Und es gab nur etwa 1.000.000 Zellen
Hier ist ein Beispielcode. Ich habe in Eile geschrieben, es kann Fehler geben. Messungen für die folgenden Optionen:
1) am hässlichsten, wenn das Array nach Bedarf erweitert wird
2) leicht optimiert - wenn auf den beabsichtigten Teil erweitert
3) etwas optimierter - erweitert sich mit einem Spielraum von mehreren Portionen
4) statischer Speicher, der offensichtlich immer Null sein wird
Es ist klar, dass, wenn Sie dynamisch eine große Menge an Speicher für alles auf der Welt zuweisen, die Geschwindigkeit wie bei Statik sein wird, aber das passiert selten
Bei dynamisch expandierenden Arrays ist das Schlimmste die Speicherfragmentierung, die dabei alles verschlingt. Nun, die immer größer werdende Zeit für die nächste Erweiterung – denn. in einem stark fragmentierten speicher dauert die suche nach einem passenden stück länger
Ergebnisse in Mikrosekunden. Der starke Anstieg der benötigten Zeit in der ersten Spalte gegen Ende liegt höchstwahrscheinlich daran, dass das Terminal Speicher für Arrays wohl in kleinen Blöcken alloziert, optimiert für uns ein wenig. Aber wenn das Array größer als der Block wird, beginnt es dummerweise, nach dem ersten passenden leeren Stück zu suchen. Ich habe viel weiter gedreht, da wird es sehr lang ... mehrere Sekunden. Und es gab nur etwa 1.000.000 Zellen
Und so bekomme ich es
Wahrheit ein wenig korrigiert
Und wenn Sie Arrays initialisieren
dann so
es wurde zwei Jahre lang getestet!
Was für ein sturer Kerl! Lesen Sie, was sie oben geschrieben haben - CopyTicks stört genau so. Wenn Sie gerne nach Wegen suchen, eine fehlerhafte Funktion zum Laufen zu bringen oder fehlerhafte Umgehungen zu finden, dann lassen Sie es lieber bleiben - darum geht es nicht
In zwei Jahren hättest du verstehen können, dass es kein Fehler ist, wenn eine Funktion nicht so funktioniert, wie du es willst, und die Entwickler davon wissen und es nicht beheben...
Daumen hoch, coole, gebildete Programmierer.........
INT_MAX = 2147483647
in der Tat haben Sie sofort ein INT_MAX* sizeof(double) Stück Speicher weggeschnappt und arbeiten dann wie mit static
Sie könnten geschrieben haben
double d[INT_MAX]; - das wäre für Sie dass elbe wie
der einzige Unterschied besteht in der Ausführung der Funktion ArraySize(), wobei der gesamte Speicher auf einmal abgeschaltet wird
Behoben, wird heute in der Beta-Version erscheinen.
Ich danke Ihnen vielmals. Ich werde vor Freude pumpen :) der Workaround war sehr ressourcenintensiv
Behoben, wird heute in der Beta-Version erscheinen.