Beispiel
Code: Alles auswählen
Original$ = "Fischers Fritz fischt frische Fische"
Komprimiert$ = Komprimieren(Original$) ; ergibt z.B: "sk3E4Rdnr"
Dekomprimiert$ = Dekomprimieren(Komprimiert$) ; ergibt wieder "Fischers Fritz fischt frische Fische"
Textstring in Textstring komprimieren
Textstring in Textstring komprimieren
Ich suche eine schnelle Möglichkeit, einen Textstring in einen Textstring zu komprimieren (weniger Zeichen als vorher) und wieder zu dekomprimieren.
Beispiel
Die einzelnen Zeichen in Komprimiert$ müssen sich im ASCII-Raum ab Chr(32) bewegen, damit sie auch darstellbar sind und als String gespeichert werden können.
Beispiel
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
[edit]
ok, ersthaft:
welche Zeichen sollen denn im ursprungssatz erlaubt sein?
nur Großbuchstaben+Space? nur Buchstaben+Space?
[edit2]
ist das für dein esperanto-projekt?
Zuletzt geändert von Kaeru Gaman am 23.07.2006 09:13, insgesamt 1-mal geändert.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Ich glaub mal nicht das daß so einfach ist du brauchst ja ein algo wo gespeichert ist z.b. Wie oft die einzelnen buchstben vorkommen und wo sie stehen - auf jedenfall wird da so ein kurzer kompriemierter string wie du ihn haben willst nicht bei rauskommen. 
Purebasic 5.0 32bit und 64 bit
I'm back from hell
I'm back from hell
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
@Eckhard
um es mal zu umschreiben.
mal angenommen, du kommst mit einem satz buchstaben aus, brauchst also 26 zeichen.
dann nehmen wir der einfachheit halber 32, und codieren ein zeichen mit 5 bit.
nach den 5bit fang ich gleich mit dem nächsten zeichen an, und achte nicht auf die byte-grenze.
im ergebnis bekomme ich 8 zeichen in 5 byte.
leider sind die jedoch NICHT im > 32 bereich.
irgendwelche für bilder geeignete kompressionen kann man hier vergessen.
die bauen hauptsächlich darauf, dass bilder redundant sind, also, viele gleichfarbige flächen besitzen.
ich schätze mal, das soll für dein esperanto-projekt sein.
ich würde vorschlagen, das ganze etwas anders anzugehen.
1. die daten nicht in data-zeilen zu übergeben, sondern in einer datei, notfalls codiert.
2. sie im programm in 2 korrespondierenden Arrays abzulegen.
dann könnte man in beiden schnell suchen, also von beiden sprachen her kommen.
um es mal zu umschreiben.
mal angenommen, du kommst mit einem satz buchstaben aus, brauchst also 26 zeichen.
dann nehmen wir der einfachheit halber 32, und codieren ein zeichen mit 5 bit.
nach den 5bit fang ich gleich mit dem nächsten zeichen an, und achte nicht auf die byte-grenze.
im ergebnis bekomme ich 8 zeichen in 5 byte.
leider sind die jedoch NICHT im > 32 bereich.
irgendwelche für bilder geeignete kompressionen kann man hier vergessen.
die bauen hauptsächlich darauf, dass bilder redundant sind, also, viele gleichfarbige flächen besitzen.
ich schätze mal, das soll für dein esperanto-projekt sein.
ich würde vorschlagen, das ganze etwas anders anzugehen.
1. die daten nicht in data-zeilen zu übergeben, sondern in einer datei, notfalls codiert.
2. sie im programm in 2 korrespondierenden Arrays abzulegen.
dann könnte man in beiden schnell suchen, also von beiden sprachen her kommen.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
Re: Textstring in Textstring komprimieren
dafür gibt's die PB-Befehle PackMemory() und UnPackMemory(). DasEckhard.S hat geschrieben:Ich suche eine schnelle Möglichkeit, einen Textstring in einen Textstring zu komprimieren (weniger Zeichen als vorher) und wieder zu dekomprimieren.
Komprimieren lohnt sich allerdings nur bei entsprechend langen Strings.
Den komprimierten String kann man mit dem Base64Encoder() soEckhard.S hat geschrieben:Die einzelnen Zeichen in Komprimiert$ müssen sich im ASCII-Raum ab Chr(32) bewegen, damit sie auch darstellbar sind und als String gespeichert werden können.
umwandeln, dass dieser nur Zeichen von Chr(32) bis Chr(127) enthält. Da
der encodierte String i.d.R. um die 33% grösser wird, würde allerdings Deine
Einsparung der Komprimierung wieder flöten gehen
Grüße ... Kiffi
a²+b²=mc²
Hallo Kaeru Gaman (und alle anderen Beteiligten)!
Auch am Sonntag schon so früh fit?
Hallo Nachbar, Korbach liegt ja nicht weit von Meschede, wo ich wohne
Ja die Kompression sollte für den Übersetzer sein. Aber deine Überlegungen stimmen, da kann man nicht viel
komprimieren. Vielleicht sollte ich das Ganze doch von einer anderen Seite her anpacken. Ich gebe dir als Experten einmal
ein paar mehr Infos für weitere Überlegungen:
Die Daten sehen ja so aus:
abadono abadon
abako rechenbrett
babao rosinenkuchen
...
zumzumo gesumm
sollen aber später erweiter werden z.B. mit Wortangaben, Mehrzahl, Vergangenheitsformen bei Verben usw. :
abako rechenbrett substantiv rechenbretter
babao rosinenkuchen substaniv rosinenkuchen ...
trinki trinken verb trank getrunken
Die txt-Datei hat momentan 60000 Einträge und ist (mit bisher zwei Spalten) 1500 kB groß. Die Überlegung mit dem
Komprimieren kam daher, dass die Datei gezippt nur 500 kB groß ist.
Kiffi hat den Vorschlag mit PackMemory() und UnPackMemory() gemacht. Muss ich mir noch ansehen.
Ich glaube, es ist besser die ganze Zeile in ein Feld zu ziehen und nur ein Array zu verwenden
Die Überlegung: Muss/Kann ich wirklich alle 60000 Zeilen in ein Array ziehen (Größe des Arbeitsspreicher?, Geschwindigkeit?) oder ist es nicht sinnvoll erst dann nur einzulesen, wenn das Wort gebraucht wird.
Wenn man also den Satz:
Mi trinkas kafon hodiau (Ich trinke heute Kaffee)
übersetzen will, würde man nur alle Wörter mit M einlesen bis zum Wort "Mi", dann mit T, dann mit K und dann mit H
durchsehen. Da kafon mit K und dann A beginnt, würde dieses Wort unter K beim Einlesen sehr schnell gefunden.
Das würde für die Lösung mit
26 Data- Sätzen sprechen mit
Eventuell alle Einträge mit "A" in einem Megalangen-A$-String, wo mit Semikolon getrennt ist. Kiffi hat ja den Vorschlag mit PackMemory() und UnPackMemory() gemacht. Dann gibt es einen B$, C$ usw.
Andere Idee, die ich aber noch nich völlig durchdacht habe. Es gibt keine Wörter mit 1 Buchstaben im Wörterbuch. Wenn
man nun das ganze Wörterbuch als Array hat und ein zweites Array das sich Sprungmarken der ersten zwei Buchstaben
merkt:
Aa = 1
Ab = 5
Ac = 8
...
Ba = 345
Bb = 351
Bc = 378
..
Zy = 59675
Zz = 59678
Dann könnte man sehr schnell anhand der ersten zwei Buchstaben im "Wörterbuch" an die richtige Stelle gelangen.
Kann man das irgendwie elegant?
Und die wichtige Performance-Frage: Weißt du, wie groß Arrays sein können? Sind 200000 Felder kein Problem, wenn es
sich um Strings handelt, und jedes Feld z.B. 100 Buchstaben hat? Wie lange dauert das Einlesen und ist das Programm bzw. der Arbeitsspeicher nicht überfordert?
Auch am Sonntag schon so früh fit?
Hallo Nachbar, Korbach liegt ja nicht weit von Meschede, wo ich wohne
Ja die Kompression sollte für den Übersetzer sein. Aber deine Überlegungen stimmen, da kann man nicht viel
komprimieren. Vielleicht sollte ich das Ganze doch von einer anderen Seite her anpacken. Ich gebe dir als Experten einmal
ein paar mehr Infos für weitere Überlegungen:
Die Daten sehen ja so aus:
abadono abadon
abako rechenbrett
babao rosinenkuchen
...
zumzumo gesumm
sollen aber später erweiter werden z.B. mit Wortangaben, Mehrzahl, Vergangenheitsformen bei Verben usw. :
abako rechenbrett substantiv rechenbretter
babao rosinenkuchen substaniv rosinenkuchen ...
trinki trinken verb trank getrunken
Die txt-Datei hat momentan 60000 Einträge und ist (mit bisher zwei Spalten) 1500 kB groß. Die Überlegung mit dem
Komprimieren kam daher, dass die Datei gezippt nur 500 kB groß ist.
Kiffi hat den Vorschlag mit PackMemory() und UnPackMemory() gemacht. Muss ich mir noch ansehen.
Ich glaube, es ist besser die ganze Zeile in ein Feld zu ziehen und nur ein Array zu verwenden
Die Überlegung: Muss/Kann ich wirklich alle 60000 Zeilen in ein Array ziehen (Größe des Arbeitsspreicher?, Geschwindigkeit?) oder ist es nicht sinnvoll erst dann nur einzulesen, wenn das Wort gebraucht wird.
Wenn man also den Satz:
Mi trinkas kafon hodiau (Ich trinke heute Kaffee)
übersetzen will, würde man nur alle Wörter mit M einlesen bis zum Wort "Mi", dann mit T, dann mit K und dann mit H
durchsehen. Da kafon mit K und dann A beginnt, würde dieses Wort unter K beim Einlesen sehr schnell gefunden.
Das würde für die Lösung mit
26 Data- Sätzen sprechen mit
Eventuell alle Einträge mit "A" in einem Megalangen-A$-String, wo mit Semikolon getrennt ist. Kiffi hat ja den Vorschlag mit PackMemory() und UnPackMemory() gemacht. Dann gibt es einen B$, C$ usw.
Andere Idee, die ich aber noch nich völlig durchdacht habe. Es gibt keine Wörter mit 1 Buchstaben im Wörterbuch. Wenn
man nun das ganze Wörterbuch als Array hat und ein zweites Array das sich Sprungmarken der ersten zwei Buchstaben
merkt:
Aa = 1
Ab = 5
Ac = 8
...
Ba = 345
Bb = 351
Bc = 378
..
Zy = 59675
Zz = 59678
Dann könnte man sehr schnell anhand der ersten zwei Buchstaben im "Wörterbuch" an die richtige Stelle gelangen.
Kann man das irgendwie elegant?
Und die wichtige Performance-Frage: Weißt du, wie groß Arrays sein können? Sind 200000 Felder kein Problem, wenn es
sich um Strings handelt, und jedes Feld z.B. 100 Buchstaben hat? Wie lange dauert das Einlesen und ist das Programm bzw. der Arbeitsspeicher nicht überfordert?
http://de.wikipedia.org/wiki/Bin%C3%A4rer_Suchbaum
Damit kriegst du eine verdammt schnelle suche hin!
Warum müssen deine Gepackten Daten noch lebar sein?
Wenn es doch net so wichtig ist wäre ein Huffman relativ einfach umzusetzen!
Damit kriegst du eine verdammt schnelle suche hin!
Warum müssen deine Gepackten Daten noch lebar sein?
Wenn es doch net so wichtig ist wäre ein Huffman relativ einfach umzusetzen!
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
hallo nachbar...
Meschede, is ja cool.
also zum thema.
1500KB is dochn witz, ich hab schon größere screenshots gesehen.
ernsthaft, ich würde da absolut bei klartext bleiben, außer du willst es wirklich deshalb codieren, um es vor zugriffen zu schützen.
es ist auch kein thema, so etwas auf einmal in den speicher zu packen.
von der grundsätzliche anwendung her wärs schon etwas für ne richtige datenbank,
weil du die grundbegriffe in beiden sprachen sortiert haben könntest,
in zwei getrennten tabellen, und die ergänzungen in einer dritten...
aber das ist fürs erste nich so wichtig.
hast du dir den Link, den Konne gepostet hat mal angesehen?
so eine suchmethode meinte ich. man nennt das auch indiziert-binäres suchen.
der vorteil ist, dass du mit nur 16 datensatzzugriffen den richtigen satz von 65536 datensätzen finden kannst.
(als beispiel)
voraussetzung wäre halt, dass die liste sortiert ist.
deshalb meinte ich auch 2 Tabellen/Arrays, die in bezug zueinander stehen,
und die eine deutsch-alphabetisch sortiert, die andere esperanto-alphabetisch.
um das umzusetzen wäre zuerst einmal wichtig, die begriffe in getrennten strings zu haben.
also nicht mit leerstelle zwischen, sondern richtig getrennt.
wichtig wäre dabei nur, dass die begriffspaare, die zusammengehören, auch wirklich direkt nacheinander kommen.
die kann man dann in zwei korrespondierende tabellen einlesen,
beide unabhängig voneinander alphabetisch sortieren,
und dann eben in einer suchen und nach dem verweis aus der anderen die übersetzung holen.
auch kombinationen mehrerer begriffe wären möglich, nicht so sehr viel mehr aufwand.
Meschede, is ja cool.
also zum thema.
1500KB is dochn witz, ich hab schon größere screenshots gesehen.
ernsthaft, ich würde da absolut bei klartext bleiben, außer du willst es wirklich deshalb codieren, um es vor zugriffen zu schützen.
es ist auch kein thema, so etwas auf einmal in den speicher zu packen.
von der grundsätzliche anwendung her wärs schon etwas für ne richtige datenbank,
weil du die grundbegriffe in beiden sprachen sortiert haben könntest,
in zwei getrennten tabellen, und die ergänzungen in einer dritten...
aber das ist fürs erste nich so wichtig.
hast du dir den Link, den Konne gepostet hat mal angesehen?
so eine suchmethode meinte ich. man nennt das auch indiziert-binäres suchen.
der vorteil ist, dass du mit nur 16 datensatzzugriffen den richtigen satz von 65536 datensätzen finden kannst.
(als beispiel)
voraussetzung wäre halt, dass die liste sortiert ist.
deshalb meinte ich auch 2 Tabellen/Arrays, die in bezug zueinander stehen,
und die eine deutsch-alphabetisch sortiert, die andere esperanto-alphabetisch.
um das umzusetzen wäre zuerst einmal wichtig, die begriffe in getrennten strings zu haben.
also nicht mit leerstelle zwischen, sondern richtig getrennt.
wichtig wäre dabei nur, dass die begriffspaare, die zusammengehören, auch wirklich direkt nacheinander kommen.
die kann man dann in zwei korrespondierende tabellen einlesen,
beide unabhängig voneinander alphabetisch sortieren,
und dann eben in einer suchen und nach dem verweis aus der anderen die übersetzung holen.
auch kombinationen mehrerer begriffe wären möglich, nicht so sehr viel mehr aufwand.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
und Konne