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...
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.
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 ?
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?
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.
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
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
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:> 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.
>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?
:-)
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.
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.
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 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.
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...
Marc V. schrieb:> Bitte dasselbe furLothar 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.
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.
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.
