Interessantes Thema für viele: was ist neu in MetaTrader 4 und MQL4 - große Änderungen auf dem Weg - Seite 50
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
Es gibt ein solches Schreiben. Allerdings kann die Lücke (diskontinuierlicher Sprung des Kurses) jederzeit auftreten, nicht nur am Anfang des Taktes. Also ist jedes "ausgedünnte" Format per Definition nicht ohne Sünde. Volles Futter nur in Ticks. Und es könnte noch voller in der Geschichte der Tasse sein. Ich versuche, ein Minutenformat für mich zu machen, so weit ich diesen Kompromiss gefunden habe.Ich kann es so lassen, wie oben beschrieben (ohne Open, nur {Hi-Lo-Close}), ich verstehe alle Nachteile, es ist nur eine Version meiner Codierung für meinen Tester. Ich werde rohe Ticks verwenden oder sie künstlich durch irgendwelche Methoden reduzieren (mit gespeicherten Ticks Format {bid-ask-time}).
Ich glaube nicht, dass der Versuch zu verstehen, ohne zu urteilen, die schwerste meiner Sünden ist. ;)
Das Denken in Bezug auf die Schwere der Sünde ist natürlich stärker. Ich stimme zu.
Ich bin froh, dass du das richtig verstanden hast. Also besorg dir lieber einen Kessel neben meinem. Wir werden viel Zeit zum Plaudern haben. Keine Bewährung.
;)
Sind Sie sicher, dass die MQ-Stäbe M1 unverpackt aufbewahrt werden?
Wie kommt es dann, dass es beim Abrufen des Verlaufs zu Verzögerungen kommt (geringfügig, aber vorhanden), aber das erneute Anwenden (z. B. auf den Cache) schneller geht?
Offenbar werden in der Verlaufsdatei Balken als Änderungen von synchrobar gespeichert, die in komprimierter Form vorliegen.
Ihre Zählung von 52 Bytes ist also eine Zählung der ungepackten Geschichte.
Sind Sie sicher, dass die MQ-Stäbe M1 unverpackt aufbewahrt werden?
Wie kommt es dann, dass es beim Abrufen des Verlaufs zu Verzögerungen kommt (die zwar gering sind, aber es gibt sie), aber das erneute Anwenden (z. B. auf den Cache) schneller geht?
Offenbar werden in der Verlaufsdatei Balken als Änderungen von synchrobar gespeichert, die in komprimierter Form vorliegen.
Ihre Berechnung von 52 Bytes ist also eine Berechnung der ungepackten Geschichte.
Darüber habe ich nichts gesagt, und nicht nur das - ich bin sicher, dass es eine Verpackung gibt. Das Format ist der Öffentlichkeit nicht bekannt, und ich habe nicht versucht, es zu "knacken".
Es ist also alles richtig, ich habe nur das ungepackte Format beschrieben. Es ist aus der Dokumentation entnommen.
Davon habe ich nichts gesagt, und nicht nur das, ich bin sicher, dass es voll ist. Das Format ist nicht öffentlich bekannt und ich habe nicht versucht, es zu "knacken".
Das ist richtig, ich habe nur das beschriebene ungepackte Format. Sie ist der Dokumentation entnommen.
Das ist richtig, aber Sie versuchen zu zeigen, dass das neue Format wirtschaftlich sein wird, indem Sie das derzeitige ungepackte Format und das teilweise verpackte neue Format vergleichen.
Ich vergleiche nicht die Ökonomie, die Sie sich vorgestellt haben, sondern nur die Informativität. Keine Ökonomie, mein ungepacktes Format ist mehr == 88 Bytes {Open, High, Low, Close} und == 72 Bytes {High, Low, Close}.
Sie hätten sich nicht durch den Stein mit Krebs infizieren sollen. Ich hätte vorgeschlagen, den Informationsgehalt zu verdoppeln, anstatt 52 Bytes 88.
Das gleiche von Anfang an hrenfx vorgeschlagen.
Warum gibt es überhaupt ein Format mit so vielen Daten? D.h. es ist notwendig, die Grenzen dieses Tick-Filters (dieses Formats) zu definieren, wenn sich das Ergebnis nicht von der reinen Tick-Historie unterscheidet.
Auf den ersten Blick ist ein einfacher Tick-Filter HighBid+LowAsk nicht viel schlechter als der intelligente Filter (gemessen an der Datenmenge).
Close-data ist nur für die Synchronisierung mit mehreren Währungen geeignet.
Vielleicht ist es einfacher, zu einem kleineren Zeitrahmen zu wechseln, als dies zu tun. S20 benötigt beispielsweise nur 48 Bytes für dieselbe Minute im HighBid+LowAsk-Format (vielleicht sogar weniger, wenn 4 Bytes pro Preis mehr als genug sind). In meinem Testgerät mache ich alles über long int - sehr schnell). Und was die Genauigkeit betrifft, so übertreffen 100 % Ihren Minutenfilter um 88 Bytes.
P.S. Die Funktion Error(Freq, DataSize) = Full - Freq * DataSize tendiert gegen Null, wenn Freq erhöht wird,
wobei Fehler der Verlust von Informationen ist.
Vollständig - vollständige Marktinformationen.
Freq * DataSize ist eine "Multiplikationsfunktion": die Menge an Informationen, die mit der Quantisierungsfrequenz Freq und dem Informationsgehalt(DataSize) für jeden Quantisierungsterm wiedergewonnen werden kann.
Warum gibt es überhaupt ein Format mit so vielen Daten? D.h. es ist notwendig, die Grenzen dieses Tick-Filters (dieses Formats) zu definieren, wenn sich das Ergebnis nicht von der reinen Tick-Historie unterscheidet.
Auf den ersten Blick ist ein einfacher Tick-Filter HighBid+LowAsk nicht viel schlechter als der intelligente Filter (gemessen an der Datenmenge).
Close-data ist nur für die Synchronisierung mit mehreren Währungen geeignet.
Vielleicht ist es einfacher, zu einem kleineren Zeitrahmen zu wechseln, als dies zu tun. S20 benötigt beispielsweise nur 48 Bytes für die gleiche Minute im HighBid+LowAsk-Format (vielleicht sogar weniger, wenn 4 Bytes pro Preis mehr als genug sind). In meinem Testgerät mache ich alles über long int - sehr schnell). In Bezug auf die Genauigkeit übertrifft er Ihren 88-Byte-Minuten-Filter um 100 %.
Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests
Ein für viele interessantes Thema: Was ist neu in MetaTrader 4 und MQL4 - große Änderungen stehen bevor
Avals, 2013.08.11 15:43
Wenn man nicht weiß, was man damit anfangen soll, kann man vergessen, dass es sich um eine halbe Maßnahme handelt. Wir brauchen einen richtigen Tick-Tester.
p.s. Wenn es weit verbreitet ist und in den Chips enthalten ist, dann ist das gut)