Richtig mit Winrar packen

[Sheldon]

Die absolut beste Packmethode wäre die Stellenangabe des Datenblockes in PI.
Da PI keine Wiederholungen kennt, ist jeder beliebige Datenblock da mit ziemlicher Sicherheit irgendwo drin enthalten.
Gibt man nun lediglich die Startposition dieses Blockes in PI an, so kann man mit dieser einen Zahl den gesamten Ddatenblock rekonstruieren.

Das Komprimieren dauert natürlich extrem lang, da man diese Anfangsstelle nicht so leicht finden kann.

Was ist PI? 3,141...?

[Marathon]

Was ist PI? 3,141...?

ja
Die Kreiszahl.
Umfang eines Kreises geteilt durch den Durchmesser des selben Kreises.

Merksatz (Anzahl der Buchstaben gleich Ziffer in PI):
"Ist's doch o Isaac schwierig zu wissen wofür sie steht"
3,1415926535

[Sheldon]

ja
Die Kreiszahl.
Umfang eines Kreises geteilt durch den Durchmesser des selben Kreises.

Merksatz (Anzahl der Buchstaben gleich Ziffer in PI):
"Ist's doch o Isaac schwierig zu wissen wofür sie steht"
3,1415926535

Wenn die Komprimierung zu lange dauert, ist das eh nichts für mich da ich große Datenmengen mit dieser Methode packen muß. Ich bin zwar bereit, denn Rechner auch mal über Nacht laufen zu lassen, aber nicht über Tage hinweg.

Ich möchte 16 GB mit einer Kompressionsrate von 10% packen, so wie ich dieses auch runtergeladen habe.

[Marathon]

Du solltest einfach WinRar mit Einstellung "Gut" statt "Beste" benutzen und kein Solid anhaken.
"Beste" braucht nur unnötig viel Zeit für unwesentlich bessere Resultate und "Solid" verschlechtert die Archivqualität im Schadensfalle drastisch.

Für 16 GB braucht ein moderner Quadcore der unteren Klasse (i5 750) nur ca 1-2 Stunden.

Die modernen CPUs haben wirklich mächtig Dampf, was man auch merkt, wenn man mal Karten der Landesvermessungsämter exportiert und umwandelt.
Das geht mit derzeitiger Technik phänomenal schnell, während man sich selbst mit Dual Cores noch einen abbricht, weil es so eklig lange dauert.

Der Wegfall des FSB und der Level-3-Cache bringen enorm was.

Wichtig ist auch die Festplattenbandbreite. Man sollte von einer Festplatte nur lesen und auf eine andere Festplatte nur schreiben.
Benutzt man für lesen und schreiben dieselbe Festplatte, dann nützt einem auch ein schneller Prozessor nichts, weil der die nötigen Daten nicht schnell genug geliefert bekommt und die meiste Zeit nur Däumchen dreht.

[Sheldon]

Ich hab aber keinen Quad sondern nur einen altersschwachen X2-4200. Bis jetzt hat er mir gereicht und ich wollte eigendlich warten bis die X6 oder X8-CPUs in bezahlbare Regionen rücken bevor ich mir einen neuen Rechner zulege.

[Denkpoli]

Die absolut beste Packmethode wäre die Stellenangabe des Datenblockes in PI.

Das werden wir sehen!

Da PI keine Wiederholungen kennt, ist jeder beliebige Datenblock da mit ziemlicher Sicherheit irgendwo drin enthalten.
Gibt man nun lediglich die Startposition dieses Blockes in PI an, so kann man mit dieser einen Zahl den gesamten Datenblock rekonstruieren.

Davon geht man heute aus.

Das Komprimieren dauert natürlich extrem lang, da man diese Anfangsstelle nicht so leicht finden kann.

Rechnen wir mal nach:

Festlegungen:
1. Als Datenblock benutzen wir deinen Beitrag. Er hat ungefähr 400 Buchstaben, was ich hiermit als Tatsache festlege.
2. Dein Datenblock ist ein gewöhnlicher Text. 100 mögliche Symbole sind mehr als ausreichend, um einen solchen ( einschließlich Ziffern und Sonderzeichen ) darzustellen. Deswegen benutze ich hier als Grundlage das 100er - Zahlensystem, was auch noch den Vorteil hat, dass es so herrlich kompatibel zum 10er - System ist.

Berechnung:
1. Die Wahrscheinlichkeit, dass ein bestimmtes Symbol im Text mit dem einer gegebenen Stelle in Pi übereinstimmt ist 1/100.
2. Die Wahrscheinlichkeit pe ( e steht für Einzelereignis, in dem Fall, dass der gesamte Textblock übereinstimmt ), liegt dann bei 1/100^400 = 10^(-800).
3. Die Verbundwahrscheinlichkeit pv errechnet sich in hier nach: pv=1-(1-pe)^n, wobei n für die Anzahl der überprüften Textblöcke steht.
4. Wenn wir uns nun damit begnügen, dass der Textblock mit einer Wahrscheinlichkeit von nur 50% gefunden wird, gilt: 0,5=1-(1-10^(-800))^n. Als Ergebnis erhalten wir n=6,931E799. Damit sollte klar sein, dass deine Aussage "Das Komprimieren dauert natürlich extrem lang" eine extrem starke Untertreibung darstellt.

Nochwas: Vergleiche mal die Anzahl der Stellen, die du brauchst, um die Zahl abzuspeichern, mit der Anzahl der Stellen, die der unkomprimierte Text hatte.

[twoxego]

Wenn die Komprimierung zu lange dauert, ist das eh nichts für mich da ich große Datenmengen mit dieser Methode packen muß. Ich bin zwar bereit, denn Rechner auch mal über Nacht laufen zu lassen, aber nicht über Tage hinweg.

Ich möchte 16 GB mit einer Kompressionsrate von 10% packen, so wie ich dieses auch runtergeladen habe.

dann machst Du am besten ein CSO oder ISO daraus.
programme die das können, gibt es wie sand am meer. die können in der regel auch im hintergrund arbeiten.

[GAP]

dann machst Du am besten ein CSO oder ISO daraus.
programme die das können, gibt es wie sand am meer. die können in der regel auch im hintergrund arbeiten.

In einem solchen Fall empfehle ich sich TrueCrypt anzusehen. Die Daten werden in einer als Laufwerk eingebundenen Datei gespeichert. Die Lese und Schreibvorgänge sind sehr schnell und die Handhabung ist sehr komfortabel.

[Schaschlik]

(...)

Sehr gute Berechnung. Pi wird sich dafür nicht eignen denke ich.

Nochwas: Vergleiche mal die Anzahl der Stellen, die du brauchst, um die Zahl abzuspeichern, mit der Anzahl der Stellen, die der unkomprimierte Text hatte.

Es ist nicht notwendig Pi zu speichern, da diese Zahl jeder neu berechnen kann, wass freilich einen enormen zusätzlichen Aufwand bedeutet. Gespeichert werden nur die Startpositionen und Länge der einzelnen Datenwörter "auf Pi".

Allerdings könnte man sich fragen, warum überhaupt PI verwenden und nicht eine Mandelbrotmenge mit fester Definition. Sollte vom Prinzip her genauso funktionieren und ist bzgl. der zugrunde liegenden Berechnungen für heutige Rechner schneller zu ermitteln.


Und überhaupt: warum sollte man denn (wenn man es schon so macht) jedes einzelne Datenwort "auf Pi" kodieren? Man könnte ebenso den ganzen Text auf Pi "irgendwo" zusammenhängend finden....

Da sind wir dann schnell bei den [Links nur für registrierte Nutzer]

[Denkpoli]

Pi wird sich dafür nicht eignen denke ich.

Es eignet sich auch keine andere Zahl. Eine Kompression ist nur durch das gezielte Ausnutzen von Redundanzen möglich. Man kann nicht einfach willkürlich die Codierung der Information ändern und erwarten, dass man dann ( im Durchschnittsfall ) weniger Speicherplatz braucht. Das wäre das Perpetuum Mobile der Informatik.

Es ist nicht notwendig Pi zu speichern, da diese Zahl jeder neu berechnen kann, wass freilich einen enormen zusätzlichen Aufwand bedeutet. Gespeichert werden nur die Startpositionen und Länge der einzelnen Datenwörter "auf Pi".

Da habe ich mich falsch ausgedrückt. Natürlich wird Pi nicht mitgespeichert. Das würde auch gar nicht gehen. Selbst wenn man zum Speichern eines Buchstabens nur ein Atom bräuchte, wäre die Anzahl der Atome im Universum, verglichen mit der Anzahl der Atome dieses Superspeichers, geradezu winzig.
Was man, wie du schriebst, wirklich abspeichern muss, sind die Startposition und die Länge des jeweiligen Datenblocks. Das sind aber auch wieder Zahlen, die selbst Speicherplatz benötigen. Und wie viele Stellen braucht man denn, um 6,931E799 exakt abszuspeichern?
Und nun bedenke: Das ist nicht der Durchschnittswert, sondern der Wert, den du bekommst, wenn du dich mit einer Trefferquote von 50% zufrieden gibst. Das ist sowas wie die Halbwertszeit eines radioaktiven Atomkerns. Die durchschnittliche Lebensdauer ist aber länger.

Allerdings könnte man sich fragen, warum überhaupt PI verwenden und nicht eine Mandelbrotmenge mit fester Definition. Sollte vom Prinzip her genauso funktionieren und ist bzgl. der zugrunde liegenden Berechnungen für heutige Rechner schneller zu ermitteln.

Und selbst wenn du es fertig bringst, den Berechnungsprozess und den Faktor hundert Quadrillionen zu beschleunigen ist das bei diesen Zahlen kein großer Unterschied zu vorher, davon abgesehen, dass wir inzwischen wissen, dass der Algorithmus nicht funktioniert.

Und überhaupt: warum sollte man denn (wenn man es schon so macht) jedes einzelne Datenwort "auf Pi" kodieren? Man könnte ebenso den ganzen Text auf Pi "irgendwo" zusammenhängend finden....

Genau das habe ich bei meinem Beispiel doch getan! ?(