wenn ich bis dahin nicht eine Enterpsrise version von delphi habe bestimmt *G*

ich habe einen tollen link gefunden dank dem Stichword RAD kompri

www-user.tu-chemnitz...compproj/2common.htm

sehr schöne seite.


aber hier ging es mir eigetnlich nur darum mit großen zahlen zu arbeiten nicht was ich damit vorhabe...

das ist ein gutes dokument. ich lese es mir mal durch!
ps: wenn du deinen algo fertig hast dann schreibt ihn mal!

es gibt doch bestimmt eine grenze, wenn man diese überschreitet gehen daten verloren oder net, wenn man zb 10gb au 1 bit komprimiert, lässt sich ja wohl nischt mehr mit dem bit anfangen

habe mich gerade mit meiner RAD kompri... versucht, doch leider ohne erfolgt ich kann jetzt wohl eine zahl z.b.
5456 - 500 nehmen sooft bis es nicht mehr geht aber alleding brauche ich dann die anzahl und das ergbnis und zusmammen ergibt das dann eine 3 stellige zahle die untereinander abgespeichert werden musss oder halt mit einem Trennzeichen.... naja warh aber eine schöne idee fand ich auf jedenfall wie die meisten RAD Komprision....

naja evtl. in paar jahren finde ich einen anderen weg mal sehen....

nein mimi es geht auch in ein paar jahren nicht....

du kannst nicht ALLES komprimieren wenn das gingen würde könntest die komprimierungja wieder komprimieren und so weiter bis du ein bit hast, und wie willst du denn aus einem bit wieder irgendetwas herstellen?

bitte glaub uns einfach

hab ich auch grad gesagt

Muss ich wohl einsehen, das es nicht funktionieren kann, aber es wird irgenwann funktionieren.
Nur die Frage wann es Funktionieren wird steht noch in den Sternen....

nein wird es eben net

Hallo Mimi,

ich wollte dich oben nicht entmutigen. Dein Ehrgeitz in dieser Sache ist durchaus respektwürdig. Ich befasste mich bis vor kurzem mit Folgen von 1 MB - Größe. Da wird es schon einige Generationen dauern, bis irgendwann mal einer alle möglichen Datenfolgen ausgerechnet hat

Hier mal eine Kleinigkeit, warum man durch den Teilalgorithmus nicht alle Folgen verlustfrei teilen kann: Wenn man die letzte Binärstelle anschaut, so wird es in Bitfolgen der Länge n immer (2^n)/2 gerade und (2^n) / 2 ungerade Folgen geben. Aus dem Grund wird 2 als Teiler nur in 50% der Fälle gehen. In den anderen Fällen musst du auf andere Teiler ausweichen. Dann hast du noch das Problem, selbst wenn du die Datei durchs Teilen von 4 GB auf 1KB runtergeteilt hast, dass du auch noch die Multiplikationsinformationen speichern musst. Die brauchen insgesamt mindestens wieder soviel Informationen wie die ursprüngliche Datei.

Naja, ich wollt das eben nur anmerken, damit du dich nachher nicht zusehr in Bereiche stürzt, die nicht gehen können. Allerdings ist bemerkenswert, dass du mit dem Teileralgo einen zumindest rekursiven Algorithmus gefunden hast für bestimmte Datenfolgen.

Ich denke bei binären Folgen müsste der Teiler pro Divisionsschritt >= 4 sein, damit du überhaupt einen binären Erfolg von mindestens 1 Bit pro Vorgang bekommst. Sehe ich das richtig? War nur ein Denkansatz ohne das jetzt nachzurechnen

Viele Grüße

\\ Backslash \\

ok eigentlich ist es doch möglich, wenn man einen packer schreibt, der den inhalt der datei immer durch die gleiche zahl teilt, meinetwegen, 10mio, dann ist die datei ja kleiner, und damit sie wieder lesbar wird, wird sie wieder mit 10mio multipliziert (bei jemandem, der den gleichen packer hat), und bei der multiplaktion ist dann praktisch die alte datei wiederhergestellt, also hätte jede auch noch so kleine zahl eine dazugehörige datei. natürlich ist es etwas kompliziert, wenn man nachkommastellen hat, aber doch machbar, oder ?

(Bitte nicht hauen )

F34r0fTh3D4rk hat folgendes geschrieben:

ok eigentlich ist es doch möglich, wenn man einen packer schreibt, der den inhalt der datei immer durch die gleiche zahl teilt, meinetwegen, 10mio, dann ist die datei ja kleiner, und damit sie wieder lesbar wird, wird sie wieder mit 10mio multipliziert (bei jemandem, der den gleichen packer hat), und bei der multiplaktion ist dann praktisch die alte datei wiederhergestellt, also hätte jede auch noch so kleine zahl eine dazugehörige datei. natürlich ist es etwas kompliziert, wenn man nachkommastellen hat, aber doch machbar, oder ? (Bitte nicht hauen )

Wow du bist ein richtiger profi.

Gibst erst deinen Senf zu etwas, was du anscheinend nicht vollständig gelesen hast und entwickelst dann eine Idee, die das Hauptthema dieses Threads ist.

Ich fand das Thema von Anfang an nachvollziehbar, aber leider hab ich nicht die Ahnung um zu sagen, ob das klappt.
Jedenfalls fand ich Mimi etwa vorschnell mit seiner Behauptung. Erst ausprobieren, dann Thesen posten, ist meiner Meinung sicherer.

Hi F34r0fTh3D4rk und OneOfTen,

ich habe hier ein paar Beiträge rausgelöscht. Klärt eure Differenzen bitte per PN!
An dieser Stelle sei euch beiden unsere Richtlinien nahe gelegt, vor allem der Abschnitt nummero 3.

Gruß,
raziel

Zitat:

ok eigentlich ist es doch möglich, wenn man einen packer schreibt, der den inhalt der datei immer durch die gleiche zahl teilt, meinetwegen, 10mio, dann ist die datei ja kleiner, und damit sie wieder lesbar wird, wird sie wieder mit 10mio multipliziert (bei jemandem, der den gleichen packer hat), und bei der multiplaktion ist dann praktisch die alte datei wiederhergestellt, also hätte jede auch noch so kleine zahl eine dazugehörige datei. natürlich ist es etwas kompliziert, wenn man nachkommastellen hat, aber doch machbar, oder ?

Schonmal daran gedacht, dass da ein großer Dezimalbruch rauskommen kann? Um es verständlicher zu machen. Wenn du jede Datenfolge jeder x-beliebigen Größe durch 2 oder durch 3 teilst (immer), so wirst du vielleicht eine Verkleinerung bekommen, außerdem auch einen Dezimalbruch bzw. Teilerrest. Man könnte jedoch mit der Modulo-Funktion herausfinden ob eine Datenfolge ohne Rest teilbar ist. Allerdings gibt das immer noch keine Kompression bei Daten, die zum Beispiel aus Zufallsgeneratoren stammen, da die Wahrscheinlichkeit für eine gerade Folge genauso hoch sein sollte wie die für eine ungerade Folge, bzw. deren letzte Stelle 0 oder 1 ist

Zitat:

dass du mit dem Teileralgo einen zumindest rekursiven Algorithmus gefunden hast für bestimmte Datenfolgen

was meinst du mit "rekursiven Algorithmus" ?
eine sich immer widerholde funktion ?

@F34r0fTh3D4rk
genau davon sprach ist die ganze zeit

@Backslash
das ist bei meinen verzuchen mit kleinen zahlen rauß gekommen ich habe z.b. ein Programm geschrieben das immer

4000 / 100 = 40
aber bei andren zahlen z.b.

6548 / 100 = 65,48
also wieder 4 zeichen die ich abspeichern muss also bringt das nichts dann dachte ich an - nehmen da war die anzahl zu hoch.

das problem ist meiner ansicht nach wenn ich eine große zahl in 4 schritten duchgehe und die 4 ergbnisse teile bis es nicht mehr geht habe ich wegen der nach kommerzahlen eine zu lange zhal rauß.

aber es war eine schöne idee.
Man müste nur eine möglichkeit finden zahlen ohne koma zu bekommen, dann hätte das verfahrnen bestimmt erfolgt. wobei das verfahren bestimmt lange zeit braucht.

Ich habe in meinen test gesehen das es ca 2-4 minuten dauert eine Asccicode kette zubilden dabei war die datei nur ca 74,4 kb rauß(die eular.txt aus system32 *G*)

Oder seit ihr anderansicht ? das problem ist ja wie schon gesagt: bei ungeraden zahlen.

edit:
evlt. kann man ja ein eigenen zufalls generatur entwickeln wenn ich bei Random immer den gleichen start werde angebne bekomme ich immer den gleichen zahlen folge rauß.... vileicht kann man darauß was machen

Rekursiver Algotithmus ist ein normaler Algorithmus. Sprich: der Algorithmus ruft sich wieder selber auf. Müsstest du aber kennen . Ich kenne darunter zu mindestens nix anderes. Ich glaub aber nich, dass man durch Teiler überhaupt jemals Daten komprimieren kann. Ich würde ehr in Bits reingehen, also dass z.B. 2 Zeichen in einem Byte gespeichert werden.

würde es denn sinn machen: 0101001001010 / 100 zu teilen ?
wie macht man sowas ?
(wegen der 0 am anfang)
vileicht geht das so...

Ich nehm mal ein Beispiel. Du hast nur den Text ABBBABBA (natürlich viel länger). Da es nur 2 Zeichen sind, schriebst du in eine Bibliothek, die am Anfang der Datei ist, das es nur die beiden Zeichen gibt und A=0 und B=1 ist. Damit erhälst du die Bitfolge (ohne Bibliothek): 01110110. Damit hast du 8Byte in 1Byte(=8Bit) umgewandelt, sparst also bei langen Texten viel Speicher und die Bibliothek wird bei großen Dateien sich kaum bemerkbar machen.

Meine MEinung zu Krompression: So wie es andere hier schon erwähnt haben: Irgendwann ist Schluss mit der Komprimierung.
das Prinzip der Komprimierung ist die Reduzierung der Redundanz.

@Heiko
ja aber dann musst der text/datei nach einen bestimmten schma aufgabut sein oder nicht ?
was ist beim folgenden Text:

ahjlifemvlalei3394*fklasjfsaf{]ffslkflskflskl ???

@Tilo
Ja bei der herkömlichen verfahren, aber ich wollte ja ein verfahren entwickeln was mind. 80-95 % Komprimiert, was bringen erkömliche verfahren an komprimirungs raten ? 30 - 50 %?

Dein Beispiel für eine Komprimierung werde ich heute Nachmittag, wenn ich nach dem Training noch Zeit habe, ausprobieren. Ich glaub aber nicht das man den Text stark komprimieren kann, da er so ziemlich kurz ist. Ich habe gerade mal versucht dein Beispieltext mit Win-Rar zu packen.
Ergebnis: ungepackt: 45Bytes
gepackt: 114Bytes (bei höchster Kompressionsrate)

So weit ich weiß arbeiten die Packer nach dem Prinzip wie ich es dir vorgeschlagen hatte. Das Problem bei so kurzen Texten ist die Bibliothek, dass die zu groß wird.

Die Packraten gehen teilweise deutlich über 30-50%. Mit Win-Rar habe ich gerade eine html-Seite auf 8% komprimiert, also 92%.