PureBoard

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.

[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?

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.

@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.

Eckhard.S hat geschrieben:Ich suche eine schnelle Möglichkeit, einen Textstring in einen Textstring zu komprimieren (weniger Zeichen als vorher) und wieder zu dekomprimieren.

dafür gibt's die PB-Befehle PackMemory() und UnPackMemory(). Das
Komprimieren lohnt sich allerdings nur bei entsprechend langen Strings.

Eckhard.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.

Den komprimierten String kann man mit dem Base64Encoder() so
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

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?

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!

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.

Danke an Kaeru Gaman und Konne !
Ich mache nun Einlesen von Datei in Array und binäre Suchbaummethode. Superschnell! Nach nur 16 Suchversuchen ist die Zeile gefunden.
Hurra!

Weitere Fragen zum Projekt als neues Thema.