Ich brauche Hilfe! Ich kann das Problem nicht lösen, ich stoße an die Grenzen der Hardware - 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
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)
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.
ichmo - wenn Sie in einem komprimierten Format suchen wollen, müssen Sie zuerst dekomprimieren
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 :)
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
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 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
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 )))
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?
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 hatVielleicht 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.