News Dateikomprimierung: KI schlägt ZIP-Programme - bis zu einem bestimmten Punkt

Petabyte? Kinderkram!
Mit 64Bit bist du im Exabytebereich wenn du jedes einzelne Byte adressieren willst.
Und auch für den Dateinamen ist Platz genug im Wörterbuch ;)

Du willst aber nicht jedes einzelne Byte adressieren, sondern jede einzelne Bitkombination bennenen können. ;-)
Um den Unterschied zu verdeutlichen:
2 Byte haben zwei Adressen. Für die Addressierung reicht "0 = erstes Byte", "1 = zweites Byte", also ein einziges Bit.
Sie enthalten aber je 8 Bit, die man je Byte auf 2^8 = 256 verschiedenen Wegen kombinieren kann. Und für die Kombination aus beiden beiden Bytes ist man schon bei 256 × 256 = 2^16 Möglichkeiten:
00000000 00000000
00000000 00000001
00000000 00000010
00000000 00000011
00000000 00000100
00000000 00000101
00000000 00000110
00000000 00000111
...
11111111 11111100
11111111 11111101
11111111 11111110
11111111 11111111

Um in deinem "alle Dateien der Welt"-Wörterbuch die richtige Kombination nachzuschlagen, musst du also bereits 65.536 verschiedene Namen an 2-Byte-Dateien vergeben können, also einen 16-Bit-Code für den Index einen Systems mit 1-Bit-Speicherzellenadressierung verwenden. Für alle 8-Byte-Dateien wären es 64 Bit, wohin gegen 8 Speicherzellen gerade einmal 3 Bit zur Adressierung brauchen. Und-so-exponentiell-weiter – jeweils genauso viele Index-Bits, wie die Dateien selbst Bits enthalten, denn genau daraus ergibt sich die mögliche Vielfalt. Ein alle Kombinationsmöglichkeiten abdeckender Index ist immer genauso groß, wie das was indiziert wird.

Erst wenn man einen unvollständigen Code hat, also die vorkommenden "Wörter" nicht alle denkbaren Buchstabenkombinationen enthalten spart man Platz. So gibt es zum beispiel 27^2 = 729 Möglichkeiten, zwei Buchstaben zu kombinieren. Aber es gibt nicht 729 Wörter mit zwei Buchstaben in der deutschen Sprache. (Sondern ... keine Ahnung? Schätze mal ein Dutzend.) Also bräuchte man da einen Index mit viel weniger als 27^2 Kombinationen, um alles abzudecken, und dieser Index ließe sich tatsächlich platzsparender speichern als die Wörter selbst.

Du wirfst hier so viel durcheinander (oder redest so wirr dass mans nicht versteht) dass ich nicht weiß wo ich anfangen soll. :ka:

Dann machen wirs mal konkret. Man nehme folgenden Text, der in der Datei "Datei123.txt" drinsteht:
"PCGHX ist ein ganz tolles Forum mit vielen netten Leuten".

Du kannst ein beliebig großes Wörterbuch benutzen.
Bitte erstelle eine Datei die maximal 64bit (=8 Bytes) groß ist, die alle diese Informationen enthält.

Selbst wenn du ein sehr gutes angepasstes Wörterbuch hättest das alle Wörter enthält (und auch NUR die und keine anderen dass der Verweis mit 1 Byte eineindeutig ist):
PCGHX =A
ist=A
ein=B
ganz=C
tolles=D
Forum=E
mit=F
vielen=G
netten=H
Leuten=I
Datei123=J

wäre deine zu speichernde Datei immer noch J[ABCDEFGHI] 80 bit groß.

Anmerkung: Du verwendest volle 8 Bit je Index, könntest also 256 verschiedene Buchstaben-Strings indizieren, dabei hat dein Beispiel nur deren 11. Die könnte man bequem mit 0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, 1001, 1010 adressieren. Also gerade einmal vier Bit kurze Indizies.
Mit einem gesamt Speicherbedarf von 40 Bit, verglichen mit 65-ASCII-Zeichen zu insgesamt 520 Bit, ist das aber ein gutes Beispiel dafür, wie Komprimierung funktioniert. :-)
 
Zuletzt bearbeitet:
Zurück