Ich brauche Hilfe! Ich kann das Problem nicht lösen, ich stoße an die Grenzen der Hardware - Seite 5

 

Was Sie suchen, kann komprimiert werden und in komprimiertem Format gesucht werden. Dadurch wird die Datenmenge reduziert und Sie können alle Daten im RAM behalten. (theoretisch)

 
Integer:

Was Sie suchen, kann komprimiert werden und in komprimiertem Format gesucht werden. Dadurch wird die Datenmenge reduziert und Sie können alle Daten im RAM behalten. (theoretisch)

Imo - um in komprimierter Form zu suchen - müssen Sie es zuerst dekomprimieren - in der Theorie, schreiben Sie einen Algorithmus für die Datensuche in komprimierter Form - keine Chance

und das Problem ist - mt4 (32 bit) kann nicht viel im RAM speichern

---

es ist logisch, eine große Menge in einer Datenbank zu speichern und Abfragen zu verwenden, um berechnete Daten zu erhalten

Ich kann mir keinen besseren Weg vorstellen, um fertige Lösungen anzuwenden, als meinen eigenen Datenverarbeitungsmechanismus zu schreiben.

SQL ist sehr gut für die Speicherung großer Datenmengen geeignet, obwohl 20 Gigabyte für SQL nicht viel sind...

--

Sie können Ihren eigenen Mechanismus schreiben und eine gegebene Datei in Teilen lesen und einem Lesefragment die maximale Menge an Speicher zuweisen, um die Geschwindigkeit zu erhöhen

und es müssen mehrere Fragmente von 20 Gigabyte gelesen werden, um einen Berechnungszyklus durchzuführen

Die Frage ist, ob dies schneller ist als die Möglichkeit, Daten in die Datenbank zu laden und über SQL-Abfragen zu verarbeiten - ich denke nicht.

Ich denke, es wäre fast schneller, die Daten in SQL einzugeben.

 
YuraZ:

ichmo - wenn Sie in einem komprimierten Format suchen wollen, müssen Sie zuerst dekomprimieren

Nicht unbedingt. Sie können komprimieren, wonach Sie suchen. Na also! :)
 

Die gesündeste Lösung wäre natürlich, den Algorithmus zu ändern. Da dies aber nicht bekannt ist, gibt es hier nichts Konkretes zu sagen. Allgemeine Gedanken dürfen natürlich überhaupt nicht sein.

Da beispielsweise mehrere Dateilesevorgänge erforderlich sind, könnten diese Lesevorgänge in einer internen "Schleife" stattfinden. Man könnte versuchen, das Lesen auf die äußere "Schleife" selbst zu "übertragen" - die Anführungszeichen werden verwendet, weil eine solche "Übertragung" im Allgemeinen bedeuten könnte, einen völlig neuen Algorithmus von Grund auf zu erstellen :).

Ein weiterer Hinweis ergibt sich aus der Erwähnung von sequentiellen Lesevorgängen mit einer Verschiebung - ein iterativer Algorithmus, der nur Lesevorgänge mit "Verschiebung" erfordert, könnte dieses Problem lösen. Das könnte aber auch bedeuten, dass ein völlig anderer Algorithmus von Grund auf neu entwickelt werden muss.

Vielleicht geht es aber auch gar nicht darum :)

 
Integer:
Das ist nicht notwendig. Sie können komprimieren, wonach Sie suchen. Na also! :)

---

Es gibt eine große Menge an Informationen (etwa 20 GB in einer Textdatei).

Die Informationen bestehen aus der gleichen Art von Sequenzen, etwa einer Million davon.

Es ist notwendig, alle Sequenzenwiederholt durchzugehen und einige Berechnungen anzustellen.

---

von 20 Gigabyte muss man die Daten in den Algorithmus einspeisen.

er sucht nicht - er hat Daten in Form einer Datei - die im Algorithmus verwendet werden - dem Berechnungsalgorithmus zugeführt

 
Candid:

Die gesündeste Lösung wäre natürlich, den Algorithmus zu ändern. Da dies aber nicht bekannt ist, gibt es hier nichts Konkretes zu sagen. Allgemeine Gedanken dürfen natürlich überhaupt nicht sein.

Da beispielsweise mehrere Dateilesevorgänge erforderlich sind, könnten diese Lesevorgänge in einer internen "Schleife" stattfinden. Man könnte versuchen, das Lesen auf die äußere "Schleife" selbst zu "übertragen" - die Anführungszeichen werden verwendet, weil eine solche "Übertragung" im Allgemeinen bedeuten könnte, einen völlig neuen Algorithmus von Grund auf zu erstellen :).

Ein weiterer Hinweis ergibt sich aus der Erwähnung von sequentiellen Lesevorgängen mit einer Verschiebung - ein iterativer Algorithmus, der nur Lesevorgänge mit "Verschiebung" erfordert, könnte dieses Problem lösen. Das könnte aber auch bedeuten, dass ein völlig anderer Algorithmus von Grund auf neu entwickelt werden muss.

Vielleicht geht es aber auch gar nicht darum :)

es ist logisch, den Algorithmus mit großen Datenmengen in den SQL-Server zu stellen
 
YuraZ:

---

Es gibt eine große Menge an Informationen (etwa 20 GB in einer Textdatei).

Die Informationen bestehen aus der gleichen Art von Sequenzen, etwa einer Million davon.

Es ist notwendig, alle Sequenzenwiederholt durchzugehen und einige Berechnungen anzustellen.

---

aus 20 Gigabyte, muss man die Daten in den Algorithmus einspeisen.

es sucht nicht - es hat eine Datenbank - die in den Algorithmus einfließt

Nur eine Verschwörung. Natürlich könnte es alles Mögliche sein, aber ich vermute, es ist das Aussehen. Ich vermute sogar, was.
 
Integer:
Nicht notwendig. Sie können komprimieren, wonach Sie suchen. Na also! :)

Du erstaunst mich, meine Liebe))))

Welchen Algorithmus sollen wir für die Komprimierung verwenden? Huffman, Lempel-Ziv?

Die Komprimierung für einen Textschreiber ist 4-8 mal höher. Bedenken Sie, dass die Komprimierungsalgorithmen für jede Datei unterschiedliche Umkodierungsbäume erstellen.

Mit anderen Worten: Die Quelldatei hat einen Baum und der zu suchende Teil der Daten hat einen anderen Baum.

Es ist nur interessant, wie Sie vorschlagen, danach zu suchen, auch wenn das theoretisch ))))

Datenkompression ist nichts anderes als Kodierung. In Analogie zur Verschlüsselung erhalten wir zwei unterschiedliche Nachrichten (komprimierte Daten), die mit unterschiedlichen Schlüsseln (Umschlüsselungsbäumen) verschlüsselt sind.

Es ist nicht einmal möglich, sie in irgendeiner Weise abzugleichen, geschweige denn eine Suchfunktion zu nutzen )))

 
elugovoy:

Du erstaunst mich, meine Liebe))))

Welchen Algorithmus sollen wir für die Komprimierung verwenden? Huffman, Lempel-Ziv?

Die Komprimierung für einen Textschreiber ist 4-8 mal höher. Bedenken Sie, dass die Komprimierungsalgorithmen für jede Datei unterschiedliche Umkodierungsbäume erstellen.

Mit anderen Worten: Die Quelldatei hat einen Baum und der zu suchende Teil der Daten hat einen anderen Baum.

Es ist nur interessant, wie Sie vorschlagen, danach zu suchen, auch wenn das theoretisch ))))

Datenkompression ist nichts anderes als Kodierung. In Analogie zur Verschlüsselung erhalten wir zwei unterschiedliche Nachrichten (komprimierte Daten), die mit unterschiedlichen Schlüsseln (Umschlüsselungsbäumen) verschlüsselt sind.

Sie sind nicht einmal in irgendeiner Weise vergleichbar, geschweige denn eine Suchfunktion )))

Ups, und mir fallen hier eine Menge Dinge auf.

Ich denke, dass sogar ein Kind in der Lage sein sollte, es zu verstehen. Wenn Sie einen Text mit einem bestimmten Algorithmus komprimieren, wird er heute und morgen in komprimierter Form genau gleich sein.

Wollen Sie damit sagen, dass man mit demselben Komprimierungsalgorithmus und der Komprimierung zweier unterschiedlicher Texte zwei völlig identische Datensequenzen erhalten kann?

 
Integer:
Nur eine Verschwörung. Natürlich kann alles sein, aber ich gehe davon aus, dass die Suche. Ich vermute sogar, was.

>>> Ich weiß nicht, wonach ich suche ...

>>> Sie müssen alle Sequenzenwiederholt durchgehen und einige Berechnungen durchführen.

Nun - ja - ich suche - aber ich suche durch 20 Gigs...

Grundsätzlich basiert die Suche auf der Tatsache, dass es eine Art von Suche und Vergleich gibt.

Ich halte mich an das, was der Autor geschrieben hat

Vielleicht können die Daten nicht verkleinert - komprimiert - indiziert werden.


ist es logisch, die Daten in SQL zu speichern

Übergabe der Geschäftslogik an den Server + Daten

der Expert Advisor sendet nur kurze Daten zur Aufzählung und Berechnung an den Server

und erhalten eine fertige Antwort.