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

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
an Komposter: Andrei, wenn du bei dem Dimensionsproblem nicht weiterkommst, bedeutet das, dass du einen Fehler bei der Formulierung des Problems gemacht hast.
Hier gibt es drei Möglichkeiten:
1 Denken Sie selbst darüber nach
2 das Problem in einem öffentlichen Forum anzusprechen
3 Lösen Sie das Problem unter vier Augen (für jeden, von dem Sie glauben, dass er es lösen kann und dem Sie vertrauen, dass er es geheim hält).
Ich erkläre Ihnen, was ich meine: Wenn Sie Nachrichten speichern, können Sie die gesamte Nachricht in Thongs schreiben, oder Sie können typische Phrasen kodieren (Komprimierung), "Kontostand" wird zu 1, "Kontokapital" zu 2, usw. Eine andere Variante des typischen Problems ist der Wunsch, bereits sortierte Daten auszufüllen. Bei großen Dimensionen ist dies der Tod, es ist einfacher, am Ende hinzuzufügen und eine bedingte Sortierung durch Indizes durchzuführen.
Ich glaube, ich verstehe, was ich meine, wenn ich sage, dass es einen Fehler in der Aufgabendefinition gibt.
Nun, Sie können eine solche Ersetzung in einem guten Texteditor vornehmen. Ich nehme an, dass die redundanten Informationen unter allen Bedingungen (wenn es sich um Nachrichten handelt) >40% betragen.
Die Schreibfunktionalität für die Verarbeitung von Textdaten wird dadurch jedoch nicht abgeschafft. Wenn das Volumenproblem gelöst ist, kann das Leistungsproblem schleichend auftreten.
Und im Allgemeinen ist die Problemstellung nicht vollständig gelöst, das ist eine Tatsache... nicht viele Daten, aber mehr Möglichkeiten ))
Erinnert mich an: "Ist es rot? Nein, es ist schwarz. Warum ist sie weiß? Weil es grün ist."
Davon ist hier nicht die Rede.
>>> Es geht um den Vergleich zweier komprimierter Sequenzen.
eindeutiges Element, da es keine Sequenz hat, nicht komprimiert ist, schlägt die Suche fehl
Kontrolle - in der Praxis
Beispiel - RAR zwei Dateien komprimieren
ELEMENT - 08:01:
UND FOLGE
08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.
---
Öffnen Sie beide RAR-Dateien in einem HEX-Editor und suchen Sie nach
Sie werden feststellen, dass das Element 08:01: nicht komprimiert ist
und es wird nicht mit dem übereinstimmen, was in der zweiten Datei steht.
Wenn Sie jeden Eintrag - jede Spalte einzeln - komprimieren, erhalten Sie keinen Größengewinn.
Im Gegenteil, Sie erhöhen das Datenvolumen auf Kosten der Kontrolldaten des Archivs
Probieren Sie es aus - in der Praxis
Beispiel - RAR komprimiert zwei Dateien
ELEMENT - 08:01:
UND FOLGE
08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10:56:12.
10:56:12.
10:56:12.
10:56:13.
10:56:39.
10:56:39.
10:56:39.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10:57:52.
11:44:50.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.08:01:
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.
---
Öffnen Sie beide RAR-Dateien in einem HEX-Editor und suchen Sie nach
Sie werden feststellen, dass das Element 08:01: nicht komprimiert ist.
und es wird in keiner Weise übereinstimmen.
aber wenn Sie jeden Eintrag - jede Spalte einzeln - komprimieren, gewinnen Sie nicht an Größe
im Gegenteil, Sie werden die Datenmenge erhöhen
Jeder Datensatz muss einzeln komprimiert werden. Natürlich ist dies nur sinnvoll, wenn die Datensätze groß genug sind, um sie zu komprimieren.
Jeder Datensatz muss einzeln komprimiert werden. Dies ist natürlich nur sinnvoll, wenn die Aufnahmen groß genug sind, um sie wirklich zu komprimieren.
Nun, wir sind zu dem Schluss gekommen, dass wir in Blöcken arbeiten müssen. Es ist also unmöglich, eine Information zu finden, die nicht der Größe eines Blocks entspricht.
Warum ist das so? Wovon? Wo liegt das Problem? Dazu ist es nicht gekommen.
Warum ist das so? Wovon? Wo liegt das Problem? Dazu ist es nicht gekommen.
Jeder Datensatz muss einzeln komprimiert werden. Natürlich ist dies nur sinnvoll, wenn die Aufnahmen groß genug sind, um sie wirklich zu komprimieren.
Dimitri - wenn Sie jeden Datensatz komprimieren - eine Zeile
Sie werden die Lautstärke erhöhen - überprüfen Sie es!
201 a1.rar -- komprimiert aaaa1 Ich kann nicht sagen, dass es komprimiert ist, aber es ist komprimiert.
es war 535 aaaa1
wurde 77 a2.rar ein Element komprimiert - bzw. es ist nicht komprimiert ... aber in der Datei + Kontrollbytes
war 8 aaaa2
---
das Datenvolumen wird von 20 Gigabyte auf die Größe von 20 Gigabyte Suchelement + Geschwindigkeitsbytes erhöht
Was ist dann der Sinn?
Dimitri - wenn Sie jeden Datensatz komprimieren - eine Zeile
Sie werden die Lautstärke erhöhen - überprüfen Sie es!
201 a1.rar -- komprimiert aaaa1 Ich kann nicht sagen, dass es komprimiert ist, aber es ist komprimiert.
535 aaaa1
77 a2.rar ist ein Element komprimiert - oder besser gesagt, es ist nicht komprimiert ... aber in der Datei + Kontrollbytes
8 aaaa2
---
das Datenvolumen wird von 20 Gigabyte auf die Größe von 20 Gigabyte Suchelement + Verwaltungsbytes erhöht
Was ist dann der Sinn?
Ja, ich weiß, wenn die Daten kurz sind, werden sie bei der Archivierung größer.
Deshalb ist die von Ihnen vorgeschlagene Lösung nicht geeignet.