| Die letzten 10 Beiträge |
| Genie |
Hattest recht. Hab einen Überlauf übersehen. jetzt ist die Zahl an bytes genauso groß wie die Zeichenfolge. |
| eulerscheZahl |
Ok, versuche mal folgendes:
Du zerlegst die gesamte zu komprimierende Datei im Gruppen von je 30 Byte, komprimierst die alle einzeln auf 8 Byte. Das kannst du auch gerne rekursiv machen, also das komprimierte nochmal komprimieren, bis du am Ende eine Datei von 8 Byte hast.
Spiele damit ein wenig herum, komprimiere einige Dateien und versuche, daraus wieder den originalen Inhalt wiederherzustellen. Dann wirst du schon merken, dass das nicht funktioniert. Mit 30 Byte kannst du eben einfach mehr Informationen speichern, als mit 8, daran ist nicht zu rütteln. |
| Genie |
Mann muss ja die zahl die 8byte hat wieder exponieren dann ergibt sich wieder die Hauptzahl. Die Hauptzahl (ULLONG_MAX-Grenze) entspricht dem String mit 30Byte und aus dieser Hauptzahl wird das Gesamte Dokument zurückberechnet. auf jeden fall funktionierts. Ich kann zwar kein größeres Dokument komprimieren da ich nicht weis wie man über die ULLONG_MAX Grenze kommt aber kleinen Strings funktionierts. Mein Algorithmus macht aus einem Dokument nur eine einzige Zahl, die dann abgespeichert wird. |
| eulerscheZahl |
Ich fasse mal zusammen, was ich verstanden habe:
Du kannst aus 30 Byte 8 Byte machen - und zwar als eindeutige Zuordnung.
Für 30 Byte gibt es aber 256^30 verschiedene Möglichkeiten, für 8 Byte nur 256^8. Das kann gar nicht funktionieren.
Kompressionsprogramme arbeiten so, dass sie Zeichen umkodieren. z.B. kommt der Buchstabe 'e' in Texten häufig vor, da wäre es also ratsam, keine 8 Bit zu verwenden, sondern nur 3 oder 4. Bei kaum verwendeten Sonderzeichen kann man dagegen auch mal mehr als 8 Bit spendieren. Wenn du aber einen Film mit zip/rar/tar.gz/7zip/... komprimieren willst, wird die Datei nicht kleiner werden - die Bitfolge ist einfach zu unregelmäßig, um da etwas optimieren zu können. |
| Genie |
Die Datei kann man ohne weiteres wieder dekomprimieren, so dass die alte Datei wieder vollständig dasteht. Ich weis nur nicht ob es ein Problem darstellt dass die zu logarithmierende Zahl mehrere millionen stellen hat.
Ich habe schon ein kleines Programm geschrieben, der ULLONG_MAX ist aber die Grenze dass sind vl 30 Zeichen, also 30 Byte, die man komprimieren kann auf 8 Byte |
| eulerscheZahl |
Kannst du die Daten denn auch wieder dekomprimieren?
Bei Hashes - zumindest im Kryptobereich - soll ja genau das nicht gehen. |
| Genie |
Hallo Karlito,
Jetzt hätte ich eine Idee wozu man den Algorithmus verwenden kann. Wenn man nur einen bestimmten Logarithmus dieser gewonnenen Zahl abspeichert könnte man damit Daten komprimieren.
Was ist deine Meinung dazu? |
| Karlito |
Ich glaube nicht. Mit solch grundlegenden Dingen beschäftigen sich so viele kluge Leute, dass ich bezweifle, dass dir da etwas Bahnbrechendes gelungen ist. Das heißt nicht, dass Du aufgeben solltest, aber offensichtlich musst du deine Kenntnisse stark vertiefen.
Gruß,
Karlito |
| Genie |
Könnte man meinen Algorithmus irgendwie vermarkten. Man könnte den doch für digitale Signaturen verwenden oder zur Verschlüsselung von Dokumenten.
Der Algorithmus kann definitiv ein Dokument in einen Zahl mit einer rießigen Anzahl von Stellen verwandeln. |
| Karlito |
Ah, OK. Damit ist es keine Hashfunktion. Eine größere Menge auf eine kleinere Menge (Definition einer Hashfunktion) ohne Kollisionen abzubilden ist nicht möglich.
Du hast also irgendetwas erfunden, was jedoch keine Hashfunktion ist.
Gruß,
Karlito |
| Es sind weitere Beiträge zu diesem Thema vorhanden. Klicken Sie hier, um sich alle Beiträge anzusehen. |
