Können Sie ehrlich beantworten, was die Gründe für die Verwendung von OHLC Bid + Spread im Vergleich zu OHLC Bid + OHLC Ask sind? 8 statt 5 Zahlen speichern (das Format der Balken und der Historie ist schwer zu ändern)? Wird sie sich erheblich auf den Umfang der übermittelten Daten auswirken? Oder haben Sie vielleicht einfach keine Ask-Preis-Historie? Wird die Logik des Testers komplizierter? Nun, im zweiten Fall ist es noch einfacher - es gibt überhaupt keinen Begriff der Streuung. Seien Sie ehrlich: Was hält Sie davon ab?
Die Größe der Balkenstruktur ist das wichtigste Merkmal, das sich proportional auf die Menge der vom Terminal verbrauchten Ressourcen auswirkt.
Wir sind immer mit der Aufgabe konfrontiert, Ressourcen zu sparen, daher ist eine Expansion in dieser Form nicht angebracht.
structMqlRates
{
datetime time; // время начала периодаdouble open; // цена открытияdouble high; // наивысшая цена за периодdouble low; // наименьшая цена за периодdouble close; // цена закрытияlong tick_volume; // тиковый объемint spread; // спредlong real_volume; // биржевой объем
};
Das entspricht (wenn ich mich nicht irre) 46 Bytes.
Die Größe der alternativen Struktur:
structMqlRates
{
datetime time; // время начала периодаdouble openBid; // цена открытия Biddouble highBid; // наивысшая цена за период Biddouble lowBid; // наименьшая цена за период Biddouble closeBid // цена закрытия Biddouble openAsk; // цена открытия Askdouble highAsk; // наивысшая цена за период Askdouble lowAsk; // наименьшая цена за период Askdouble closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
Entspricht 76 Bytes.
D.h. wir sprechen von einer 65%igen Zunahme des Datenverkehrs während des Herunterladens der Historie und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall. Natürlich können 65 % nicht ausreichen, um Sie aufzuhalten. Die Gründe sind eindeutig unterschiedlich.
Das entspricht (wenn ich mich nicht irre) 46 Bytes.
Die Größe der alternativen Struktur:
Entspricht 76 Bytes.
D.h. wir sprechen von einem Anstieg des Datenverkehrs während des Herunterladens der Historie und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall um 65 %. Natürlich können 65 % nicht ausreichen, um Sie aufzuhalten. Die Gründe sind eindeutig unterschiedlich.
Ich habe 48 Bytes:
structMqlRates
{
datetime time; // время начала периодаdouble Base; // базовая цена бара. Все остальные цены отсчитываются от базы в пипсах short openBid; // цена открытия Bidshort highBid; // наивысшая цена за период Bidshort lowBid; // наименьшая цена за период Bidshort closeBid // цена закрытия Bidshort openAsk; // цена открытия Askshort highAsk; // наивысшая цена за период Askshort lowAsk; // наименьшая цена за период Askshort closeAsk // цена закрытия Asklong tick_volume; // тиковый объемlong real_volume; // биржевой объем
};
Wer auch immer sagt, dass Leerverkäufe nicht ausreichen, möge mir wenigstens ein Beispiel nennen (von der Börse oder vom Devisenmarkt).
Die Größe der Balkenstruktur ist das wichtigste Merkmal, das sich proportional auf die Menge der vom Terminal verbrauchten Ressourcen auswirkt.
Wir sind immer mit der Aufgabe konfrontiert, Ressourcen zu sparen, daher ist eine Verlängerung in dieser Form nicht angebracht.
Renat, gab es irgendwelche Versuche, die Struktur vonMqlRates zu optimieren? Warum brauchen wir zum Beispiel doppelt so genaue (8 Byte) Werte für OLHC, wenn die Genauigkeit jetzt auf maximal fünf Dezimalstellen begrenzt ist? Warum werden diese Werte nicht als normalisierte 3- oder 5-stellige int-Werte gespeichert, die nur halb so viel Speicherplatz benötigen?
Der maximale Wert, der mit diesem Ansatz geschrieben werden kann, ist 42949,67295.
Gibt es irgendwelche OLHC-Forex-Daten, die über diese Grenze hinausgehen?
Wer auch immer sagt, dass Short nicht genug ist - er möge der Erste sein, der mir wenigstens ein Beispiel (von der Börse oder vom Devisenmarkt) nennt.
hrenfx:
D.h. wir sprechen von einer 65%igen Zunahme des Datenverkehrs für das Herunterladen des Verlaufs und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall.
Es ist klar, dass die Entwickler eine ähnliche Transformation der ursprünglichen Struktur verwenden, bevor sie die Daten komprimieren, um den Verlauf zu übertragen, was zu einer enormen Kompressionsrate führt. Aber selbst wenn man nichts, aber auch gar nichts unternimmt, kann man schlimmstenfalls 65 % mehr bekommen.
Können Sie ehrlich beantworten, was die Gründe für die Verwendung von OHLC Bid + Spread im Vergleich zu OHLC Bid + OHLC Ask sind? 8 statt 5 Zahlen speichern (das Format der Balken und der Historie ist schwer zu ändern)? Wird sie sich erheblich auf den Umfang der übermittelten Daten auswirken? Oder haben Sie vielleicht einfach keine Ask-Preis-Historie? Wird die Logik des Testers komplizierter? Nun, im zweiten Fall ist es noch einfacher - es gibt überhaupt keinen Begriff der Streuung. Seien Sie ehrlich: Was hält Sie davon ab?
Die Größe der Balkenstruktur ist das wichtigste Merkmal, das sich proportional auf die Menge der vom Terminal verbrauchten Ressourcen auswirkt.
Wir sind immer mit der Aufgabe konfrontiert, Ressourcen zu sparen, daher ist eine Expansion in dieser Form nicht angebracht.
Die Größe von MqlRates:
Das entspricht (wenn ich mich nicht irre) 46 Bytes.
Die Größe der alternativen Struktur:
Entspricht 76 Bytes.
D.h. wir sprechen von einer 65%igen Zunahme des Datenverkehrs während des Herunterladens der Historie und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall. Natürlich können 65 % nicht ausreichen, um Sie aufzuhalten. Die Gründe sind eindeutig unterschiedlich.
Wenn Sie den Worten Ihres Gegners keinen Glauben schenken, wozu dann noch reden?
Die Größe von MqlRates:
Das entspricht (wenn ich mich nicht irre) 46 Bytes.
Die Größe der alternativen Struktur:
Entspricht 76 Bytes.
D.h. wir sprechen von einem Anstieg des Datenverkehrs während des Herunterladens der Historie und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall um 65 %. Natürlich können 65 % nicht ausreichen, um Sie aufzuhalten. Die Gründe sind eindeutig unterschiedlich.
Ich habe 48 Bytes:
Wer auch immer sagt, dass Leerverkäufe nicht ausreichen, möge mir wenigstens ein Beispiel nennen (von der Börse oder vom Devisenmarkt).Die Größe der Balkenstruktur ist das wichtigste Merkmal, das sich proportional auf die Menge der vom Terminal verbrauchten Ressourcen auswirkt.
Wir sind immer mit der Aufgabe konfrontiert, Ressourcen zu sparen, daher ist eine Verlängerung in dieser Form nicht angebracht.
Renat, gab es irgendwelche Versuche, die Struktur vonMqlRates zu optimieren? Warum brauchen wir zum Beispiel doppelt so genaue (8 Byte) Werte für OLHC, wenn die Genauigkeit jetzt auf maximal fünf Dezimalstellen begrenzt ist? Warum werden diese Werte nicht als normalisierte 3- oder 5-stellige int-Werte gespeichert, die nur halb so viel Speicherplatz benötigen?
Der maximale Wert, der mit diesem Ansatz geschrieben werden kann, ist 42949,67295.
Gibt es irgendwelche OLHC-Forex-Daten, die über diese Grenze hinausgehen?
Gibt es OLHC-Daten zu Forex, die über diese Grenze hinausgehen?
Ich habe 48 Bytes:
Wer auch immer sagt, dass Short nicht genug ist - er möge der Erste sein, der mir wenigstens ein Beispiel (von der Börse oder vom Devisenmarkt) nennt.D.h. wir sprechen von einer 65%igen Zunahme des Datenverkehrs für das Herunterladen des Verlaufs und des Speicherverbrauchs durch das Terminal und den Tester (einschließlich Agenten) im schlimmsten Fall.
Vladix:
Warum brauchen OLHC-Werte zum Beispiel doppelte (8 Byte) Genauigkeit, wenn .....................
Das heißt übrigens: JA.
könnte sehr wohl ersetzt werden durchund es wird KEINER betroffen sein. dann wird die Größe auf magische Weise auf 46 Bytes zurückkehren. schön, nicht wahr :)
Ich habe 48 Bytes:
Wer auch immer sagt, dass Short nicht genug ist - er möge der Erste sein, der mir wenigstens ein Beispiel (von der Börse oder vom Devisenmarkt) nennt.