Beiträge von Mars

Ohje, wenn Andy die 50 geknackt hat muss ich wohl nochmal schrauben

Ich hatte einfach keine Lust auf alt bewährtes zurückzugreifen und hab meine Idee (Prediction geboosteter dynamischer Huffman Tree) weiterverfolgt. Leider hat das eine entscheidende Schwäche: Ganze Bits.

Egal wie gut die Vorhersage ist, im Regelfall kann man 3 Bit/Symbol nicht unterschreiten, da im Huffman-Tree, genauso wie bei Telefonnummern keine vollständigen 01-Ketten existieren dürfen die gleichzeitig der Anfang einer anderen Kette sind. Wenn es also eine 2Bit Kette gibt (z.B. "01"), dann kann es keine einzige weitere Kette geben die mit "01" beginnt. Der Tree wird "optimal" erstellt, und wird den Teufel tun, bei sämtliche anderen Zeichen die Bitketten um 1 zu verlängern, nur weil die Chance für ein "a" als nächstes Zeichen 20% ist (das wäre aber nötig um unter die 3Bit/Symbol zu kommen).

Der Ansatz ist super, rennt aber bei Huffman komplett gegen die Wand...

Nächste Idee ist dann: Prediction geboosteter arithmetischer Kodierer. Der sollte mindestens 10%-20% besser klarkommen (damit sollte auch 60% bei Text kein Problem sein).

Ich hab etwa 2000 Zeilen Spaghetticode fabriziert der zu allem Überfluss auch noch ganz besonders langsam ist und nicht die Kompression erreicht die ich gerne hätte^^

Werde das irgendwann Morgen abgeben, viel Spaß beim Durchlesen Oscar

PS: Nächstes Mal wird die 50% in Angriff genommen. Das ist zwar noch ein paar Meter, aber das schaffen wir

Ja, damit klappt alles, vielen Dank

Dachte immer das ist im Prinzip dasselbe. Quicksort heißt ja normalerweise auch immernoch Quicksort, selbst wenn ich ab einer gewissen Teife z.B. InsertionSort (wie in der Array.au3) verwende... Muss ich wohl nochmal nachlesen ist schon ein paar Tage her

Je nachdem wie man das Verfahren nennen möchte. Manchmal heißt es auch Radix-Sort.
Das ist übrigens in fast allen Fällen die mit großem Abstand schnellste Sortiermethode, sofern man eine gute Repräsentation der "Buckets" findet. (bei Dezimalzahlen z.B. die Ziffern -> 10 Buckets -> Iterativ), bei Buchstaben -> 256 Buckets Iterativ, etc etc. Das Größte Problem der Methode ist es eine gute Methode für die Bucketdefinition zu finden (bei hochdimensionalen Daten wie z.B. einem WString kann nicht einfach 2^16 Buckets nutzen, das ist dann wieder zu Speicherintensiv und zu langsam, bei floats kann man z.B. auch nicht einfach die Ziffern verwenden, da muss man kreativ werden).

Probleme die ich kenne sind:
- Bei GDI+ wurden irgendwelche Returnwerte und Konstanten geändert. Ggf. muss man hier einiges Anpassen, wenn man GDI+ verwendet. (UEZ weiß hier mehr).

- Bei _ArrayDisplay friert das Skript (als "toter" Prozess mit Volllast im Taskmanager sichtbar, man kann ihn dort auch beenden) ein, wenn man WÄHREND _ArrayDisplay aktiv ist das Skript via Tray beendet.

- Bei Rechnungen mit Exponent & Minus Kombinationen (z.B. 11 - 2^4 = 27) wurde irgendwas umgestellt. Das war teilweise vorher (3.3.14.5) schon "schief" ist jetzt aber noch "schiefer". Klammern verwenden löst das Problem.

Ggf. musst du das EN-Forum lesen, vllt gibt es noch mehr Probleme die ich nicht kenne (oder probleme die niemand aus dem DE-Forum kennt)

Empfehlung: Probier es aus. "Wahrscheinlich" geht alles gut (vor allem wenn dich die 3 oben genannten Sachen nicht betreffen).

Moin,

der Thread hier ist absichtlich im Offtopic, weil er einfach nur zum Spaß ist

Anbei meine Interpretation von "Welche Expression ergibt eigentlich 27" und "Welche Expression ergibt eigentlich -5"

Motiviert durch Musashi (Zitat: "$x = 11 ------ 2^4 ; -5") ist hierbei ein Skript entstanden

For $i = 0 To 4 Step 1
    ; Zahl     = 27
    ; Länge    = 12 Zeichen
    ; Versuche = 10
    $s = ExpressionThatEqualsWithLessDigits(27, 12, 10)
    ConsoleWrite($s & ' = ' & Execute($s) & @CRLF)
Next

For $i = 0 To 4 Step 1
    ; Zahl     = -5
    ; Länge    = 12 Zeichen
    ; Versuche = 10
    $s = ExpressionThatEqualsWithLessDigits(-5, 12, 10)
    ConsoleWrite($s & ' = ' & Execute($s) & @CRLF)
Next

; $i    - Zahl (muss kein integer sein, aber "einfache" Zahlen aus der Menge der Quotienten sind besser)
; $iLen - Länge der Expression die herauskommen soll
; $n    - Anzahl Versuche von denen der genommen wird der die "wenigsten Zahlen" enthält.
Func ExpressionThatEqualsWithLessDigits($i, $iLen = 15, $n = 10)
    Local $a[$n][2], $j = $iLen, $k = -1
    For $h = 0 To $n - 1 Step 1
        $a[$h][0] = ExperssionThatEquals($i, $iLen)
        If $a[$h][0] = '' Then
            $a[$h][1] = $iLen
        Else
            $a[$h][1] = CountDigits($a[$h][0])
        EndIf
        If $j > $a[$h][1] Then
            $j = $a[$h][1]
            $k = $h
        EndIf
    Next
    If $k = -1 Then Return 'NOT FOUND'
    Return $a[$k][0]
EndFunc

Func CountDigits($s)
    Return StringLen(StringReplace(StringReplace(StringReplace(StringReplace(StringReplace($s, '+', '', 0, 1), '-', '', 0, 1), '*', '', 0, 1), '/', '', 0, 1), '^', '', 0, 1))
EndFunc

Func ExperssionThatEquals($i, $l = 20)
    Local $s = ''
    For $_ = 0 To 99999 Step 1
        $s = RandomExpression($l)
        If Execute($s) = $i Then Return $s
    Next
    Return ''
EndFunc

Func RandomExpression($l)
    Local $s = '', $a = ['1', '2', '3', '4', '5', '+', '-', '*', '/', '^'], $x = ''
    For $i = 0 To $l - 1 Step 1
        $x = $a[Random(0, UBound($a) - 1, 1)]
        If StringIsDigit($x) Then
            If StringIsDigit(StringRight($s, 1)) Then
                $i -= 1
            Else
                $s &= $x
            EndIf
        Else
            $s &= $x
        EndIf
    Next
    Return (StringIsDigit(StringRight($s, 1)) And StringIsDigit(StringLeft($s, 1))) ? $s : RandomExpression($l)
EndFunc

Beispieloutput:

1/+5/5^-3--2 = 27
3/++3-5^+2+1 = 27
3-2^+3*+-3^1 = 27
4-+5*-4++--3 = 27
3+-4^1*+3*-2 = 27
1+-+1*2-2+-2 = -5
1^4---4+-4/2 = -5
2+3+-5/2*++4 = -5
5/-3*++3/++1 = -5
3/-1-++3+2/2 = -5
5^3----5^--2 = 100
4^1-3*+-2^+5 = 100
4*1^+4*--5*5 = 100

M

Es lässt sich wie ein assoziatives Array verwenden. Du kannst soetwas wie $Map["Klaus"] = "Isst am liebsten Wurst" machen. Früher musste man dafür ein Dict/DllStruct verwenden, oder (wenn man Variablen im "AutoIt-Datentyp" haben will) einen selbstgebauten Hashtable.

Endlich laufen meine UDFs die Maps verwenden auch mit der Stable. Bin sehr zufrieden damit

Ich kann kein Ruby... keine Ahnung was gchq.decode macht, keine Ahnung was Betrag(lolz) ist (ist das ein String? Braucht man in Ruby keine Anführungsstriche?), keine Ahnung was mir ein vermutlich seit 10 Jahren nicht mehr verfügbares Video bringt...^^ Sehr seltsam

Habe mal kurz reingeschaut und nichts herausgefunden

Falls es jemandem hilft: Hier ist eine Map wo jeder Wert als Chr($x) interpretiert wurde (+Blauwert)

Ich kann darin jedenfalls nichts erkennen

unnamed.png

Edit: Hier nochmal konvertiert. Motiviert von AspirinJunkie -> bigEndian

Jetzt steht da wenigstens "irgendwas"

unnamed.png

lg

M

Ich nominiere mich mit dem pastebin Beispiel selbst als Kandidat für den "worst abuse of the rules" Award. Dicht gefolgt von der Methode den vollständigen Text im Code zu speichern und nur auszugeben

Ist also technisch gesehen ein Pastebin-Upload der zu "komprimierenden" Daten und das Ausgeben der ID (8 Zeichen) eine valide Methode?

Bei einem NN zur Kompression ist natürlich wieder das Problem: In wie fern existiert bereits Vorwissen im Algorithmus. Angenommen ich trainiere ein 1GB NN mit unfassbar viel Text, dann kann ich extrem gut komprimieren, weil ich quasi eine Kopie von "jedem möglichen Text" in meinem Programm enthalten habe. Das wäre dann wieder soetwas wie: Ich habe das Wörterbuch nicht in den Komprimierten Daten, und ohne das Wörterbuch sind die komprimierten Daten keine valide Beschreibung der unkomprimierten Daten...

Wieder eine philosophische Fragestellung

Hier mal eine kleine Übersicht von dem "was ich denke was gilt" (das heißt nicht, dass es tatsächlich so ist. Nur mein subjektiver Eindruck)

Edit Nummer 20: Oops, es sind 2 Seiten geworden. Viel Spaß beim Lesen meine fleißigen Schüler

Entropiekodierer allgemein:

- Alle Daten haben irgendeinen Informationsgehalt. Entropiekodierer versuchen möglichst wenige Bits zu verwenden um diesen Informationsgehalt wiederzugeben.

- Huffman: Ersetzt "Symbole" (wir nutzen hier oft 8Bit Chars, aber ansich kann das "alles" sein) durch Bitfolgen die in einem Baum in einem Blatt enden (weshalb der Kodierer weiß, wann das nächste Zeichen anfängt)

- Arithmetisch: Ersetzt alle Daten durch eine Kommazahl. Genaueres muss man nachlesen. Der Witz ist: Dieser Entropiekodierer ist "quasi optimal" im Sinne von "es gibt quasi keinen besseren Entropiekodierer". Jetzt kommt eine spannende Frage: Warum gibt es überhaupt irgendwelche anderen Kodierer bzw. Kompressionsalgorithmen, wenn ein arithmetischer Kodierer schon der Beste ist?

(Einfache) Statische Version:

- Das (Wikipedia) Vorzeigebeispiel. Kommt auch gerne in der Schule oder frühen Semestern mal dran.

- Sehr einfach implementierbar/Klar definiert was man wo zu tun hat.

- Baut den Baum aus "allen" Daten auf (daher ist der Baum automatisch "optimal" aufgebaut, "globaler Kontext")

- Speichert eine Wahrscheinlichkeitstabelle, oder den Baum selbst in den komprimierten Daten.

- Wendet denselben Baum auf alle Daten an (extrem schnell, wenn man einen LUT aus dem Baum aufbaut)

- Erzielt eigentlich immer gute Kompression (Abhängig von Symbolanzahl und davon wie gut die Entropien der einzelnen Zeichen durch ganze Bits dargestellt werden können)

(Einfache) Dynamische Version:

- Im Prinzip 95% äquivalent zur statischen Version.

- Die Wahrscheinlichkeitstabelle wird gleichverteilt initialisiert.

- Nach jedem dekodierten Zeichen wird die Wahrscheinlichkeitstabelle aktualisiert und der Baum neu aufgebaut (das wars schon)

- Tausendfach langsamer als die statische Version, da man hier quasi jedes Mal einen neuen Baum züchten muss, wärend die statische Version einen einzigen Lookup in einem Array machen muss.

- Erzielt etwas schlechtere Kompression als die statische Version (da gerade zu Beginn eine Gleichverteilung angenommen wird, was ja offensichtlich nicht stimmt)

- Tradeoff zwischen schlechterer Kompression und Platzeinsparung durch kleineren Header (keine Wahrscheinlichkeitstabelle in den Komprimierten Daten)

Jetzt kommt das Große Aber:

Das "dynamische" tritt dir die Tür zu unbegrenzten Möglichkeiten auf. Vorher warst du an ein starres Konstrukt an dem man nicht viel herumschrauben kann gebunden. Klar kann man z.B. den Input vorverarbeiten ("Wörter" statt "Zeichen" als Symbole verwenden erhöht die Kompression), aber am Prinzip selbst lässt sich nichts ändern. Eigentlich hat die dynamische Version schlechtere Kompression als die statische, aber... was wäre wenn man xyz einbaut, was passiert, wenn man den Baum durch Steuerzeichen beeinflusst (z.B. "die nächsten 1000 Zeichen haben eine andere Statistik als die bisherigen, danach geht es aber mit den bisherigen weiter", Beispiel für "lokalen Kontext"), was passiert, wenn man das Nächste Symbol vorhersagt und den Baum entsprechend trimmt (damit er für das vorhergesagte Zeichen weniger Bits braucht, "lokaler Kontext"), was passiert, wenn man den Baum "vergessen" lässt was er schon gesehen hat, sodass er lokal besser angepasst ist, usw usw. Dann wird aus "schlechter" plötzlich "besser". Kleine Warnung: Der Rechenaufwand geht dabei sehr schnell durch die Decke. Hier muss man ggf. optimierte Datenstrukturen (wie z.B. einen MinHeap für den Tree) benutzen, sonst kann man bis Morgen auf das Ergebnis warten

Spoiler für die Frage:
Weil jeder (einfache) Entropiekodierer die Entropie pro Symbol (Zeichen) kodiert und NICHT die Entropie zwischen den Zeichen.
Beispiel: "1111122222333334444455555" und "5235114223133414424535251" sehen für einen Entropiekodierer "gleich" aus. Global betrachtet stimmt das, beide Strings enthalten dieselben Zeichen mit derselben Häufigkeit, ABER der erste String hat eine deutlich niedrigere Entropie und kann viel besser komprimiert werden als der 2te. Zu einer guten Kompression gehören also beide Seiten der Medaille: lokale Muster und globale Muster. Lokal ist: Wie steht mein aktuelles Symbol im Verhältnis zu seinen Nachbarn, Global ist: Wie steht mein aktuelles Symbol insgesamt zum kompletten Datensatz. Nur das globale Problem wird vom statischen Huffman (und vom arithmetischen Kodierer) gelöst, für das lokale Problem muss man sich etwas ausdenken PS: Deshalb ist es auch doof, dass immer von "Entropie" gesprochen wird und nicht von "Shannon Entropie", würde man letzteres verwenden könnte man (durch nachlesen) herausfinden, dass diese Definition nur für stochastisch unabhängige Zeichen gilt (was ja im Regelfall nicht so ist. Wir betrachten ja meistens nicht "rauschen auf 8Bit Zahlen", sondern "Text", oder "Programmcode" oder "Bitmap").

Eine andere Entropiedefinition (deren Name ich leider vergessen habe) ist: Die Länge des "kleinsten Programms" das die Daten reproduzieren kann. Damit kann man sich glaube ich besser vorstellen wie der Informationsgehalt wirklich aussieht. z.B. ein 1024x1024 Bitmap voller Schwarzweiß-Rauschen (das aber mit einer deterministischen Random Funktion erzeugt wurde) hat nur eine extrem kleine Entropie (weil man dafür mit wenigen Zeilen ein Programm schreiben kann das dieses Bild erzeugt), ein 1024x1024 Bitmap mit "echtem" Schwarzweiß-Rauschen hat extrem hohe Entropie, da man kein Programm schreiben kann das diese Daten erzeugt, ohne dass es die Daten selbst hardcoded enthält.

Auch lesenswert: https://de.wikipedia.org/wiki/Bedingte_Entropie
Mit der Info, dass die Entropie zukünftiger Zeichen gegen 0 konvergiert, je mehr Zeichen man bereits kennt. Übersetzt: Je besser ich vorhersagen kann was als nächstes Zeichen kommt, desto kleiner die Entropie. Wenn jemand deutschen Text schreibt und mit "Xyl" anfängt, weiß ich, dass er mit "ophon" aufhören wird. Entropie von "ophon" ist also = 0 (mit der Nebenbedingung, dass ich "alle vorherigen Zeichen" kenne, also quasi, "dass ich das Deutsche Wörterbuch kenne").

Ich mache es gerade so:
- Adaptiver Huffman Encoder (dank Heap (Array[2*n][3]) um den Tree zu konstruieren auch nativ recht performant)

- Im Header steht eine ID, wobei

-> 0 = Default (einfach alle 256 möglichen Symbole Gleichverteilt, ohne Anhang)

-> 1 = Hex (16 Symbole Gleichverteilt, ohne Anhang, wird nicht verwendet, aber vllt braucht man das irgendwann irgendwo)

-> 2 = Byte (hier kommt dann der min/max/exist anhang)

-> 3 = unused.

-> Hier könnte man noch zahlreiche weitere Modi hinzufügen für z.B. Base64, oder auch Vorgefertigte Wahrscheinlichkeitstabellen.

- (wenn ID = 2) Im Header steht minSymbol & maxSymbol (z.B. bei Text wäre das sowas wie 20 und 170, frei erfundene Werte)

- (wenn ID = 2) Dann Binär 150 (maxSymbol - minSymbol) Mal eine 0 oder 1 speichern, je nachdem ob das Zeichen da ist oder nicht

- Tree wird mit den vorhandenen Symbolen aufgebaut (gleichverteilt, z.B. 70 Symbole)

- Tree wird alle X Zeichen neu aufgebaut (weil es einfach zu langsam ist es nach jedem Zeichen zu machen, obwohl das eigentlich besser wäre)

- Prediction fällt leider flach. Die Ansätze die ich da habe sind zu langsam. Dann kommt man wirklich wieder bei 1Byte/sek raus.

- Vorgefertigte Tabellen fallen auch flach. Ich hab keine Lust erstmal 3 Tage lang unterschiedlichste Daten zu crawlen um mir die Tables zu basteln...^^

-> Sehr kleiner Header

- für kurzen Text ist die ID = 0 -> Header = 2 Bit, Kompression ist nicht so gut (logisch), aber bei kurzem Text besser, als wenn der Table schon länger als der Text selbst ist^^

- für langen Text ist die ID = 2 -> Header im Bereich von 100-200 Bit (je nach Anzahl verwendeter Zeichen)

- für "Kauderwelsh" ist die ID = 0 (z.B. "Dateien" die kein Text sind -> Da sind normalerweise alle 256 Zeichen drin, da braucht man nicht zu selektieren)

-> Adaptiv?

- Bei jedem Neuaufbau KANN (dafür gibt es ne config) die Wahrscheinlichkeitstabelle mit einem Wert <1.0 multipliziert werden. Der Encoder "vergisst" also ein Stück weit was er bereits gesehen hat. (je nach Parameter mehr oder weniger agressiv). Dadurch ist es möglich sich an die Daten "anzuschmiegen" und im Idealfall (der nie eintritt) ist der Tree so immer optimal für die lokal vorhandenen Daten geeignet. (die 500 "a" Chars die man aus Spaß an den Anfang gesetzt hat erhöhen also nicht mehr die Länge der Bitmuster der Sachen die man eigentlich kodieren will).

- Steuersymbole (nur eine Idee). Man könnte z.B. ein Resetsymbol (resettet die Wahrscheinlichkeiten), oder ein Boostsymbol (boostet die Wahrscheinlichkeit des letzten dekodierten Zeichens), oder ähnliches untermischen. Damit müsste man sich nochmal besser an die Daten anpassen können. Das sieht mir aber auch kompliziert aus (nicht das implementieren, sondern das "herausfinden wo ein Steuersymbol die beste Wirkung hat") also fällt es auch erstmal Flach^^

Soweit der Plan. Umgesetzt ist etwa 50%^^

Vllt bastel ich da eine kleine UDF draus wenn es fertig ist. Nach dem Wettbewerb haben wir dann 5 verschiedene ordentliche KompressionsUDF's

PS: Ich hab auch noch einen ollen arithmetischen Entropiekodierer, leider frisst der sich recht schnell fest (z.B. wenn die Schranken 1.00000000 und 0.9999999 sind und die Double Genauigkeit nicht ausreicht um weiterzugehen bis 1.000000001 und 1.000000000 die Schranken sind und 1.00000000 abgeschnitten werden kann). Die Zahlen hier sind nur ein Beispiel, meiner rechnet im Hex System, damit der kodierte Inhalt Hex und nicht Dec ist. Das Problem ist aber dasselbe. Um den sinnvoll einsetzen zu können müsste ich also erst eine Hex-Float UDF basteln die beliebige Genauigkeit beim Rechnen hat. Das wird aber nicht passieren

Pschhhhht, man postet doch nicht sein bestes Pferd vor dem Rennen

Bei der Länge von 3600 tippe ich mal auf einen statischen Huffman encoder, da kommen bei mir ähnliche Werte raus

PS: Da geht aber noch was... Benutze deine Fantasie

(auch wenn es verlockend ist, Algorithmen zu nutzen die weit verbreitet und erprobt sind. Wir sind hier ein Forschungsteam, wir brauchen den neuen Stuff )

Meine Aktuelle Idee ist (auch wenn sie leider viel viel viel zu langsam läuft):

- Adaptiver Huffman Encoder (soweit so gut)

- Der Tree startet gleichverteilt und wird nach jedem Zeichen aktualisiert (dann braucht man den Tree nicht in den Komprimierten Daten speichern)

- Der Tree wird außerdem mit Prognosen gefüttert und aktualisiert BEVOR er überhaupt das nächste Zeichen zu Gesicht bekommt. Damit ist die Kodierung noch besser, weil im Schnitt bessere Bitraten für zu kodierende Zeichen vorliegen, wenn die Prognosen korrekt waren (was bei einfachem Text zu 90%+ der Fall ist)

Probleme:

- Tree initialisierung ist Gleichverteilt (das ist ja gerade der Trick, damit man ihn nicht speichern muss), Presets könnte man aber erstellen (Häufigkeiten der Zeichen von "allem möglichen" wie "Text", "Win32PE", "Base64", etc. Diese Presets könnte man dann bequem mit z.B. einem einzigen Byte anwählen und hätte damit vorallem zu Beginn eine bessere Kompression... Diese Presets erstellen ist aber sehr aufwendig und dafür habe ich keine Kraft)

- Tree aktualisieren ist langsam

- Prognosen erstellen ist noch viel langsamer (dafür muss man eine halbwegs gute Auswertung von allem bisher Dekodiertem durchführen...)

Wenn man das alles macht schätze ich, dass locker 50%+ drin sind. Aber das werde ich nicht hinbekommen, weil es zu viel Arbeit ist. Vllt hat ja jemand Lust die Idee umzusetzen^^

Ich glaube das liegt nicht an BkColor, sondern an GuiSetState(). Was man dagegen tun kann weil ich leider auch nicht...

Ggf. ist es auch nicht möglich ein Fenster ohne irgendeinen Fokus anzuzeigen.

Edit: Da war Oscar schneller und da gibt es sogar eine Lösung

#include <GuiButton.au3>
#include <GUIConstantsEx.au3>

GUICreate("My GUI Button",300,200,0,@DesktopHeight/2)
Opt("GUICoordMode", 2)

Global $Button_1 = GUICtrlCreateButton("ja", 10, 30, 100)
$yy=_GUICtrlButton_GetFocus($Button_1 )

Global $Button_2 = GUICtrlCreateButton("nein", 0, -1)
$zz=_GUICtrlButton_GetFocus($Button_2 )

GUISetState() ; wenn man das hier wegkommentiert hat niemand den Fokus

$yyyy=_GUICtrlButton_GetFocus($Button_1 )
$zzzz=_GUICtrlButton_GetFocus($Button_2 )

MsgBox(0,"","$yy::"&$yy&"   $zz:: "&$zz&"   $yyyy:: "&$yyyy&"   $zzzz:: "&$zzzz)

While 1
$msg = GUIGetMsg()
If $msg = $GUI_EVENT_CLOSE Then ExitLoop
WEnd

M

Bei mir ist es das genaue Gegenteil: Kompression ist "okay" (winrar macht daraus 2700 Bytes... also geht hier noch was), Geschwindigkeit mmmmh

============================================================

Result for "Mars"

============================================================

Decompressed = Original: True

Length Original: 6033

Length compressed: 3949

Length decompressed: 6033

Compress-Ratio: 34.543 %

Time compressed: 10277 ms

Time decompressed: 9389 ms

============================================================

Eine letzte Frage noch:

In welcher Basis soll der komprimierte String sein? Wenn man nur die Länge vergleicht wäre ja die Kodierung (z.B. B216 oder B64, etc.) sehr ausschlaggebend trotz gleichem Inhalt.

Ich würde bei sowas volle Bytes zählen (wobei es egal ist in welcher Form diese Vorliegen... Als HexString, ArrayOfBytes, etc. etc).