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

 
Urain:

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 ))

 

Davon ist hier nicht die Rede.

 
YuraZ:

>>> 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

 
YuraZ:

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.

 
Integer:

Jeder Datensatz muss einzeln komprimiert werden. Dies ist natürlich nur sinnvoll, wenn die Aufnahmen groß genug sind, um sie wirklich zu komprimieren.

Wir sind also an einem Punkt angelangt, an dem wir in Blöcken arbeiten müssen. Dementsprechend wird es unmöglich sein, eine Information zu finden, die nicht der Größe eines Blocks entspricht.
 
Contender:
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.

 
Integer:

Warum ist das so? Wovon? Wo liegt das Problem? Dazu ist es nicht gekommen.

Und er redet immer noch über Bälle mit Mischka :)
 
Integer:

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?

 
YuraZ:

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, vergrößert die Archivierung den Umfang.
 
Integer:
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.