Also ich krieg für blablabla
(0, 0, ‘b’)
(0, 0, ‘l’)
(0, 0, ‘a’)
(3, 3, ‘b’)
(3, 1, ‘a’)
Macht auch in meinen Augen mehr Sinn, ein Null-Zeichen am Ende ist eigentlich überflüssig und in dem Beispiel auf dem Aufgabenblatt ist beim letzten Tupel auch ein ‘r’ und kein ‘’.
Wenn du das b schon im SearchBuffer stehen hast, wieso hat dein letztes Tupel die Länge 3?
Ich bekomme folgendes:
$ echo blablabla > blabla.txt
$ java Packer -c blabla.txt blabla.lz
(0, 0, 'b')
(0, 0, 'l')
(0, 0, 'a')
(3, 3, 'b')
(6, 2, '
')Scheint echt so, als würden einem Unix und Konsorten (arbeite hier grad unter MacOS) immer einen abschließenden new-line mit unterschieben…
solved
Kann es sein, dass im Beispiel ein Fehler ist?
Warum ist das letzte Tupel 6,4,‘r’ und nicht 4,4,‘r’?
Oder warum ist in der vorletzten Zeile 6,6,‘f’?
Müsste es nicht 0,6,‘f’ sein?
Hab’s…
Dazu durchsucht (aufsteigender Index im Suchpuffer) man den gesamten Suchpuffer vom jüngsten zum ältesten Eintrag.
Hm, eines aber noch zur letzten Zeile beim Einpackbeispiel.
Warum 6,4,‘r’ und nicht 6,5,‘’ ?
Wieso (6, 2, ‚\n‘)? Sollen wir nicht den SuchBuffer von hinten durchgehen?
Und zum [m]echo[/m] gehört ein abschließendes newline…
@hehejo: dann würdest du beim auspacken noch ein ‚‘ an die Datei anhängen, also ein byte mit 0000 0000. Das ist aber nicht erwünscht, deshalb muss im letzten Tupel auch das letzte Zeichen der Datei stehen.
Hab wegen der Suchrichtung nix gefunden (es sein denn, ich hab was überlesen, was gut möglich ist ;-)). Steht nur drin, dass man den offset von rechts angeben soll, aber nicht, dass man nicht von links suchen darf 
Das wusst’ ich jetzt nicht. Hab das allerdings auch, wenn ich die Datei in irgendeinem Editor erstelle.
Außerdem müsste man sonst 0-32 in 5 Bits unterbringen
hat sich erledigt, testcase pääst 
heyho!
also ich häng scho seit stunden an dem dummen lz77 algorithmus…
wie genau muss ich dabei vorgehen wenn ich die längste bereits zusammenhängende zeichenkette suche? ich blick nun gar nicht mehr durch.
die tupel ansich schreibt er gut.
//schauen ob das nächste Symbol gleich ist
if (look.getAt(0) == pack.getAt(b)) {
counter++;
b++;
look.dequeue();
}funktioniert genau für das finden von genau einem zeichen! (mal abgesehen dass das mit dem pack.getAt(b) reiner zufall ist und je nach beispiel anders sein muss.
aber kann mir jemand mal in worten sagen wie ich dem algorithmus zu schreiben habe? ich komm im moment echt nicht weiter…
Hey!
ich haette da jetzt mal eine ganz grundsaetzliche Frage…
was genau passiert hier? Ich hab irgendwie nichtmal gecheckt wie man das aufzurufen hat. Also die zirkulaere Reihung hab ich, die funktioniert auch, aber was den Rest der Aufgabe angeht… :-/
Koennte mir einer von euch bitte kurz erklaeren was ich ueberhaupt reinbekomme und wie man das dann am Ende testen kann?
Waere echt super,
st
Du musst beispielsweise in Einpacker mit leseByte() immer das naechste Byte aus dem Datenstrom abrufen und damit dann deine ZirkulaereReihung (i.e. look-Ahead-Buffer bzw von dort auch search-Buffer) fuellen.
Dann musst du eben den LZ77 Algorithmus irgendwie implementieren und mit schreibeTupel die entsprechenden Tupel dann ausgeben lassen bzw spaeter ueber schreibeByte in den outStream schreiben.
Testen kannst du das ganze dann ueber die Packer-Datei indem du beispielsweise eine Datei mit dem Inhalt “foobarfoobarfoobar” erstellst und dann den packer mit “java Packer -c foobar.txt foobar.lz” aufrufst.
btw, ich hab da mal eine kleine Frage zu diesem 2-Byte Ausgabe-Tupel:
Das ganze ist schon so gedacht, dass ich mein Offset-Int nehme, das dann um 5 bits nach links shifte, mein Laenge-Int bei dem nur dir 5 LSBs gesetzt sind dazuaddiere und das dann als 2 Byte ausschreibe (+ ein Byte fuer das Folgezeichen), oder?
Ach, und das kommt mir grade noch, muss ich da noch irgendwas wegen little-Endian beachten, eigentlich ja nicht oder?
[edit]
Nu hab ich grade gesehen, dass schreibeByte ja einen int als Parameter nimmt?!
Aber int = 32bit = 4 byte… :rolleyes:
Hm, irgendwie hab ich das dumpfe Gefuehl ich steh grade auf dem Schlauch… Vielleicht sollt ich erstmal ne Pause einlegen und was essen
thx & gruß
Nic
ok, danke,
ich versuchs mal…
Ja. Wobei deine 8 niedrigsten Bits genommen und der Rest einfach abgeschnitten wird.
D.h. du musst deine 2Byte halt auf die 8 untersten Bits von 2 int’s aufteilen.
Ich kann’s mir nicht vorstellen – prinzipiell ist Java ja doch so gedacht, dass es plattformunabhängig sein sollte. Und so aufgeblasen wie die bitweisen Operatoren eh schon sind, …
Ach Moment, wir schreiben ja eh nur einzelne Bytes => komplett egal.
…und ich würd statt dem Addieren ein oder nehmen, aber sonst ist es prinzipiell so möglich – auch wenn zum genauen Format keine Vorgaben existieren, weswegen mein Packer mit dem von Airhardt schon mal ordentlich inkompatibel ist…
Ich nehm mal an die nicht-vorhandenen Vorgaben sind Absicht, schließlich sollen wir in Teilaufgabe c) ja die Ausgabe optimieren…
Wodurch mein Packer schon mal völlig inkompatibel mit euren ist… 
Naja, dass nach dem Optimieren die Kompatibilität beim Teufel ist, ist eh klar.
Aber vorher wäre es vielleicht auch für die Tutoren recht praktisch, wenn man beim Testen ein einheitliches Dateiformat hätte, und nicht zuerst jedes Mal schauen müsste, ob der seine Bits jetzt oben oder unten reinpackt, ob zuerst Offset und dann Länge oder andersrum kommt etc. …
Hm… ich hoffe jetzt mal dass wir Teilaufgabe b) und c) nicht getrennt abgeben müssen… sonst müsste ich den Packer noch mal kräftig modifizieren, dass er wieder wie in b) gefordert ist…
Und den Testcases ist es wahrscheinlich auch egal wie die Ausgabe ist, die ver- uind entpacken wahrscheinlich ne Testdatei und schauen ob das gleiche rauskommt…
also ich denke ehrlich schon, dass du aufgabe b) und c) getrennt abgeben musst, weil c) sind ja die sogenannten bonuspunkte, welche mit dem pflichtteil nicht zusammenhängen dürften.
Trotzdem kann man das ja “auf einmal” abgeben, die sehen ja dann ob man optimiert hat, und wer optimiert hat war/wäre sicher auch in der Lage, das Programm wie in b) verlangt zu schreiben. Auf Plagiarismus wird ja geprüft… (auch wenn ich das bei so einfachen/kurzen Programmen, bei denen eh ein Drittel schon als Code und das zweite Drittel durch die Aufgabenstellung gegeben ist, nicht für sonderlich sinnvoll/ergiebig halte)
hi Leute!
hab ein kleines Problem mit LZ77… Präfix ist eigentlich so definiert, dass das letzte Element (vom lookAheadBuffer in diesem Fall) nicht dazu gehören kann, und so war es auch im Beispiel da: a r f o o b a r f o o b a r (6, 4, ‘r’): das letzte “r” könnte ja auch dazu gehören, tut es aber nicht… andererseits, wäre es unlogisch und ineffizient, des so zu implementieren… also, was ist mit dem “r”?liegt es daran, dass es das alle letzte Element ist, oder doch an dieser Präfix-Geschichte?
Wenn du das letzte Element ( hier das ‘r’ ) mitnimmst, was schreibst du dann ins Tupel? Ein Null-Zeichen? Das steht dann nachher auch in der Datei dirn…
Wenn du dann zufällig mal den ganzen LookAheadBuffer im SearchBuffer findest hast du so n Null-Zeichen mitten in der Ausgabedatei…
Deshalb ist es meiner Meinung nach unabdingbar, das so zu machen wie im Beispiel.
das gilt aber nur für das letzte Zeichen…müssen wir nur deswegen alle anderen auch so implementieren?
ist nur eine prinzipuelle Frage, die Aufwände sind in beiden Fällen genau gleich groß, glaub ich…