Komprimierung von 20 Gigabyte auf 5 Megabyte oder weniger
Martin Schöler
Ich habe mir folgendes Gedacht:
Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so
gedacht:
Eine irrationale Zahl, z.B. pi, oder die Wurzel aus 2 ist ja
unendlich lang. Wir sehen diese Zahl mal im Binärcode...
Irgendwo in dieser Unendlichkeit muss also zufällig die
gesamte Festplatte abgespeichert sein. Der Zufall
ist 100%, da die irrationale Zahl ja unendlich groß ist.
Diese Position finde ich heraus, gebe sie ungefähr an durch
z.B. 10 ^ 1000000000000000000000000 oder, wenn die zahl größer
wird, dann eben durch 10 ^ 10 ^ 10 ^ 10000000000000.
Nun speichere ich danach die ersten 500 Bytes der Festplatte,
mit denen man den Anfang der Festplatte ab der obigen
ungenauen Position suchen muss. Da die Zahl oben zu ungenau ist,
und die 500 Bytes in der eingegrenzten Unendlichkeit der irrationalen
Zahl bis zum Beginn der Festplatte sehr wahrscheinlich
mehrmals vorkommen, zähle ich nun, wie oft diese 500 Bytes
mehrmals vorkommen, bis zu der Position der Festplatte. Diese
Zahl gebe ich nun genau an, als dritten Wert. Nun habe ich die
gesamte Festplatte von 20 GB mit 3 Werten definiert.
Beispiel:
10 ^ 10 ^ 10 ^ 1000000000000000000000000000000000000000000000000000
[die ersten 500 Bytes der Festplatte]
145231239874094193871623948763872374917826348793726
Um die letztere Zahl zu verkleinern, kann ich natürlich die 500 Bytes
auf 5 MB erweitern.
ICH WEIß, dass diese Kompression wegen der fast unendlichen
Rechenleistung Milliarden Jahre dauern würde, oder vielleicht
sogar noch länger, aber meine Frage:
Wäre es theoretisch und auch praktisch (Rechenleistung nicht
einberechnet!!!) möglich, die Festplatte nach dieser Variante
von 20 GB auf z.B. 5 MB zu komprimieren?
M. Schöler
Ulrich Thiel
> Wäre es theoretisch und auch praktisch (Rechenleistung nicht
> einberechnet!!!) möglich, die Festplatte nach dieser Variante
> von 20 GB auf z.B. 5 MB zu komprimieren?
Eigentlich schon, obwohl es halt "praktischer Blödsinn" ist :)
Aber warum merkt man sich nicht die Positionen der Ziffern in der
irrationalen Zahl, mit der die Festplatte beginnt bzw. aufhört!? Das wäre
irgendwie einfacher!? Wenn du weißt, dass die Festplatte bei der x-ten
Stelle in der irrationalen Zahl beginnt, dann ist das Ende bei
x+20E12...Problematisch wird es natürlich, wenn du jetzt anfängst, Daten auf
deiner Festplatte zu verändern :)
Peter Niessen
"Martin Schöler" <ma...@t-online.de> schrieb
> Hallo !
>
> Ich habe mir folgendes Gedacht:
> Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
> 20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so gedacht:
[Beispiel Snip]
> Wäre es theoretisch und auch praktisch (Rechenleistung nicht
> einberechnet!!!) möglich, die Festplatte nach dieser Variante
> von 20 GB auf z.B. 5 MB zu komprimieren?
Geht so nicht. Unter allen denkbaren Dateien gibt es immer eine eine
die man nicht komprimieren kann.
Das ist insbesondere die Datei die von 800 GB auf 20GB komprimiert
wurde. Gibt aber noch mehr von dem Kaliber :-)
Ergo: Geht nicht! (zumindest meistens nicht)
Mit freundlichen Grüßen:
Peter Nießen
Ulrich Thiel
die Sicherung dieser beiden Werte vielleicht größer als die Platte selbst ;)
Uwe Nowak
> Eine irrationale Zahl, z.B. pi, oder die Wurzel aus 2 ist ja
> unendlich lang. Wir sehen diese Zahl mal im Binärcode...
> Irgendwo in dieser Unendlichkeit muss also zufällig die
> gesamte Festplatte abgespeichert sein. Der Zufall
> ist 100%, da die irrationale Zahl ja unendlich groß ist.
Nein, der schluss ist falsch. Es kann ohne weiteres unendliche lange
nicht periodische Zahlen geben, die eine bestimmte Ziffernkombination
niemals enthalten (nimm Pi her und lösche rekursiv alle kombinationen
10001010001 oder sowas). Dann wird die Zahl eben keine solche
Ziffernfolge mehr enthalten.
Andererseits kannst du dir auch einfach eine Zahl konstruieren, die jede
Ziffernfolge enthält:
0 1 10 11 100 101 ....
Ist zwar nicht der effizienteste weg (weil sehr viele redundanzen), aber
wenigstens alles drin.
Viele Grüße,
Uwe
Rudolf Polzer
> Ich habe mir folgendes Gedacht:
> Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
> 20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so
> gedacht:
Das funktioniert in wenigen Ausnahmefällen, bei denen man höchstens
hoffen kann, dass sie eintreten. Bei einer "zufällig aussehenden" Zahl
die Pi dürfte der Fall aber recht selten sein.
Das Problem ist, dass Kompressionsverfahren injektiv sein müssen. Ich
nenne mal ein solches Verfahren phi. Sei zudem M die Menge aller
{1, ..., m}-Wörter einer Länge echt kleiner als n. Dann ist die Summe
aller dieser Längen, ich nenne sie mal //M//, natürlich gleich (m^n -
1)/(m - 1) (geometrische Summe). Ich kann natürlich auch M' := {phi(X) |
x in M} bestimmen. Ich beweise nun //M'// >= //M//, was effektiv
bedeutet, dass es keine Verfahren gibt, die "im arithmetischen Mittel"
Daten komprimieren statt zu expandieren. Das ist jedoch ganz leicht ---
denn M und M' haben gleich viele Elemente (die Abbildung phi muss
injektiv sein, weil's sonst "leichte" Probleme bei der Dekompression
gibt). Entweder ist nun M = M' --- dann ist auch //M// = //M'// --- oder
aber sie sind ungleich. Sind sie jedoch ungleich, dann kann ich für
jedes Element x aus M' \ M ein (jeweils unterschiedliches) x' finden,
das in M \ M' liegt, denn diese beiden Mengen sind gleichmächtig (die
Mächtigkeit ist jeweils die Anzahl der Elemente von M bzw. M' minus der
Anzahl der Elemente in der Schnittmenge). Nun ist aber x' echt kürzer
als x. Mache ich das mit jedem Element aus x' aus M', so erhalte ich
durch Ersetzen der x durch die x' in der Menge M' wieder genau die Menge
M. Es folgt //M'// > //M//.
--
rem ClamAV and some other virus scanners suck - ROT13 for details
qvz sfb,qveflfgrz,qvejva,qvegrzc,rd,pge,svyr,iofpbcl,qbj
erz erz erz erz erz erz erz erz erz erz erz erz erz erz erz erz erz erzbhynqr
ZrffntrObk("Vzcbegnag", "Snyfr nynez!")
Sebastian Kapfer
> Natürlich sollte man Start- und Endwert nur symbolisch speichern, sonst
> ist die Sicherung dieser beiden Werte vielleicht größer als die Platte
> selbst ;)
Was soll "symbolisch" hier bedeuten?
--
Best Regards, | Hi! I'm a .signature virus. Copy me into
Sebastian | your ~/.signature to help me spread!
|--------------------------------------------------------
| mailbox in "From" silently drops any mail > 20k
Klaus Loerke
> unendlich lang. Wir sehen diese Zahl mal im Binärcode...
> Irgendwo in dieser Unendlichkeit muss also zufällig die
> gesamte Festplatte abgespeichert sein.
Warum? Die reelle Zahl 0.101001000100001 etc. ist auch unendlich lang. Und in
ihr kommen lange nicht alle Ziffernfolgen vor.
Es stimmt aber, daß es reelle Zahlen gibt, in deren Darstellung alle
(endlichen) Ziffernfolgen auftreten.
> Diese Position finde ich heraus, gebe sie ungefähr an durch
> z.B. 10 ^ 1000000000000000000000000 oder, wenn die zahl größer
> wird, dann eben durch 10 ^ 10 ^ 10 ^ 10000000000000.
> Nun speichere ich danach die ersten 500 Bytes der Festplatte,
> mit denen man den Anfang der Festplatte ab der obigen
> ungenauen Position suchen muss. Da die Zahl oben zu ungenau ist,
> und die 500 Bytes in der eingegrenzten Unendlichkeit der irrationalen
> Zahl bis zum Beginn der Festplatte sehr wahrscheinlich
> mehrmals vorkommen, zähle ich nun, wie oft diese 500 Bytes
> mehrmals vorkommen, bis zu der Position der Festplatte. Diese
> Zahl gebe ich nun genau an, als dritten Wert. Nun habe ich die
> gesamte Festplatte von 20 GB mit 3 Werten definiert.
Wieso nimmst du an, daß du den ersten Index in 20 Byte, 20 Kilobyte oder gar
20 Gigabyte ablegen kannst? Der kann (und wird!) so groß werden, daß jede
Zahldarstellung mehr Platz braucht als die Darstellung der Festplattendaten.
Abgesehen davon kann es ein solches Verfahren nicht geben, hieße es doch, daß
eine injektive Abbildung N -> {0..n} für ein gewisses n\in N existiert.
klaus
Hans Crauel
> Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
> 20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so
> gedacht:
> [Ausführungen, die die Zuweisung einer Adresse in einer `normalen
> Zahl' beschreiben, gesnippt; dass nicht jede irrationale Zahl
> dazu geeignet ist, haben andere bereits bemerkt]
> ICH WEIß, dass diese Kompression wegen der fast unendlichen
> Rechenleistung Milliarden Jahre dauern würde, oder vielleicht
> sogar noch länger, aber meine Frage:
> Wäre es theoretisch und auch praktisch (Rechenleistung nicht
> einberechnet!!!) möglich, die Festplatte nach dieser Variante
> von 20 GB auf z.B. 5 MB zu komprimieren?
Die Idee, einfach eine Adresse zuzuweisen, welche auf die
Festplatte bzw. auf deren Inhalt verweist, lässt sich sehr viel
einfacher und mit noch weniger Speicheraufwand realisieren:
Man baut die Festplatte aus und legt sie in einen Schrank mit
geeigneten Fächern, die man zuvor numeriert hat. Dann genügt
eine Zahl mit typischerweise wenigen Ziffern, um die riesengroße
Festplatte eindeutig festzulegen.
Hans Crauel
Philip Kügler
Hans Crauel wrote:
> =?ISO-8859-1?Q?Martin_Sch=F6ler?= schreibt
>
>
>>Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
>>20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so
>>gedacht:
>>[Ausführungen, die die Zuweisung einer Adresse in einer `normalen
>> Zahl' beschreiben, gesnippt; dass nicht jede irrationale Zahl
>> dazu geeignet ist, haben andere bereits bemerkt]
>
[...]
> Die Idee, einfach eine Adresse zuzuweisen, welche auf die
> Festplatte bzw. auf deren Inhalt verweist, lässt sich sehr viel
> einfacher und mit noch weniger Speicheraufwand realisieren:
> Man baut die Festplatte aus und legt sie in einen Schrank mit
> geeigneten Fächern, die man zuvor numeriert hat. Dann genügt
> eine Zahl mit typischerweise wenigen Ziffern, um die riesengroße
> Festplatte eindeutig festzulegen.
Mist das wollte ich auch gerade vorschlagen. ;-)
Solche Überlegungen können und werden nie zu einem Ziel führen, da man
dabei an der "Informationsdichte" scheitert.
Alle Kompressionsmethoden funktionieren nur deshalb, weil die zu
komprimierenden Daten meistens eine sehr geringe Informationsdichte
besitzen.
.) Informationsdichte = 1 bedeutet jede Stelle (in beliebiger
Darstellung) ist ein nicht-reduntanter wesentlicher Teil der
Information. Für einen Computer wäre das ein einzelnes Bit.
.) Informationsdichte = 0 würde etwas darstellen, das gar keine
Information enthält (Also unmöglich)
Word-Dateien (.doc) hab eine informationsdichte von ca. 0,01-0,1. d.h.
mehr als 90% der Datei besteht aus unnötigem Müll, der dann durch eine
Kompression "entfernt" wird. (Deswegen hat eine 200kb Datei nach dem
zippen nur mehr 20kb + zip-overhead).
Ob du jetzt eine Ersetzungsmaske errechnest (ace, rar, zip, arj, lha,
...) oder einen Index in einer Zahlenfolge bestimmst ist irrelevant, da
der zu übertragende Teil die unkomprimierten Daten mit einer
Informationsdichte von höchstens 1 darstellen kann. D.h. dein Schlüssel
wird im Mittel genug unterschiedliche Zustände haben müssen um alle
Möglichen Kombinationen aus deinen zu komprimierenden Daten darstellen
zu können.
Wenn du jetzt ein "Dictionary" verwendest (Als eine Maske wie "aabcgfe"
= 1, "ksajhdfkdsg" = 2, ...) und dann diese Indizes als Polynom
abbildest, so wird die Größe der Polynome zwar weseltich kleiner sein
als eine äquivalente Darstellung mit Informationsdichte 1, du mußt
jedoch auch dieses Dictionary allen decodern zur Verfügung stellen. und
wenn dieses Dictionary die Informationsdichte 1 hat, so ist die
(Gesamt-)Informationsdichte aller zu übertragenden Daten wieder kleiner
als 1, da die Polynome ja dann "reduntete" Daten darstellen.
Deshalb können Videodateien (sofern ein brauchbarer Codec verwendet
wird) auch nicht komprimiert werden (oder zumindest nur marginal).
lg,
Philip
fiesh
> Eine irrationale Zahl, z.B. pi, oder die Wurzel aus 2 ist ja
> unendlich lang. Wir sehen diese Zahl mal im Binärcode...
> Irgendwo in dieser Unendlichkeit muss also zufällig die
> gesamte Festplatte abgespeichert sein. Der Zufall
> ist 100%, da die irrationale Zahl ja unendlich groß ist.
"Normalitaet" (siehe dazu z.b. mal (unwissenschaftlich)
"http://www.heise.de/newsticker/data/as-01.08.01-000/".
Lustigerweise hatte ich genau den selben Gedanken auch schonmal :)
Aber: Nimm an, du hast eine normale Zahl gegeben, stell dir z.B. vor,
sie listet der Reihe nach in Binaerdarstellung alle Zahlen auf, also
0. 0 1 10 11 100 101 110 111 ...
dann siehst du, dass die Zahl (und ein Festplatteninhalt ist ja nichts
anderes als eine grosse Zahl) an einer Stelle steht, die "groesser" ist,
als die Zahl selbst. Somit brauchst du zum abspeichern der Stelle
mindestens soviel Platz, wie die Zahl selbst schon benoetigt.
Ich hoffe, ich konnte dir mit dieser sehr schwammigen Erklaerung das
ganze anschaulich verdeutlichen.
(Du kannsts dir auch etwas formaler ueberlegen, in dem du annimst, es
gaebe eine normale Zahl, die jeden Zeichencode so enthaelt, dass du
damit echt komprimieren kannst. Dann folgt induktiv ja, dass du alles
auf 1 Bit komprimieren kannst.)
--
bye
fiesh
Gottfried Helms
>
> Wieso nimmst du an, daß du den ersten Index in 20 Byte, 20 Kilobyte oder gar
> 20 Gigabyte ablegen kannst? Der kann (und wird!) so groß werden, daß jede
> Zahldarstellung mehr Platz braucht als die Darstellung der Festplattendaten.
>
Na ja, da das hier doch immer wieder angefragt wird... Das einfachste
Beispiel für eine Kompression ist doch die Verwendung des Morse-Codes
für meine Bytes. Die empirisch am häufigsten auftretenden Bytes werden mit
dem kürzesten Code dargestellt. Natürlich sind die seltenen Codes dann
länger - aber wer sagt denn, daß die in der praktischen Anwendung überhaupt
auftreten?
Wenn man jetzt davon ausgeht, daß die meisten 40-GB-Festplatten zu
einem Großteil (sagen wir mal 75%) eines der drei aktuellen Windows-systeme
enthalten, kann der invariante Teil von diesen Systemen (ein paar hundert
megabyte inzwischen) schonmal auf 2 Bit reduziert werden.
Der Witz ist dabei natürlich, daß diese 2 Bit lediglich eine externe Referenz
indizieren, die ihrerseits dann beliebig groß sein kann - wie z.B. di beiden
Buchstaben des Namens einer Irrationalzahl mit genau den optimalen Eigen-
schaften.
Da die Windows-binärdarstellung (z.zt noch) endlich ist, kann man übrigens
statt einer Irrationalzahl sogar ganz einfach eine Rational - oder sogar
Integerzahl nehmen, und ihr einen kurzen Namen geben (z.B. die 200-800-mil-
lionenstelligen Integerzahlen "WIN98" "WINME" "WINXP").
Diese 3 sehr großen Integerzahlen kann ich mit 2 bit indizieren, und habe deswegen
eine extreme Packung des größten Teils meiner ersten Festplatten-Partition.
Entsprechend vergibt man kleine Nummern für die Kombinationen der häufigsten
Programmpakete, also z.b. die Standard-Word/Excel-Installation mit 1, usw .
Für den ganzen Plattenbedarf dieser Giga-Bytesandwüsten hat man in -sagen wir
mal- einem weiteren Nibble von maximal 4 bit Platz.
Der -nicht unbeträchtliche- variante Teil befindet sich zwar wiederum in
riesigen Dateien (system.dat ~ 8MB bei mir z.Zt), aber die Auswahl der Optionen
der genannten Programmpakete ist natürlich nicht so erschreckend groß, daß man
die häufigsten nicht mit relativ kleinen Codes belegen könnte - und unterliegt
sicherlich ebenfalls einer Häufigkeitsverteilung mit einem extremen (= extrem
ausbeutbaren) nicht-uniformen Verlauf.
Und so weiter.
Die seltener auftretenden Fälle, also alle weiteren stärkeren benutzerdefinier-
ten Abweichungen oder Zusatzinstallationen muß man entsprechend mit längeren
Codes belegen - das ist klar. Aber selbst viele von denen treten ja gar nicht auf,
weil sehr viele aus willkürlichen Options-Kombinationen und Zusatzinstallationen ja
in sich sinnlos wären, nicht zuletzt, da sie eh' nicht funktionieren würden und
zu ständigen Programm- oder gar Windowsabstürzen führen würden -und damit in einem
Algorithmus unter ebendiesem Windows übrhaupt nicht berücksichtigt zu werden
bräuchten, wie eine kurze Überlegung zeigt.
Also die Kunst der Kompression ist
- Redundanz finden
- sich dabei auf extern verfügbare/vereinbarte Informationen/Konventionen beziehen
- und diese konstengünstig indizieren.
-------------
Jetzt zu dem variableren und benutzerspezifischeren Teil der Daten auf der
Giga-byte-Platte, der unabhängig von der Office-Installation und deshalb nicht
durch die ersten 6 bit darstellbar ist.
Wenn man realistischerweise annimmt, daß der größte Teil des verbleibenden
Speicherplatzes bei 90% aller Windows-Anwender entweder Bilder oder Sounds
ausmachen, kann man hier wiederum zunächst die Indizierungs-Kompression durch
Verweis auf extern vorhandene Information (also hier: statt des Liedes dessen
Namen) anwenden. Wiederum gelingt es, aus mitunter 80-MB-großen Wave-dateien
einen 14-byte-langen String zu generieren - und die Liste aller dieser
Strings sollte mit einem bekannten ZIP-Verfahren noch weitaus enger gepackt
werden können - sofern man sie nicht vorher sogar noch einer weiteren Stufe der
Index-Kompression (externer häufigkeitsorientierter Index für die Titel)
unterwirft.
Dies wäre dann erst mal der lächerlich kleine verbleibende Anteil der (für diese
Bereiche notwendigen oder wünschenswerten) verlustfreien Kompression -
"lächerlich" klein natürlich nur für die erwähnten 75%-90% der Standardanwender
ohne ausgefeilte Zusatzinstallationen.
Für die Bilder und Sounds, die in den externen indizierbaren Listen *nicht*
enthalten sind, oder deren Indexposition so hoch wäre, daß deren Codierung
unverhältnismäßig viel Platz verschwenden würde, kann man nun natürlich
verlustbehaftete Kompression anwenden, z.B. JPG mit 10% Ergebnislänge.
Im Prinzip kann man dieses Verfahren auf *alle* verbliebenen Daten anwenden,
wenn man sich die heutzutage gute Qualität von JPG-Bildern ansieht. Hierzu
nimmt man einen linearen Datenarray von 512 Clustern a 512 byte, interpretiert
das als 512*512-Graustufenbild und unterwirft das einem JPG-Kompressionsverfahren.
Auch bei benutzerdefinierten Textdateien, emails oder email-Archiven kann
schließlich eine gewisse Unschärfe durchaus hingenommen werden, da diese in
den meisten Texten und Manuskripten aus rein anthropologischen Gründen ohnehin
vorliegt (Problem der unscharfen Bedeutungsfelder, der verschwommenen
Argumentation, der ungenauen thematischen Fokussierung) Hier kann man noch
die kürzlich im Internet verbreitete, und von mir mit Interesse gelesenen
Information hinzuziehen, nach der für die Möglichkeit des Wiedererkennens
von Wörtern die Reihenfolge der Buchstaben fast unerheblich ist, solange
Anfangs- und Endbuchstabe richtig sind.
---------------------------------
Die Überlegung aus dem Vor-posting
> Abgesehen davon kann es ein solches Verfahren nicht geben, hieße es doch, daß
> eine injektive Abbildung N -> {0..n} für ein gewisses n\in N existiert.
weist auf die Unmöglichkeit einer *universellen* verlustfreien Abbildung eines
beliebigen Strings auf einen kürzeren hin.
Man sieht aber, daß - und wie- durchaus eine dramatische Kompression im Sinne
der ursprünglich gestellten Aufgabe stets realisiert werden kann, solange man
gewisse Typen von Codesequenzen identifizieren kann, die signifikante
Häufigkeitsunterschiede aufweisen. In allen solchen Fällen kann eine
Referenzierung und Indizierung externen Wissens (wie z.B. der Entwicklung
der unendlichen Dezimalstellensequenz von PI, referenziert durch die zwei Byte
"PI" in
"PI"(<meinindex>) -> database.constants("PI").(<meinIndex>),
besser:
"PI"(<meinindex>) -> internal_algorithmus("PI").(<meinIndex>),
oder durch eine geeignete Anordnung von Codesequenzen in externen Listen , z.B.
wie hier mit dem Index in die externe Liste aller Betriebssysteme (hier in
ihrer jeweiligen Grundeinstellungsversion)
"00"b -> database("OS").("WIN98").binary
"01"b -> database("OS").("WINME").binary
"10"b -> database("OS").("WINXP").binary
"11"b(<other code>) -> database("OS").(<other code>).binary
eine teilweise dramatische Kompression darstellen (800 MB-> 2 bit), wie dies
prinzipiell vom Morse-Code bekannt ist. Daß dem Decodierungs-Algorithmus dann
eine solche Datenbasis, z.B. in Form eines Sets von CD'S (oder eines Internet-
zugriffes auf google o.ä.) zur Verfügung gestellt werden muß, ist dann
natürlich eine andere Frage.
In bezug auf die Verwendung der externen Information "PI" (die der Decodierungs-
algorithmus dann als Erzeugungsvorschrift für unendlich viele Dezimal-Digits
durch einen wenige 100-byte-langen Algorithmus interpretieren muß) läßt sich
das Problem des meist *sehr* langen Indexschlüssels für die Startposition der
gewünschten Information in PI (außer, wenn der Benutzer grade die ersten 10000
Stellen von Pi in seiner Textdatei gespeichert hat...) möglicherweise dadurch
verringern, daß die im Algorithmus für PI verwendete Approximationsformel so
parametrisiert wird, daß die gewünschten Stellen gleich am Anfang auftauchen.
Mit andern Worten - wenn die Erfahrung zeigt, daß der Index in die Ziffernfolge
von PI zu groß wird, kann man ja eine andere Konstante finden, die besser
konfektioniert ist. Aber dieses wäre dann ein Thema für ernsthaftere Forschungen
z.B. über
"empirische Häufigkeitsverteilungen von Binaries auf PC-Festplatten im
Zusammenhang mit Dezimalstellenentwicklung von sehr großen Integerzahlen
bzw. exotischen Irrationalzahlen, und deren Darstellung durch sparsame
Approximationsalgorithmen",
die man vielleicht mal mit einer Cray und entsprechenden Geldern von der DFG
durchführen sollte.
Just my 2 c -
Gottfried Schelms
Philip Kügler
Gottfried Helms wrote:
[...] ;-)
Du mischt da diverse Annahmen (OS, Inhalt einzelner Dateien, ...) wirfst
das alles ein einen Topf und interpretierst das Ergebnis als Kompression.
Mit derselben Annhame behaupte ich, daß die relevanten Inhalte aller
Datenträger dieser Welt in 300 Jahren durch 42 ausgedrückt werden können.
Tipp: Viele unterschiedliche OS mit unterschiedlicher Version (Nicht nur
98, ME, 200, XT, NT), Status des OS (Fixes, Patches, Datenfehler,
Hardwareabhängige Treiber, ...), Zustand des Systems (Zeit seit
Installation, gedrückte Tasten, ...), Installierter Software, ...
Außerdem ist die Idee Texte verlustbehaftet zu komprimieren schon sehr
ausgefallen...
Theoretisch könnte auf jeder Platte eine Kombination aller auf dieser
Welt verfügbaren Informationen liegen. Unabhängig davon, dass das
Dictionary für eine solche Kompression einige Tonnen Datenträger
bräuchte (Unabhängig welcher verfügbare Datenspeicher gewählt wird) ist
der Schlüssen den du dann für eine bestimmte Festplatte ermittelst
sicher nicht viel kleiner als der Platteninhalt selbst.
lg,
Philip
Sebastian Kapfer
> Die Idee, einfach eine Adresse zuzuweisen, welche auf die Festplatte
> bzw. auf deren Inhalt verweist, lässt sich sehr viel einfacher und mit
> noch weniger Speicheraufwand realisieren: Man baut die Festplatte aus
> und legt sie in einen Schrank mit geeigneten Fächern, die man zuvor
> numeriert hat. Dann genügt eine Zahl mit typischerweise wenigen
> Ziffern, um die riesengroße Festplatte eindeutig festzulegen.
Das blöde ist nur, dass man verdammt viele Festplatten braucht, um alle
2^(8*20*2^30) Zustände abdecken zu können. Ganz zu schweigen vom
Speicherbedarf für die Indizes :-)
Hans Crauel
>> Die Idee, einfach eine Adresse zuzuweisen, welche auf die Festplatte
>> bzw. auf deren Inhalt verweist, lässt sich sehr viel einfacher und mit
>> noch weniger Speicheraufwand realisieren: Man baut die Festplatte aus
>> und legt sie in einen Schrank mit geeigneten Fächern, die man zuvor
>> numeriert hat. Dann genügt eine Zahl mit typischerweise wenigen
>> Ziffern, um die riesengroÃe Festplatte eindeutig festzulegen.
> Das blöde ist nur, dass man verdammt viele Festplatten braucht, um
> alle 2^(8*20*2^30) Zustände abdecken zu können. Ganz zu schweigen
> vom Speicherbedarf für die Indizes :-)
Wenn du wirklich nichts anderes willst als *alle* Zustände zu
speichern (ich unterstelle: um sie dann irgendwann mal abrufen
zu können; andernfalls wäre Speichern wenig sinnträchtig),
brauchst du gar keinen Speicher mehr. Das Bildungsgesetz für
alle Zustände ist so einfach, dass man Dreijährige danach
fragen kann, wenn man es mal vergessen haben sollte (gut, man
muss die Antwort dann noch von Dezimal- in Binärform bringen).
Hans Crauel
Peter Heckert
Martin Schöler wrote:
> Hallo !
>
> Ich habe mir folgendes Gedacht:
> Theoretisch könnte man doch eine riesengroße Festplatte von z.B.
> 20 GB auf ungefähr 1 Kilobyte komprimieren. Das habe ich mir so
> gedacht:
> Eine irrationale Zahl, z.B. pi, oder die Wurzel aus 2 ist ja
> unendlich lang. Wir sehen diese Zahl mal im Binärcode...
Welche Vorteile sollte eine irrationale Zahl bringen?
Die Festplatte kommt auch in der unendlichen Abfolge der natürlichen
Zahlen vor, und man weiß sogar ohne suchen zu müssen, wo sie ist ;-)
Oder meinst Du, der Inhalt Deiner Festplatte käme in einer irrationalen
Zahl mit höherer Wahrscheinlichkeit vor, weil er irrational ist? ;-).
Davon abgesehen:
Natürlich gibt es 2^(1000*8) Festplatten, die sich so komprimieren lassen.
Aber es gibt auch 2^((20_000_000_000-2^1000)*8) Festplatten, die so nicht
komprimierbar sind, bzw. die dieselben Schlüssel ergäben.
Die Wahrscheinlichkeit, eine Festplatte zu finden, die so komprimierbar
ist, wäre also äusserst gering.
Ich hätte aber einen Ausweg:
Die Summe der Kehrwerte aller Quadratzahlen ist PI²/6.
Schreib einfach ein kleines Programm, das auf diese Weise alle Stellen von
PI berechnet, und speichere das Programm auf der Platte. Dann hast Du alle
Festplatten beliebiger Grösse in ein paar 100 Programmzeilen abgespeichert ;-)
Noch effizienter wäre es, ein Programm zu schreiben, das die Folge der
natürlichen Zahlen generiert. Einen besseren Kompressionsfaktor kann es
garnicht geben.
peter
Mirko
Ich bin zwar kein Mathematiker, aber dafür techn. Informatiker ( auf
der Suche nach der math. Lösung für die linearisierung einer Funktion
h(t) nach y(h), welche dann linear sein soll *schäm*).
Aber ich möchte trotzdem eine Behauptung aufstellen:
Es sollte theoretisch möglich sein einen solchen Algorithmus zu
erstellen, jedoch kann man nicht beliebig komprimieren: Die Zahl 1
oder 0 kannst Du einmal als 8-Bit ASCII darstellen und Speicherplatz
verschwenden oder einfach ein Bit nehmen und sagen "0" ist Null und
"1" ist Eins - jedoch kannst Du nur begrenzt komprimieren, da Du den
Werteberech einschränkst. Wenn Du ASCII nur verwendest um Einsen und
Nullen als Text abzulegen ist dies Vergewaltigung an der Codierung -
nichts desto trotz wird es sehr häuftig bei der Datenkonvertierung von
dem einem System in ein anderes genau so gemacht.
Versuch die Behauptung zu konkretisieren:
Um eine endliche Folge an Zeichen zu komprimieren unter Verwendung
einer Mapping-Technik ( Zahl a wird auf b abgebildet, wobei Zahl a
mehr Speicher benötigt als b) würde nur funktionieren, wenn man davon
ausgeht, das die endliche Folge nicht beliebige Variationen annehmen
kann.
Ich poste jetzt noch meine Frage von oben in einen neuen Thread, in
der Hoffung das mir jemand helfen kann.
Grüße in die Welt am 3. Advent
Mirko
Jasper Riedel
>
> Abgesehen davon kann es ein solches Verfahren nicht geben, hieße es doch, daß
> eine injektive Abbildung N -> {0..n} für ein gewisses n\in N existiert.
> klaus
Das gefällt mir wirklich gut, das ist perfekt. Gruss - Jasper
Jasper Riedel
>
> Die Summe der Kehrwerte aller Quadratzahlen ist PI²/6.
Das ist ja interessant - kannst du das mal zeigen (oder be-linken) bitte?
> Schreib einfach ein kleines Programm, das auf diese Weise alle Stellen von
> PI berechnet, und speichere das Programm auf der Platte. Dann hast Du alle
> Festplatten beliebiger Grösse in ein paar 100 Programmzeilen abgespeichert ;-)
> Noch effizienter wäre es, ein Programm zu schreiben, das die Folge der
> natürlichen Zahlen generiert. Einen besseren Kompressionsfaktor kann es
> garnicht geben.
Das verstehe ich nicht, kannst du mal einen Wink geben?
Jens Makait
"Martin Schöler" <ma...@t-online.de> schrieb
> Beispiel:
> 10 ^ 10 ^ 10 ^ 1000000000000000000000000000000000000000000000000000
> [die ersten 500 Bytes der Festplatte]
> 145231239874094193871623948763872374917826348793726
Wieviele unterschiedliche Füllungen dieser 20GB_Platte gibt es?
256^20000000000 so ungefähr.
Alle diese Platteninhalte müssen auf unterschiedliche
'komprimierte Dateinen' abgebildet werden. Da muss es
also auch 256^20000000000 verschiedene geben.
Im Durchschnitt sind die also mindestens gleich groß.
Was Kompressionsalgorithmen leisten können ist IMO,
dass sie 'üblichen' Dateiinhalte auf kürzere
Dateien abbilden, während die 'unüblichen' sogar ein paar
Byte länger werden. (gezippte ARJ-Dateien z.B.).
In den meisten praktischen Fällen wird es kräftig kleiner.
Bei den bei weitem(!) meisten Dateien wird es wenige
Byte größer.
Was macht ZIP mit Dateien, die aus Zufalls-Bytes bestehen?
Jens
Jens Makait
"Uwe Nowak" <ma...@uwenowak.de> schrieb
> Nein, der schluss ist falsch. Es kann ohne weiteres unendliche lange
> nicht periodische Zahlen geben, die eine bestimmte Ziffernkombination
> niemals enthalten.
AFAIK vermutet man aber im Moment, dass Pi derartige
Dinge nicht treibt, dass eben jede beliebige
Ziffernfolge irgendwann erscheint.
Jens
Jens Makait
"Jens Makait" <jens....@dzsh.de> schrieb
> Im Durchschnitt sind die also mindestens gleich groß.
Ach, ja, und was ist wohl dein Denkfehler?
Ich vermute, dein Modell funktioniert deshalb nicht,
weil du falsche Vorstellungen davon hast, wie groß diese
Adressen (diese Positionsangaben und Abzählhinweise)
sein müssen. Der komplette Inhalt einer 20GB-Platte
kommt in Pi wohl erst so weit hinten vor, dass du im
Durchschnitt mindestens 20GB benötigst, um die Adresse
und einen dazu passenen Abzählwert anzugeben.
Aber wirklich witzig fand ich deine Idee schon.
Und ob sie auch praktikabel wäre, ist in der Tat
für die Überlegung, ob es überhaupt geht, irrelevant.
Jens
Gottfried Helms
>
>
> Gottfried Helms wrote:
>
> [...] ;-)
>
> Du mischt da diverse Annahmen (OS, Inhalt einzelner Dateien, ...) wirfst
> das alles ein einen Topf und interpretierst das Ergebnis als Kompression.
>
> Mit derselben Annhame behaupte ich, daß die relevanten Inhalte aller
> Datenträger dieser Welt in 300 Jahren durch 42 ausgedrückt werden können.
>
> Tipp: Viele unterschiedliche OS mit unterschiedlicher Version (Nicht nur
> 98, ME, 200, XT, NT), Status des OS (Fixes, Patches, Datenfehler,
> Hardwareabhängige Treiber, ...), Zustand des Systems (Zeit seit
> Installation, gedrückte Tasten, ...), Installierter Software, ...
Da hätte ich vielleicht am Ende das Beispiel noch besser auswalzen
sollen. Sicherlich habe ich hier von Betriebssystem-binaries in Form
von Listen gesprochen - das habe ich hauptsächlich aus Gründen der Über-
sichtlichkeit gemacht. In Wirklichkeit, bzw. zugrundeliegend, ist dies
aber natürlich die genaue Einhaltung der Idee der Indizierung in eine
Irrationalzahl, wie z.B. Pi, so wie der OP das vorgeschlagen hat.
* Wenn die Binaries, von denen ich geschrieben habe, entsprechend der
Häufigkeit ihres Auftretens sortiert werden, eine Längeninfomation
vorangestellt bekommen und als zusammenhängender Dezimalstring inter-
pretiert werden, können sie nach dieser Theorie in PI ab einer
bestimmten Stelle gefunden werden.
* PI kann mit einem relativ kleinen Algorithmus berechnet werden.
* Die Dezimal-Position in PI ist -bei einer einmal festgelegten Liste
von Binaries- auch für alle Dekodierungsprogramme fest vorgegeben, kann
also Teil des Algorithmus sein.
D.H. die tatsächlich abzuspeichernde Netto-Information muß nur durch
den relativen Index in der Dezimalentwicklung von PI
+--------AP: fix gespeicherte Anfangsposition in PI
v
PI = ...(Längeninformation1)(Binary1)(Längeninformation2)(Binary2)...
enthalten, und das ist, wenn z.B. WIN98 die erste Binary ab AP
ist, dann eben nur 1 in einer 2-Bit-Zahl.
Da aber AP so riesig groß ist, wäre eine Sammlung von CD's, die
*nur* den Dezimalstring *ab AP* enthält, vielleicht zeitgünstiger
und auch effizienter für den Dekodierungs-Algorithmus.
Andererseits könnte es nun natürlich eine bestimmte rationale oder
irrationale Potenz von PI geben, z.B. PI^42.4242..., bei der der
wichtige Binarystring direkt am Anfang erscheint.
Nun ist es extrem unwahrscheinlich, solch eine Potenz von PI mit
vertretbaren Mitteln zu finden. Deshalb habe ich in meinem Text
nicht so sehr auf PI verwiesen, sondern am Ende auf ein Forschungs-
modell orientiert, als dessen Ergebnis eine andere Irrationalzahl mit
einer möglichst ökonomischen Generierungsvorschrift (parametrisierung
des Pi-Algorithmus, z.B.) herauskommt, die genau die gewünschten
Eigenschaften hat, z.B. daß der gewünschte Dezimalstring (oder
Hexadezimalstring) am Anfang oder wenigstens nahe am Anfang
steht, z.B. innerhalb der ersten 65565 Bytes anfängt, weil man dann
nur 2-Byte bräuchte um die Position anzugeben.
Für erste eigene Versuche zur Bestimmung solch einer Zahl empfehle
ich die Analyse der betreffenden Daten der eigenen Festplatte, die
Hinzufügung der Längeninformation, und dann eine Suche in Plouffes
symbolischen Inverter, z.B. mit dem Substring der ersten 16 oder 22
Ziffern. Man hätte dann schon mal einen grobe Orientierung, wie der
Anfang solch einer Zahlensuche als Ergebnis einer Formel aus bekannten
Irrationalzahlen (E,Pi,Phi,Gamma,Cos(1) etc) aussehen könnte...
>
> Außerdem ist die Idee Texte verlustbehaftet zu komprimieren schon sehr
> ausgefallen...
>
Nun ja, ganz ohne Verluste geht's eben selten, und wo gehobelt wird,
da fallen eben Späne. Aber wenn du mal eine Musik mit diesem neuen
MP3-Verfahren ("MP2000" (?)) oder die Luratech (?)-Grafik-Komprimierung
siehst - da bleiben doch wirklich kaum noch Wünsche offen. Oder?
Es ist ja auch nur als Option vorgeschlagen worden, die die verlorene
Zeit /den verbrauchten Hauptspeicherplatz für den Algorithmus aus Teil 1
wieder ausgleichen soll.
Und wenn du mal selbstkritisch siehst, mit welcher Aufmerksamkeit
du deine eigenen alten Texte liest, dann sollte ein solcher Algorith-
mus doch nicht allzuviel Schaden anrichten, wie ich in meinem vorigen
Posting eher am Rande, aber aus eigener empirischer Erfahrung, angemerkt
habe:
(aus meinem Posting)
> den meisten Texten und Manuskripten aus rein anthropologischen Gründen ohnehin
> vorliegt (Problem der unscharfen Bedeutungsfelder, der verschwommenen
> Argumentation, der ungenauen thematischen Fokussierung)
und vor allem
> Hier kann man noch
> die kürzlich im Internet verbreitete, und von mir mit Interesse gelesenen
> Information hinzuziehen, nach der für die Möglichkeit des Wiedererkennens
> von Wörtern die Reihenfolge der Buchstaben fast unerheblich ist, solange
> Anfangs- und Endbuchstabe richtig sind.
Ich schätze, daß auch bei *diesem* Posting hier nach Wegkomprimierung von
Redundanz und Randstreuung (durch Verweis auf andere mails anstelle ganzer
Bandwurmsätze und Inline-Zitate) ein großer Kompressionsfaktor entstehen
könnte, und dieser durchaus noch verbessert werden könnte durch gemäßigte
Erhöhung der argumentativen Unschärfe oder gewisse Verringerung der
Individualität der Gedankenführung - lange bevor der Inhalt wirklich unver-
ständlich werden würde.
ist überzeugt...
Gottfried Schelms
Ingo Menger
> "Peter Heckert" schrieb
> > Noch effizienter wäre es, ein Programm zu schreiben, das die Folge der
> > natürlichen Zahlen generiert. Einen besseren Kompressionsfaktor kann es
> > garnicht geben.
>
> Das verstehe ich nicht, kannst du mal einen Wink geben?
Das besagte Programm ist wahrscheinlich verschwindend klein im
Vegleich zu jeder Festplatte. Und dennoch "enthält" es gewissermassen
den Inhalt jeder denkbaren Festplatte. Denn es kann ihn in endlicher
Zeit reproduzieren.
Wenn Rechenzeit wesentlich billiger wäre als Plattenspeicher, könnte
man Festplatten wie folgt komprimieren:
a) man benutze eine gute Hash-Funktion, die Zahlen beliebiger Länge
auf Zahlen der Länge m (z.B. 8 Mbit = 1MB) abbildet. Eine gute
Hash-Funktion H(n) zeichnet sich dadurch aus, daß die
Wahrscheinlichkeit, daß (a <> b and H(a)=H(b)) gilt, nahe bei 1/2**m
liegt. Insbesondere dann, wenn sich a und b nur in wenigen Bits
unterscheiden, sollte der Haswert dramatisch differieren.
b) man berechne H(f), wobei f die Zahl ist, die auf der Festplatte
gespeichert ist.
c) man speichere H(f) sowie die Länge von f, z.B. auf Diskette.
Es gibt nun nur endlich viele Zahlen, die die gleiche Länge wie f
haben, ungleich f sind und dennoch denselben Hashwert ergeben. Das
Dekomprimieren ist daher recht einfach: man probiert für jede Zahl mit
derselben Länge wie f, ob der Hashwert mit dem auf der Diskette
gespeicherten Wert übereinstimmt. Ist dies der Fall, versucht man, die
gefundene Zahl als Inhalt einer Festplatte zu interpretieren. Dies
ergibt entweder die Originalplatte, oder ziemlichen Müll oder durch
ganz grossen Zufall eine andere gültige Festplatte. Letzteres wäre
aber erst recht interessant, denn auf dieser könnten jede Menge
interessanter Dokumente, Filme, Musikstücke oder Programme gespeichert
sein, die noch kein Mensch vorher gesehen hat.
Hiermit patentiere ich das eben skizzierte Verfahren als "compresion
by hashing - decompression with possible surprise" und erhebe Anspruch
auf das geistige Eigentum an den Inhalten aller Files, die auf
zufällig erzeugten gültigen Festplatten stehen.
whoever
mal ein bisschen neben dem topic,
mein bruder hat mal mit ner zip datei (damals zu dos zeiten)
experimentiert und eine 10k oder so zip datei
dazu gebracht entpackt etliche MB groß zu werden.
Dazu hat er in der zip datei eingetragen das eine
bestimmte zeichenfolge im text n-mal vorkam.
im ursprünglichem file kam die zeichenfolge
5 mal hintereinander vor, nach der veränderten
datei 50000000 mal.
also der umgekehrte fall, eine 5kb komprimierte datei
zu 20-unendlich GB kriegen geht leicht, das umgekehrte
sollte doch auch irgendwie gehen ;-)
yours
whoever/dbemerlin
http://roidracer.ncs.gr
Christian Kortes
> "Peter Heckert" schrieb
>>
>> Die Summe der Kehrwerte aller Quadratzahlen ist PI²/6.
>
> Das ist ja interessant - kannst du das mal zeigen (oder be-linken) bitte?
http://mathworld.wolfram.com/RiemannZetaFunctionZeta2.html
MfG,
Christian
Jasper Riedel
> "Jasper Riedel" wrote
> ...
> c) man speichere H(f) sowie die Länge von f, z.B. auf Diskette.
>
> Es gibt nun nur endlich viele Zahlen, die die gleiche Länge wie f
> haben, ungleich f sind und dennoch denselben Hashwert ergeben. Das
> Dekomprimieren ist daher recht einfach: man probiert für jede Zahl mit
> derselben Länge wie f, ob der Hashwert mit dem auf der Diskette
> gespeicherten Wert übereinstimmt. Ist dies der Fall, versucht man, die
> gefundene Zahl als Inhalt einer Festplatte zu interpretieren.
> Dies
> ergibt entweder die Originalplatte, oder
Aber wie soll ich das ohne das Original entscheiden können?
> ziemlichen Müll oder durch
> ganz grossen Zufall eine andere gültige Festplatte. Letzteres wäre
> aber erst recht interessant, denn auf dieser könnten jede Menge
> interessanter Dokumente, Filme, Musikstücke oder Programme gespeichert
> sein, die noch kein Mensch vorher gesehen hat.
Ja, gut ;)
Hermann Kremer
>"Peter Heckert" schrieb
>>
>> Die Summe der Kehrwerte aller Quadratzahlen ist PI²/6.
>
>Das ist ja interessant - kannst du das mal zeigen (oder be-linken) bitte?
Auf der Homepage von Robin Chapman von der University of Exeter
http://www.maths.ex.ac.uk/~rjc/rjc.html
ist ein Paper --> Miscellaneous articles ... --> Evaluating zeta(2)
mit (bis jetzt) 14 verschiedenen Beweisen dafür ...
Grüße
Hermann
--
Rainer Rosenthal
Ingo Menger wrote
> Hiermit patentiere ich das eben skizzierte
> Verfahren als "compresion by hashing -
> decompression with possible surprise" und
> erhebe Anspruch auf das geistige Eigentum
> an den Inhalten aller Files, die auf
> zufällig erzeugten gültigen Festplatten stehen.
Hallo Ingo,
ich habe schnell mal Dein Verfahren implementiert
und eine gerade nicht benötigte Platte damit
behandelt. Eingeklemmt zwischen zwei Gigabytes
fand sich da eine interessant aussehende kleine
Datei. Wie enttäuscht war ich aber, als ich da
bloss den altbekannte Käse las:
"Wer das liest, ist doof."
Also wenn Du Dein geistiges Eigentum daran anmelden
willst, dann viel Spass.
Und was hattest Du einklich mit dem Inhalt des Files
gemeint, in dem zu lesen stand:
"Nicht alle Zirbattel sollten erzollt werden."
???
Gruss,
Rainer Rosenthal
r.ros...@web.de
-
Eigentümlich kommt von Eigentum.
Klaus Loerke
> mein bruder hat mal mit ner zip datei (damals zu dos zeiten)
> experimentiert und eine 10k oder so zip datei
> dazu gebracht entpackt etliche MB groß zu werden.
> Dazu hat er in der zip datei eingetragen das eine
> bestimmte zeichenfolge im text n-mal vorkam.
> im ursprünglichem file kam die zeichenfolge
> 5 mal hintereinander vor, nach der veränderten
> datei 50000000 mal.
>
> also der umgekehrte fall, eine 5kb komprimierte datei
> zu 20-unendlich GB kriegen geht leicht, das umgekehrte
> sollte doch auch irgendwie gehen ;-)
wenn auf deiner Festplatte 50000000 mal _eine_ bestimmte Zeichenfolge
vorkommt, ist das durchaus möglich.
klaus
Hermann Kremer
>Philip Kügler <mfg.ichhasseuner...@keineWerbung.aon.niemals.at> wrote
in message <news:3fdb1752$0$11372$91ce...@newsreader01.highway.telekom.at>...
>
>zu 20-unendlich GB kriegen geht leicht, das umgekehrte
>sollte doch auch irgendwie gehen ;-)
Natürlich ... die vor 4 Wochen gefundene 40-ste Mersenne'sche Primzahl hat
als Textfile 6.5 MB, Du kannst sie aber mit genau 12 Bytes beschreiben:
2^20996011-1
http://mathworld.wolfram.com/news/2003-12-02/mersenne/
regards
Hermann
--
>yours
> whoever/dbemerlin
> http://roidracer.ncs.gr
Paul Ebermann
> Philip Kügler <mfg.ichhasseuner...@keineWerbung.aon.niemals.at> wrote [...]
>
> mal ein bisschen neben dem topic,
> mein bruder hat mal mit ner zip datei (damals zu dos zeiten)
> experimentiert und eine 10k oder so zip datei
> dazu gebracht entpackt etliche MB groß zu werden.
> Dazu hat er in der zip datei eingetragen das eine
> bestimmte zeichenfolge im text n-mal vorkam.
> im ursprünglichem file kam die zeichenfolge
> 5 mal hintereinander vor, nach der veränderten
> datei 50000000 mal.
>
> also der umgekehrte fall, eine 5kb komprimierte datei
> zu 20-unendlich GB kriegen geht leicht, das umgekehrte
> sollte doch auch irgendwie gehen ;-)
http://colon.colondot.net/~mbm/42.zip
ist nur 42 KB groß.
Wer mag, darf die mal entpacken ...
Paul
Gottfried Helms
> "whoever" skribis:
>
> http://colon.colondot.net/~mbm/42.zip
>
> ist nur 42 KB groß.
>
> Wer mag, darf die mal entpacken ...
>
>
Größeninformation nur ein Fragezeichen. Verdächtig...
Soo groß?
Ich hab's mir dann erspart, das ganze Zip auszupacken.
Wieviel gibt das denn so am Ende ca? Eine Zentillion ;-)
Gottfried
Paul Ebermann
> Paul Ebermann schrieb:
>
> > http://colon.colondot.net/~mbm/42.zip
> >
> > ist nur 42 KB groß.
> >
> > Wer mag, darf die mal entpacken ...
>
> Scharfes Teil! Leider gab die erste Datei (0.dll) als
> Größeninformation nur ein Fragezeichen. Verdächtig...
> Soo groß?
Etwas über 4 Gigabyte, die Datei, wenn ich mich richtig
erinnere.
(Auf meiner Festplatte ist nicht soviel Platz, ich
habe es also nicht ausprobiert.)
> Ich hab's mir dann erspart, das ganze Zip auszupacken.
> Wieviel gibt das denn so am Ende ca? Eine Zentillion ;-)
Ich habs mir nicht ausgedacht :-)
Wenn du im Netz mal nach 42.zip suchst, findest
du Berechnungen, wo man auf 4 Petabyte kommt.
Paul
Ingo Menger
> Hallo Ingo,
>
> ich habe schnell mal Dein Verfahren implementiert
Ach.
> und eine gerade nicht benötigte Platte damit
> behandelt.
Du programmierst schnell, aber das mußt Du auch, denn offenbar besitzt
Du mehrere vernetzte Quantencomputer. :-)
> Und was hattest Du einklich mit dem Inhalt des Files
> gemeint, in dem zu lesen stand:
>
> "Nicht alle Zirbattel sollten erzollt werden."
>
Das stand wohl unter /tmp.
Es müßte aber auch ein File "Antwort" mit dem Inhalt "42" geben.
Markus Becker
> Das stand wohl unter /tmp.
> Es müßte aber auch ein File "Antwort" mit dem Inhalt "42" geben.
Das lässt hoffen. Ma gugge:
#v+
becker@linux:~> which Answer
/etc/life/universe/rest/Answer
/usr/real/life/women/Answer
/usr/real/life/kumpel/Answer
becker@linux:~> cat /etc/life/universe/rest/Answer
00.42 (HHG2TG::PANIC_NOT, Know where your towel is!)
becker@linux:~> cat /usr/real/life/women/Answer
00.00 (this::seXfree86::OPPOSITE, No! Go fuck yourself!)
becker@linux:~> cat /usr/real/life/kumpel/Answer
08.15 (all::freebeer86::ABERIMMER, Klar, lass' uns ein' sauf'n gehn!)
[ ... ]
becker@linux:~> cat /etc/life/universe/rest/Question
cat: /etc/life/universe/rest/Question: Datei oder Verzeichnis nicht gefunden
becker@linux:~> cat /usr/real/life/women/Question
any
becker@linux:~> ls /etc/life/universe/rest
Answer
becker@linux:~> ls /etc/life/universe
faq fqa rest
becker@linux:~> ls /etc/universe/life/faq
[none]
becker@linux:~> ls /etc/universe/life/fqa
Answer (in blau, weil sym-link)
becker@linux:~> cat /etc/universe/life/fqa/Answer
42 (HHG2TG::PANIC_NOT, ...)
becker@linux:~> man Answer
see universe
becker@linux:~> man universe
Formatiere universe(1) neu, bitte warten...
System shutting down. Please stand by.
...login^Mroot^Mey, Scheisse, was soll das?...|/-\|/-...
^C^Z^G
Ctrl-Alt-Del
-Bip-
#v-
Mift.
Wieder nix.
Markus
Peter Heckert
Jasper Riedel wrote:
>> Noch effizienter wäre es, ein Programm zu schreiben, das die Folge der
>> natürlichen Zahlen generiert. Einen besseren Kompressionsfaktor kann
>> es garnicht geben.
>
> Das verstehe ich nicht, kannst du mal einen Wink geben?
Ganz einfach:
Man bildet jede Datei durch einen Index in die Menge der natürlichen
Zahlen ab. Der Index zeigt auf eine Zahl, die das gleiche Bitmuster hat.
Der Kompressionsfaktor ist 1.
Besser und einfacher gehts nicht, wenn das Verfahren beliebige Dateien
verlustlos komprimieren soll.
Alle Verfahren, die bestimmte Dateien verlustlos komprimieren, müssen
nämlich notwendigerweise andere Dateien aufblähen, denn wenn das
Komprimat stets kürzer wäre als das Original, dann gäbe es ja mehr
unterschiedliche Originale als Komprimate ;-)
peter
--
Reality is _not_ an elephant.
For a start, it's a rainbow.
Jasper Riedel
> >> Noch effizienter wäre es, ein Programm zu schreiben, das die Folge der
> >> natürlichen Zahlen generiert. Einen besseren Kompressionsfaktor kann
> >> es garnicht geben.
> Jasper Riedel wrote:
> > Das verstehe ich nicht, kannst du mal einen Wink geben?
> Ganz einfach:
>
> Man bildet jede Datei durch einen Index in die Menge der natürlichen
> Zahlen ab. Der Index zeigt auf eine Zahl, die das gleiche Bitmuster hat.
>
> Der Kompressionsfaktor ist 1.
Jetzt verstehe ich den gag.
> Besser und einfacher gehts nicht, wenn das Verfahren beliebige Dateien
> verlustlos komprimieren soll.
Na klar, nur ist der Index im Schnitt mindestens so platzraubend (-bedürftig)
wie die Datei (die Zahl aus N) selbst ;)
> Alle Verfahren, die bestimmte Dateien verlustlos komprimieren, müssen
> nämlich notwendigerweise andere Dateien aufblähen, denn wenn das
> Komprimat stets kürzer wäre als das Original, dann gäbe es ja mehr
> unterschiedliche Originale als Komprimate ;-)
Klar, Gruss
Sebastian Kapfer
> a) man benutze eine gute Hash-Funktion, die Zahlen beliebiger Länge auf
> Zahlen der Länge m (z.B. 8 Mbit = 1MB) abbildet. Eine gute
> Hash-Funktion H(n) zeichnet sich dadurch aus, daß die
> Wahrscheinlichkeit, daß (a <> b and H(a)=H(b)) gilt, nahe bei 1/2**m
> liegt. Insbesondere dann, wenn sich a und b nur in wenigen Bits
> unterscheiden, sollte der Haswert dramatisch differieren.
Juhu -- jetzt werden meine Daten nicht mehr nur vom Festplattenroulette
gefährdet, sondern auch noch von halbgaren Hashalgorithmen :-)
> Dies ergibt entweder die Originalplatte, oder ziemlichen Müll oder
> durch ganz grossen Zufall eine andere gültige Festplatte.
Was ist eine "gültige Platte"? Eine mit gültigem Dateisystem? Eine,
deren Dateinamen im Duden stehen?
> Hiermit patentiere ich das eben skizzierte Verfahren als "compresion by
> hashing - decompression with possible surprise" und erhebe Anspruch auf
> das geistige Eigentum an den Inhalten aller Files, die auf zufällig
> erzeugten gültigen Festplatten stehen.
Na von mir aus -- wenigstens wird dieses Patent in der Praxis niemanden
stören. Die Hoffnung, dass ein Patentamt es als Unfug oder Neuheit von
vorgestern zurückweist, habe ich ohnehin nicht. Du musst nur noch ein
paar sinnfreie Juristenfloskeln einstreuen, dann geht das durch :-)
SCNR
Arne Schwabe
>> also der umgekehrte fall, eine 5kb komprimierte datei
>> zu 20-unendlich GB kriegen geht leicht, das umgekehrte
>> sollte doch auch irgendwie gehen ;-)
>
> http://colon.colondot.net/~mbm/42.zip
>
> ist nur 42 KB groß.
>
> Wer mag, darf die mal entpacken ...
leicht verändert, der Schrecken aller Mailscanner, die sich erstmal
3-4 min todentpacken, bis denen das zu groß wird oder zu viel cpu
gezogen hat. (Gegen das Orginal haben die ja Checklisten).
Arne