Hallo, ich habe 10 Zahlen von 0-999. Diese möchte ich gerne komprimieren. Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. Das ganze vielleicht noch mit Hex Zeichen, dann sollte das etwas leichter sein. Das Ergebnis sollte 10 Stellen haben und immer gleiche länge. Daraus soll man dann verlustfrei auf die 10 Ausgangszahlen wieder erhalten können. Ich habe jetzt schon etwas gegoogelt, aber einen vernünftigen Ansatz bisher nicht nicht gefunden. Hätte jemand eine gute Idee wie man an die Sache herangehen könnte, bzw. ob das überhaupt so möglich ist?
chis schrieb: > as Ergebnis sollte 10 Stellen haben und immer gleiche länge. Ist doch einfach: Du hast genau eine Stelle für jede deiner Zahlen. D.h. du brauchst ein Alphabet mit 1000 versch. Zeichen. Dass das nicht funktionieren kann, sollte klar sein...
10 Zahlen zu 0-999 sind 1000^10 verschiedene Kombinationen. Sind also 30 Stellen im Dezimalsystem oder ca 25 im Hex System. Man könnte die Symbolanzahl vergrößeren. Mit einem Dreißigersystem kommst auf deine 10 Stellen.
chis schrieb: > Hätte jemand eine gute Idee wie man an die Sache herangehen könnte Du könntest mal beschreiben, was die Ursache der Aufgabe ist. Woher kommen die Zahlen? Warum müssen die "komprimiert" werden und was passiert damit? vielleicht kann man dann einen Tipp geben. > ob das überhaupt so möglich ist? Mit den gegebenen Informationen lautet die Antwort "Nein, im Zehner- oder Hexadezimalsystem nicht möglich!"
Hallo, >>"Nein, im Zehner- >>oder Hexadezimalsystem nicht möglich!" Ich dachte mir mit verschiedenen Rechenoperationen, die man auf die Zahlen anwendet. Könnte man das ganze eindampfen. Wenn man die Operationen wieder rückwärts anwendet kommt man wieder auf die Ursprünglichen Zahlen. Da muss es doch irgendwelche Algorithmen geben?!?
Klar nimm einen einfachen Pseudo-Random Generator Algorithm oder eine Hash-Funktion und berechne entsprechende Rainbow-Table; Wenn Du Glück hast findest Du einen Startwert, der genau Deine Zahlenfolge erzeugt. Kann aber dauern, bis Du eine Lösung findest und kann sein, dass es keine gibt. Und du brauchst Rechenpower und Speicher.
chis schrieb: > Da muss es doch irgendwelche Algorithmen geben?!? nein muss es nicht, Man kann mit 10 Stellen nur eine gewissen Informationsmenge speichern und diese ist kleiner als die Menge die du speichern musst. Wenn man alles immer Komprimieren könnte, müsste man alles auf 1 bit/Byte komprimieren können und dann auch wieder entpacken. Das kann aber schlecht sein. Wenn man mehr über die Zahlen wüsste, (wie sie sie verteilt, dürfen sie umsortiert werden usw.) dann könnte man sich etwas einfallen lassen, was aber nur für genau diesen Zweck funktioniert.
Ich vermute jetzt mal, dass chis Speicherplatz sparen will, denn ein Wert von 999 braucht 10 Bit, das sinnd 2 Byte. Also könnte man 10 x 1 Byte und die 2 Bit extra in weiteren 3 Byte speichern, mit komplizierten Bitoperationen. Die Befehle dazu brauchen mehr Speicher als die oben gesparten 7 Byte. Bei umfangreicheren Daten kann sich das aber lohnen, auch wenn wirklich komprimiert wird.
chis schrieb: > Hallo, > ich habe 10 Zahlen von 0-999. > Diese möchte ich gerne komprimieren. > Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. > Das ganze vielleicht noch mit Hex Zeichen, > dann sollte das etwas leichter sein. > > Das Ergebnis sollte 10 Stellen haben und immer gleiche länge. > Daraus soll man dann verlustfrei auf die 10 Ausgangszahlen wieder > erhalten können. > > Ich habe jetzt schon etwas gegoogelt, aber einen vernünftigen Ansatz > bisher nicht nicht gefunden. > > Hätte jemand eine gute Idee wie man an die Sache herangehen könnte, bzw. > ob das überhaupt so möglich ist? OK, eine (Anzeige)Position muss die Werte 0-999 darstellen können. Das ist geringfügig weniger als 10Bit. Also muss eine (Anzeige)Position 10Bit (10 unabhängige Informationen) darstellen können. Nehmen wir mal eine Sieben-Segment Anzeige und steuern wir sie derart an, das ein Segment AUS | DUNKEL | HELL sein kann. Damit erreichen wir 2188 mögliche Darstellungen (das sind ca. 11,095Bit) Fertich!
chis schrieb: > Da muss es doch irgendwelche Algorithmen geben?!? Warum "muss" es da irgendwelche Algorithmen geben? Denn wenn das gehen "muss", dann "muss" doch auch ein ganzer Film in "ein Zeichen" passen. Und tatsächlich. Das tut er auch, wenn man "1 DVD" als "1 Zeichen" ansieht. Letztlich ist der gesamte Konsens hier im Thread, dass der Werteraum der von dir zur Verfügung gestellten "Zeichen" (bestenfalls Hexadezimal mit 16 Werten pro Stelle) für die gestellte Aufgabe zu klein ist. Du könntest aber einfach mal meine Fragen beantworten, vielleicht findet sich ein anderer Weg...
Alex S. schrieb: > Ich werfe mal das Chinesische Restklassen-System in die Runde. Ein paar Glückskekse wären besser gewesen.
chis schrieb: > ich habe 10 Zahlen von 0-999. > Diese möchte ich gerne komprimieren. > Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. Wie man es auch dreht und wendet, das ergibt max. 8 Zahlen. Und nein, man kann 10 Zeichen ganz einfach nicht komprimieren, also brauchst du mindestens 100 bit. Und das wars dann.
Marc V. schrieb: > Und nein, man kann 10 Zeichen ganz einfach nicht komprimieren, > also brauchst du mindestens 100 bit. klar kann man das, nur kann man es nicht in jedem Fall. Man kann es also nicht garantieren. "4x112;6x42" und schon habe ich 112,112,112,112,42,42,42,42,42,42 komprimiert.
10 Bit = 0..1023 10 x 10 Bit = 100 Bit = 12.5 Byte => 13 Character Es ist also mit 13 Character einfach realisierbar, aber nicht mit 10
Peter II schrieb: > klar kann man das, nur kann man es nicht in jedem Fall. Man kann es also > nicht garantieren. Ja, sicher. 10 Zahlen die alle einen Wert von 0 haben, kann ich sogar mit 1 bit darstellen. EDIT: Peter II schrieb: > und schon habe ich 112,112,112,112,42,42,42,42,42,42 komprimiert. Und wie ?
:
Bearbeitet durch User
Das Stichwort lautet "Entropie". Das ist in diesem Fall die Menge an elementarer Unordnung in einer Datenmenge. Bei englischen Texten ist es knapp über ein Bit pro Buchstabe. Nachdem wir zu den Zahlen vom TO keine Infos haben müssen wir annehmen, dass sie 100% zufällig sind und damit per-se nicht verlustfrei komprimierbar. Bilddaten von Kameras und dgl. enthalten btw. auch eine sehr hohe Entropy (Rauschen und unruhige Motive). Dass die trotzdem so gut komprimierbar sind liegt daran, dass der Mensch der sich das Bild anguckt ziemlich dumm ist und man viele Details weglassen kann, also verlustbehaftet komprimiern.
Die ist schon bekannt dass die gängigen verlustfreien Komprimierprogramme seit gefühlt 30 Jahren im Durchschnitt "nur" ca 50% Platzersparniss bringen? Die Betonung liegt bei "Durchschnitt", denn es kommt auf die konkreten Daten an. Du kannst zum Beispiel 50.000 mal die Zahl 900 in 4 Bytes komprimieren. Aber 50.000 zufällige Zahlenwerte kannst du gar nicht komprimieren. Das Ergebnis hat also eine variable Größe. Deine hohe Kompressionsrate erreicht man nur, wenn man Informationsverlust toleriert, so wie du das von Fotos im JPG Format oder Musik im MP3 Format gewohnt bist.
Peter schrieb: > Es ist also mit 13 Character einfach realisierbar, aber nicht mit 10 Aber nicht mit 10 Hex-Zahlen. Und schon gar nicht mit 10 Ziffern von 0..9. Wobei ich hier doch sehr ins Grüblen komme, ob chis da mit den Zahlensystemen was durcheinender gebracht hat... chis schrieb: > Das Ergebnis sollte 10 Stellen haben Also verkürzen wir die Frage: was ist 1 "Stelle"? Ist das der Wertebereich 0..9? Oder ist das ein Hex-Zeichen? Oder ist das 1 Char? Oder 1 Short? Oder 1 Long?
:
Bearbeitet durch Moderator
Peter II schrieb: > "4x112;6x42" > > und schon habe ich 112,112,112,112,42,42,42,42,42,42 komprimiert. Edit ging nicht mehr, also: Du hast zehn Zeichen in 10 Zahlen "komprimiert". Alle Achtung. Und der praktische Zweck davon ist ?
>> und schon habe ich 112,112,112,112,42,42,42,42,42,42 komprimiert. > Und wie ? Indem du folgende Information abspeicherst: Paket 1 = 4 mal Wert 112 Paket 2 = 6 mal Wert 42 Ergibt die Datenfolge: 4 122 6 42 also 4 Bytes. Es gibt natürlich auch komplexere Algorithmen. Aber dieses Prinzip wird bei Faxgeräten und GIF Dateien angewendet und hat sich bis heute bewährt. Wenn Du mein Beispiel mit zufällig verteilten Daten wiederholst, wirst du den Schwachpunkt dieses primitiven Algorithmus erkennen. Im schlimmsten Fall verdoppelt er nämlich das Datenvolumen.
Marc V. schrieb: > Und der praktische Zweck davon ist ? https://de.wikipedia.org/wiki/Laufl%C3%A4ngenkodierung
Stefan U. schrieb: > Ergibt die Datenfolge: 4 122 6 42 > also 4 Bytes. Passt: "4 122 6 42" sind genau die 10 geforderten "Stellen"...
chis schrieb: > Da muss es doch irgendwelche Algorithmen geben?!? Nein, muss es nicht. Im Übrigen: Was hat das Thema mit "Mikrocontroller und Digitale Elektronik" zu tun? Das ist ja nun eher Mathematik, bzw. Informationstheorie. https://de.wikipedia.org/wiki/Informationstheorie
Stefan U. schrieb: > Indem du folgende Information abspeicherst: > > Paket 1 = 4 mal Wert 112 > Paket 2 = 6 mal Wert 42 > > Ergibt die Datenfolge: 4 122 6 42 > also 4 Bytes. Paket 1 = 123 Paket 2 = 456 // Oops Paket 3 = 789 // Und wieder Oops Paket 4 = 221 Paket 5 = 446 Paket 6 = 476 Paket 7 = 556 Paket 8 = 656 Paket 9 = 756 Paket 10 = 999 Ergibt die Datenfolge: 1 123 1 456 ... 1 999 also 100 bit + 80 bit = 180 bit. Ausgezeichnet.
:
Bearbeitet durch User
Eine vernünftige Kompression ist nur dann sinnvoll, wenn es Schwerpunkte (Häufungen) gibt. Sind die Zahlen aber halbwegs, gleichmäßig verteilt, so bringt das nichts. Manchmal, aber nur Manchmal, unterliegen die Zahlen bestimmten Trends. Dann kann die Überlegung nur die Differenz zu speichern reizvoll sein.
Moin, Diese Beispiele laufen alle Richtung Huffman. Da kann man zwar durchaus was einsparen, aber nur, wenn man die Wahrscheinlichkeiten mit denen die Zahlen 0..999 auftauchen kennt, und wenn diese Wahrscheinlichkeiten stark unterschiedlich sind. Aber dann ist keine konstante Laenge der komprimierten Daten garantiert. Nur eine durchschnittliche Laenge (wenn eben die Wahrscheinlichkeiten passen). Gruss WK
Amateur schrieb: > Manchmal, aber nur Manchmal, unterliegen die Zahlen bestimmten Trends. > Dann kann die Überlegung nur die Differenz zu speichern reizvoll sein. Dann braucht man sogar 11 bits. Zahl 1 = 999 Zahl 2 = 123 Differenz = 876 10 bit Zahl 2 = 123 Zahl 3 = 999 Differenz = -876 11 bit
:
Bearbeitet durch User
Ich vergaß: Gibt es eindeutige, sich wiederholende Häufungen, so könnte der Herr Huffman Linderung bringen. Wohl gemerkt: Wenn diese Häufungen nicht vorhanden sind, blähst Du, mit solchen Kompressionsalgorithmen, nur den Datenstrom auf.
Marc V. schrieb: > Amateur schrieb: >> Manchmal, aber nur Manchmal, unterliegen die Zahlen bestimmten Trends. >> Dann kann die Überlegung nur die Differenz zu speichern reizvoll sein. > > Dann braucht man sogar 11 bits. du sucht immer den schlimmsten fall raus - ja dabei wird das Ergebnis sogar größer. Es gibt aber sehr oft den Fall wo die Differenzen kleiner sind, dann kommt man mit weniger Bits aus.
micha schrieb: > Klar nimm einen einfachen Pseudo-Random Generator Algorithm oder eine > Hash-Funktion und berechne entsprechende Rainbow-Table; Wenn Du Glück > hast findest Du einen Startwert, der genau Deine Zahlenfolge erzeugt. > Kann aber dauern, bis Du eine Lösung findest und kann sein, dass es > keine gibt. Und du brauchst Rechenpower und Speicher. Einen ähnlichen Gedanken hatte ich auch schon: V1) Der Encoder sucht eine passende Sequenz in Pi oder e und gibt einen Pointer an der Decoder. Wird in der Praxis nicht für lange Sequenzen funktionieren. V2) Reihenentwicklung, etc.: Der Encoder erzeugt Parameter einer gebrochen rationalen Funktion. Beide Decoder verlangen allerdings etwas Rechnerei und Speicher. Bleibt also wieder die Frage nach der Anwendung.
Marcus H. schrieb: > Beide Decoder verlangen allerdings etwas Rechnerei und Speicher. Bleibt > also wieder die Frage nach der Anwendung. und bei beiden ist nicht garantiert das es dann auch in 10 Zeichen passt.
Noch eine Möglichkeit: Die Zahlen 0 ... 999 benötigen 10 Bit. Computi kann aber nur 8/16/24 oder 32 Bit. Wenn Du die Zahlen "zusammenschiebst", um die ungenutzten 6 Bit zu verwenden, so kannst Du Deine 10 Zahlen in 100 Bit oder 12 Bytes verpacken, statt 160 bzw. 16 Bytes zu verwenden. Die Schiebebefehle und die booleschen Maskierungen werden dann Dein Freund werden. Nett ist auch, dass das Ganze verlustlos geschieht.
Amateur schrieb: > Nett ist auch, dass das Ganze verlustlos geschieht. aber immer noch dumm, das ist mehr als 10byte sind die gebraucht werden.
Amateur schrieb: > Wenn Du die Zahlen "zusammenschiebst", um die ungenutzten 6 Bit zu > verwenden, so kannst Du Deine 10 Zahlen in 100 Bit oder 12 Bytes > verpacken, statt 160 bzw. 16 Bytes zu verwenden. > Die Schiebebefehle und die booleschen Maskierungen werden dann Dein > Freund werden. > Nett ist auch, dass das Ganze verlustlos geschieht. Das ist dann eben ein Trade-off: Man spart Hauptspeicher, aber dafür braucht man mehr Rechenzeit. Und mehr Speicher für den Code. Wenn der Themenersteller man sinnvolle Informationen über seinen Anwendungsfall herausrücken würde...
Hans M. schrieb: > Dann sortiert man vor dem abziehen sie von Groß nach klein ;-) Und wo speicherst du die Originalpositionen? Auch die sind Teil des Gesamt-Informationsgehalts oder willst du uns erzählen 10000 = 00001?
Peter II schrieb: > das ist mehr als 10byte sind die gebraucht werden. Das mit den 10 Byte kann ich da nicht direkt rauslesen: chis schrieb: > Das Ergebnis sollte 10 Stellen haben und immer gleiche länge. Er meint wohl eine 10-stellige Zahl. Ob die im Binärsystem, als 10 ASCII-Zeichen oder als BCD dargestellt werden soll, entzieht sich unserer Kenntnis. Ich bezweifle auch, dass der TO diese Frage überhaupt beantworten kann. Nach der Wortwahl des Ausgangspostings zu urteilen, steckt der TO da überhaupt gar nicht in der Materie, wie Zahlen dargestellt werden können.
:
Bearbeitet durch Moderator
>Das ist dann eben ein Trade-off: Man spart Hauptspeicher, aber dafür >braucht man mehr Rechenzeit. Und mehr Speicher für den Code. @Mark Die Syntax für den Zauberalgorithmus ist mir leider entfallen. Aus diesem Grunde brauchen alle Verfahren, sogar die 1:1 Übertragung/Speicherung Code;-) So ein Mist aber auch! Aber vielleicht hast Du ja sogar etwas konstruktives auf der Pfanne?
chis schrieb: > Hallo, > ich habe 10 Zahlen von 0-999. > Diese möchte ich gerne komprimieren. Warum? Zu welchem Zweck? > Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. Aus welchem Zeichensatz? Oder ist das freigestellt? Dann müsste man sich einen Zeichensatz ausdenken, der 1000 Symbole umfasst. > Das ganze vielleicht noch mit Hex Zeichen, > dann sollte das etwas leichter sein. Dann geht es nur für einen Teil der möglichen Kombinationen. Aber was sollte in welcher Hinsicht leichter sein? > Das Ergebnis sollte 10 Stellen haben und immer gleiche länge. > Daraus soll man dann verlustfrei auf die 10 Ausgangszahlen wieder > erhalten können. Dann müsste man sich einen neuen Zeichensatz, wie oben erwähnt, ausdenken. > Ich habe jetzt schon etwas gegoogelt, aber einen vernünftigen Ansatz > bisher nicht nicht gefunden. Wonach genau hast Du gesucht? > Hätte jemand eine gute Idee wie man an die Sache herangehen könnte, bzw. > ob das überhaupt so möglich ist? Welchen theoretischen Hintergrund hast Du? Deine Fragestellung deutet darauf hin, dass Du lediglich einmal gehört hast, das man Daten komprimieren kann. Eventuell hast Du schon Programme wie ZIP, Huffmann, Run-Length-Coding oder Liv-Zempel oder ähnliches verwendet, weisst aber nicht warum und in welchen Grenzen sie funktionieren. Ist das so? Wenn man mal alle unbekannten Fakten durch plausible Annahmen ersetzt, dann ist es nicht möglich, alle möglichen Folgen von 10 Zahlen, jeweils 0-999 durch eine kürzere Folge so zu ersetzen, dass die originale Zahlenfolge wieder reproduzierbar ist. Das folgt aus ganz einfachen Überlegungen: Angenommen, es gäbe so ein Verfahren, dann wäre die entstehende Folge kürzer als die Ausgangsfolge. Daraus folgt, dass es auch weniger mögliche Darstellungen verschiedener Zahlenfolgen gäbe als mit der ursprünglichen Darstellung. Nun soll aber jede der erzeugten Zahlenfolgen eindeutig einer einzigen der Ausgangszahlenfolgen zugeordnet werden können. Sagen wir, Du hast 1000^10 verschiedene Zahlen. Du hättest ein Verfahren, dass jede mögliche Kombination einer kürzeren Zahl zuordnet. Angenommen, diese neue, kürzere Darstellung könnte nur 16^10 (das ist eindeutig wesentlich weniger als 1000^10) verschiedene Zahlen darstellen (also etwa 10-stellige Hexzahlen). Dann blieben 1000^10 - 16^10 Zahlen die keiner neuen Zahl zugeordnet werden könnten. Denn die Rechenvorschrift könnte ja nur EINER Zahl der Ausgangsmenge jeweils EINE Zahl der Zielmenge zuordnen. Wenn ich nun alle 16^10 der Zielmenge ausgenutzt hätte, was mache ich dann mit der Zahl mit der Nummer 16^10+1 aus der Ausgangsmenge? Ich habe ja keine aus der Zielmenge mehr übrig. Falls Dir das wegen der grossen Zahlen zu unübersichtlich ist, versuche es mit kleineren Zahlen. Nimm an Du hättest, 8 verschiedene Zahlen und würdest versuchen, sie 4 verschiedene Zahlen (durch ein Kompressionsverfahren) zuordnen wollen. Dann könntest Du zwischen jeder der 8 Zahlen der Ausgangsmenge einen Pfeil zu genau einer der 4 Zahlen der Zielmenge zeichnen. Das aber geht nicht, wenn Du es versuchst. Nach der 4. Zahl sind alle Zahlen der Zielmenge besetzt. Klar? Bleibt die Frage, warum es so etwas wie ZIP etc. gibt und wie das funktioniert. Eine einfache Antwort ist zweiteilig: 1. Auch ZIP etc. macht nicht ALLE möglichen Kombinationen kleiner (Du wirst schon festgestellt haben, dass eine gezippte Datei nicht wesentlich kleiner oder sogar größer wird, wenn sie noch einmal gezippt wird) und 2. ZIP und ähnliches nutzen die Tatsache, dass nicht alle möglichen Kombinationen genutzt werden (z.B. in ASCII-Texten) und ausserdem, dass es - je nach Inhalt - gewisse Abhängigkeiten zwischen den Teilen der Gesamtdatei gibt.
chis schrieb: > Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. Wie schon von den Vorrednern dargestellt, benötigt man 100 Bit für die Darstellung der zehn Zahlen. Bei Verwendung von Unicode, d.h. UTF-16 oder UTF-32, statt ASCII oder ISO-8859 könnte man es sich sogar erlauben, zugunsten der Lesbarkeit erhebliche Teile des Zeichensatzes ungenutzt zu lassen. Trotzdem bedarf es schon sehr fortgeschrittener semiotischer Kenntnisse, solch eine Zeichenfolge auf einem Computer als Text einzugeben. Da würde ich selbst für Unicode-Experten durchaus mit vielen Minuten bis Stunden für eine 10-stellige Zeichenfolge ansetzen. > Das ganze vielleicht noch mit Hex Zeichen, > dann sollte das etwas leichter sein. Zahlen in Hexadezimaldarstellung besitzen eine viel zu geringe Informationsdichte, da selbst bei Zugrundelegung unseres lateinischen Buchstaben- und arabischen Ziffernalphabets nur ein Bruchteil der verfügbaren Zeichen ausgenutzt werden kann.
Also mit Huffmann komme ich für die Testdaten (999, 828, 717, 717, 818, 110 22, 1, 288, 788) auf 12 bytes. Da ist aber die Tabelle (die hat 42 bytes) nicht dabei, die braucht man aber um es wieder zu dekodieren. Ohne nähere Angaben kann man da keinen vernünftige Antwort geben, evt. geht es für bestimmte Fälle aber dazu müsste man mehr wissen. Also Fakten auf den Tisch oder Thread dicht machen.
Ich vergass: Die Code-Tabelle kann man nochmal eindampfen die war nur der Übersichtlichkeit halber ASCII. Bei solchen kleinen Datenmengen lohnt sich der Aufwand nicht, der Code + die Verwaltungsdaten sind anschliessend grösser als der erzeugte Code. Da bleibt höchstens die Idee von oben per Hash, Pi-Sequenz,.... Tauchen nur bestimmte Werte im Intervall auf und man kann andere Werte sicher ausschliessen geht noch was, es kommt halt sehr darauf an was er überhaupt vor hat aber da er den Mund nicht aufbekommt ...
@Chis solltest Du noch unter den Lebenden weilen, so wäre es nicht schlecht, wenn Du Dich mal wieder "einmischen" tätest. Irgendwie ist immer noch nicht klar, ob es sich um binäre-, BCD- oder ASCII-Zahlen handelt. Oder hast Du nur einen Schneeball vom Berg gerollt und schaust erst in der nächsten Woche mal nach, ob in der Ortschaft, am Fuße des Berges, ein paar Grundstücke günstig zu haben sind?
Amateur schrieb: > Oder hast Du nur einen Schneeball vom Berg gerollt und schaust erst in > der nächsten Woche mal nach, ob in der Ortschaft, am Fuße des Berges, > ein paar Grundstücke günstig zu haben sind? :-)
Zahlen der Größe nach sortieren, die erste Zahl speichern und dann nur noch die Differenzen.
Kurt schrieb: > Zahlen der Größe nach sortieren, die erste Zahl speichern und dann nur > noch die Differenzen. lol Ich muss grad eine WAV-Datei komprimieren. Dazu sortiere ich jetzt alle Bytes in aufsteigender Reihenfolge, damit die RLE maximal-effizient wird.
Versucht ihr immer noch den Nobelpreis zu kriegen ? Marc V. schrieb: > chis schrieb: >> ich habe 10 Zahlen von 0-999. >> Diese möchte ich gerne komprimieren. >> Mein Wunsch wäre gerne eine 10 stellige Zeichenfolge. > > Wie man es auch dreht und wendet, das ergibt max. 8 Zahlen. > > Und nein, man kann 10 Zeichen ganz einfach nicht komprimieren, > also brauchst du mindestens 100 bit. > > Und das wars dann.
Marc V. schrieb: > Versucht ihr immer noch den Nobelpreis zu kriegen ? Aber nein. Es reicht schon, wenn wir besser sind als Claude Shannon. ;-)
Hallo, Amateur schrieb: > Oder hast Du nur einen Schneeball vom Berg gerollt und schaust erst in > der nächsten Woche mal nach, ob in der Ortschaft, am Fuße des Berges, > ein paar Grundstücke günstig zu haben sind? Nein, ich habe aber auch noch genug andere Dinge zu tun. Und außerdem scheint hier jeder zweite nur seinen Senf dazugeben zu müssen. Wenn ich hier fragen würde: Wann darf man in Deutschland über eine Ampel gehen, dann ist die erste Antwort die kommt: Wo steht denn die Ampel??? Ich fasse mal zusammen, was jetzt rausgekommen ist in den letzten ~50 Beiträgen: Man kann eine Zahl komprimieren, solange gleiche Zeichen darin sind, das ist aber nicht immer gegeben, also kann ich nicht immer sicher auf eine vorgegebene Zeichenlänge kommen. Damit ist die Diskussion jetzt wohl beendet. Wenn ihr jetzt weiter Seft dazugeben wollt nur zu ist mir jetzt egal.
chis schrieb: > Nein, ich habe aber auch noch genug andere Dinge zu tun. Du fängst eine Sitzung (Thread) an und gehst dann als Sitzungsleiter (TO) zum Rasenmähen? Und wunderst dich hinterher, dass die Sitzungsteilnehmer (User) irgendwelche Fragen stellen und mangels Antworten nicht genau das diskutieren, was du willst? > dann ist die erste Antwort die kommt: > Wo steht denn die Ampel??? Richtig, das sollte man beachten. > Ich fasse mal zusammen, was jetzt rausgekommen ist > in den letzten ~50 Beiträgen: > Man kann eine Zahl komprimieren, solange gleiche Zeichen darin sind, > das ist aber nicht immer gegeben, also kann ich nicht immer > sicher auf eine vorgegebene Zeichenlänge kommen. Du solltest die ~50 Beiträge nochmal lesen. Da steht viel, viel mehr drin. Sogar ich habe daraus noch was gelernt. Und noch immer ist unklar, was denn jetzt "1 Stelle" ist. > ist mir jetzt egal. Und schon wieder nichts gelernt. Ein weiteres Fazit hättest du zumindest ziehen müssen: Nachholbedarf beim Thema "Zahlensysteme"...
> Ich fasse mal zusammen, was jetzt rausgekommen ist
Das ist völlig falsch.
Richtig ist, dass du zu deinen Zahlenfolgen zu wenig Eigenschaften
genannt hast, um einen geeigneten Kompressionsalgorithmus zu wählen bzw
zu entscheiden, ob die Aufgabe lösbar ist.
Welche Eigenschaften haben die Zahlen? Wie stehen sie zueinander in
Beziehung? Auf welchen Informationsgehalt kann man notfalls verzichten?
Was verstehst du unter einer "Stelle"?
Das sind die Kernfragen, die wiederholt gestellt wurden und Antwort
bedürfen.
@chis Wenn man in diesem Forum nicht alle Informationen die zur Behandlung der Fragestellung notwendig sind preisgibt, entwickelt sich hier schnell eine ebenso unproduktive Eigendynamik. Welche Informationen benötigt werden ist leider nicht immer offensichtlich.
Oh, sorry hab Stefans letzten Beitrag übersehen. Aber der fragt ja konkret nach und macht damit meinen letzten Satz überflüssig.
chis schrieb: > Wenn ich hier fragen würde: > Wann darf man in Deutschland über eine Ampel gehen, > dann ist die erste Antwort die kommt: > Wo steht denn die Ampel??? Nö, zuerst meckern dass man besser an der Ampel entlang geht statt drüber.
chis schrieb: > Ich fasse mal zusammen, was jetzt rausgekommen ist > in den letzten ~50 Beiträgen: Beitrag "Re: Zahlen komprimieren" Sapienti sat
chis schrieb: > ich habe 10 Zahlen von 0-999. > Diese möchte ich gerne komprimieren. Wegen der beschränkten Stellenzahl von Taschenrechnern vereinfache ich das mal oBdA (ohne Beschränkung der Allgemeinheit) auf 4 Zahlen. Ich nehme mal als Beispiel 4 Zahlen 0..999, die auf 4 Ziffern komprimiert werden sollen: 274 877 906 936 Die Ziffern schreibe ich einfach hintereinander (nötigenfalls mit führenden Nullen), ergibt eine 12 stellige Zahl 274877906936 Das ist 2^38-8, ich gebe also weiter "38-8" - Voila, 4 Zeichen. Georg
Georg schrieb: > Das ist 2^38-8, ich gebe also weiter "38-8" - Voila, 4 Zeichen. Bitte dasselbe fur 274,877,906,928
Georg schrieb: > Das ist 2^38-8, ich gebe also weiter "38-8" - Voila, 4 Zeichen. Zeig das doch mal mit 274 677 906 936 Ich komme da auf 38-2000000008 oder 37+137238953464 Und jede der "Lösungen" ist länger als 274677906936 Und da möchte ich mal sehen, wie das wieder bei einer 100stelligen Binärzahl (die für die angelegentliche Aufgabe ja nötig ist) wieder auseinandergeklaubt wird. Das sind dann immerhin mehr als 3 longs hintereinander...
:
Bearbeitet durch Moderator
Marc V. schrieb: > Bitte dasselbe fur Lothar M. schrieb: > Zeig das doch mal mit 274 677 906 936 Genau das wollte ich ja zeigen: es funktioniert nur für ganz bestimmte Zahlen (übrigens für ziemlich wenige). Aber wo ihr recht habt: da dem TO wohl jedes mathematische Verständnis abgeht, wird er meinen Post womöglich noch als Bestätigung nehmen: chis schrieb: > Da muss es doch irgendwelche Algorithmen geben?!? Eine Frage am Rande: gehören Mathematiker und Nicht-Mathematiker tatsächlich beide zur Art Homo Sapiens? Sind das verschiedene Unterarten? Georg
Georg schrieb: > gehören Mathematiker und Nicht-Mathematiker tatsächlich beide zur Art > Homo Sapiens? "Anyone who cannot cope with mathematics is not fully human. At best he is a tolerable subhuman who has learned to wear shoes, bathe, and not make messes in the house." (Robert Heinlein)
Könnte man nicht bei 10xZiffern bis 999 auf die Gesamte breite ein Steuerbyte anhängen und zum Beispiel die Bits so schieben das jedes 5. Bit ein Wiederholungsbit darstellt. Wenn das 5Bit null ist werden die nächsten 4normal eingelesen, sonst vom vorherigen kopiert. Somit würde aus 1Byte 0000|0000|2222|2222 0000|1|2222|1| werden. Hab irgendwann mal ein Bild so komprimiert, allerdings hab ich eine Farbe gelöscht und als Steuerbyte gesetzt... ich denke so köntne man aber vielleicht schon ansetzen.
@chis Für meinen Einwand: >Oder hast Du nur einen Schneeball vom Berg gerollt und schaust erst in >der nächsten Woche mal nach, ob in der Ortschaft, am Fuße des Berges, >ein paar Grundstücke günstig zu haben sind? möchte ich mich hier in aller Form entschuldigen. Statt in der nächsten Woche hätte ich besser am nächsten Tag geschrieben. Tut mir aufrichtig Leid!
Toto mit Harry schrieb: > Wenn das 5Bit null ist werden die nächsten 4normal eingelesen, sonst vom > vorherigen kopiert. > > Somit würde aus 1Byte 0000|0000|2222|2222 0000|1|2222|1| werden. Etwas ähnliches nennt sich bit stuffing und nein, da könnte man nicht ansetzen. Wie willst du ein normales von einem Stuffbit unterscheiden ? EDIT: Toto mit Harry schrieb: > Könnte man nicht bei 10xZiffern bis 999 Es geht um 10 Zahlen, nicht Ziffern.
:
Bearbeitet durch User
Amateur schrieb: > Statt in der nächsten Woche hätte ich besser am nächsten Tag > geschrieben. Warum ? Der TO ist weg, aber die Frage bleibt, mit oder ohne deinen Senf.
Lothar M. schrieb: > chis schrieb: >> Nein, ich habe aber auch noch genug andere Dinge zu tun. > Du fängst eine Sitzung (Thread) an und gehst dann als Sitzungsleiter > (TO) zum Rasenmähen? Da hier die Komprimier-Experten präsent sind, hätte ich auch eine Frage: Wie kann ich meinen Rasenschnitt verdichten, dass er in einen einzigen Auffangkorb passt? Überlegt Euch was, ich muss jetzt in eine Sitzung.
Richard H. schrieb: > Wie kann ich meinen Rasenschnitt verdichten, dass er in einen einzigen > Auffangkorb passt? einfach einen Verbrenner im Auffangkorb verbauen.
Richard H. schrieb: > Wie kann ich meinen Rasenschnitt verdichten, dass er in einen einzigen > Auffangkorb passt? Ausblasrohr bis zum Nachbar verlängern ?
Richard H. schrieb: > Da hier die Komprimier-Experten präsent sind, hätte ich auch eine Frage: > Wie kann ich meinen Rasenschnitt verdichten, dass er in einen einzigen > Auffangkorb passt? > Überlegt Euch was, ich muss jetzt in eine Sitzung. Ich präzisiere: Wie kann ich meinen Rasenschnitt verlustfrei verdichten, dass er in einen einzigen Auffangkorb passt? :)
Frank M. schrieb: > Ich präzisiere: > > Wie kann ich meinen Rasenschnitt verlustfrei verdichten, dass er in > einen einzigen Auffangkorb passt? Ganz "einfach" den Raum zwischen Atomkern und Elektronenschalen des Rasenschnitts entfernen! :-P
Frank M. schrieb: > Wie kann ich meinen Rasenschnitt verlustfrei verdichten, dass er in > einen einzigen Auffangkorb passt? Rasen pflastern. Das bisschen Unkraut, das dann noch zwischen den Fugen wächst, passt locker rein.
Hans M. schrieb: > Ganz "einfach" den Raum zwischen Atomkern und Elektronenschalen des > Rasenschnitts entfernen! Genau: einfach die "Luft" dazwischen rauspumpen :)
Frank M. schrieb: > Ich präzisiere: > > Wie kann ich meinen Rasenschnitt verlustfrei verdichten, dass er in > einen einzigen Auffangkorb passt? Verlustfrei ist echt nicht nötig, ich will ihn nicht wieder herstellen.
Richard H. schrieb: > Verlustfrei ist echt nicht nötig, Das passt aber nicht zum Ausgangsbeitrag: chis schrieb: > Daraus soll man dann verlustfrei auf die 10 Ausgangszahlen wieder > erhalten können. Du bist also somit offtopic.
Marc V. schrieb: > Ausblasrohr bis zum Nachbar verlängern ? In eine ähnliche Richtung hatte ich auch schon gedacht, nämlich das Zeug in der Cloud ablegen. Kam aber alles wieder runter geregnet.
Richard H. schrieb: > In eine ähnliche Richtung hatte ich auch schon gedacht, nämlich das Zeug > in der Cloud ablegen. Kam aber alles wieder runter geregnet. Menge die durch den Firewall zurückkommt auf <= Auffangkorb begrenzen ?
Marc V. schrieb: > Der TO ist weg, aber die Frage bleibt, mit oder ohne deinen Senf. Die Frage ist Unsinn. Das hat der TO erkannt. Sie weiter im Raum stehen zu lassen und zu diskutieren ist einigermaßen sinnlos. Frank M. schrieb: > Hans M. schrieb: >> Ganz "einfach" den Raum zwischen Atomkern und Elektronenschalen des >> Rasenschnitts entfernen! > > Genau: einfach die "Luft" dazwischen rauspumpen :) Das Vakuum raussaugen, bis keins mehr drin ist.
Peter II schrieb: > einfach einen Verbrenner im Auffangkorb verbauen. Frischer Rasen brennt schlecht.
Im Prinzip will der To doch nur 300bit komprimieren.. Mit fester Endgrösse wird das nicht gehen..Aber man kann es grundsätzlich versuchen.. Es kann dann etwas mehr oder viel weniger werden.
Rolf Magnus schrieb: > Die Frage ist Unsinn. Das hat der TO erkannt. Sie weiter im Raum stehen > zu lassen und zu diskutieren ist einigermaßen sinnlos. Die meisten haben es auch erkannt, es geht aber ohne Beleidigungen und Beschimpfungen weiter - vielleicht kommt noch etwas nützliches dabei heraus - für Gärtner oder so...
Na toll - Jetzt haben die Nachbarn mit jeder Menge Erde einen Denial-of-Grass angriff gestartet. Und mit lrzip bekomm ich den ganzen Dreck nicht wegkomprimiert - Da ist wohl die Entropie zu hoch. Ich will wieder an meinen Rasen! Jetzt versuch ich andere zu überzeugen, um einen DDoG durchzuführen.
1 | Lukas@31.Gartenstraße.Filderstadt.de:~$ hping3 -S --flood --data 30t --file $HOME/Schlamm 32.Gartenstraße.Filderstadt.de |
2 | HPING 32.Gartenstraße.Filderstadt.de (Zaun0 192.168.4.41): S set, 40 headers + 30000 kilo data |
3 | hping in flood mode, no replies will be shown |
4 | |
5 | Broadcast message from Gott@Erde (pts/3) (Wed Jun 22 19:02:17 2016): |
6 | |
7 | m( |
8 | |
9 | Segmentation fault |
10 | Lukas@31.Gartenstraße.Filderstadt.de:~$ |
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.