Aufgabe 10.1


So, auch wenn ich die Lösung unschön finde zähl ich jetzt mit hoch und runter wieviele Elemente ich schon eingefügt bzw. gelöscht habe.
Ne besser Lösung fällt mir im Moment nicht ein und die Tests funktionieren (Wie immer vielen vielen Danke für den Test!!!)


Das Problem liegt darin, dass du dir selbst nicht ganz klar darüber bist, was ANFANG und ENDE eigentlich bedeuten, konkret ob ENDE in der Liste enthalten ist oder nicht.

Sich zu merken, wie viele Elemente man in der Liste hat, dürfte eigentlich die beste und vielleicht auch schönste Möglichkeit sein.

Eine andere hab ich oben schon versehentlich gepostet, und im Wesentlichen entspricht sie eigentlich eh dem ANFANG und ENDE von oben.
Man kann sich die Position merken, an die man das nächste Element schreibt, und die Position, von der man das nächste Element liest, wobei man dabei noch irgendwie dran denken muss, wann die Liste leer ist und wann nicht (wie genau, ist dann eigentlich eh nimmer schwer)
Eigentlich ist das aber wirklich nur besser, wenn man dann tatsächlich mit Zeigern arbeitet, was in dem :#: Java ja leider auch nicht geht…


Hallo erstmal ich bin neu hier :cheesy:

Ich stelle mir momentan die Frage, ob es mit unserem Packer nicht prinzipiell möglich sein sollte, JEDE Datei zu packen. Also egal von welchem Format.
Mit meiner bisherigen Lösung, kann ich Text-Dateien oder halt auch java-Quelldateien packen und entpacken und das funktioniert auch super.
Ich kann auch die Datei von Airhardt entpacken.
Nur wenn ich eine zip oder xls Datei packen will kommt ausschließlich Schrott raus.
Weiß wer warum man mit diesem Packer solche Dateien nicht packen kann,
oder sollte das prinzipiell schon möglich sein und der Fehler liegt in meinem Code?

Wie habt ihr eigentlich das mit den 2 Byte gelöst?
Man muss ja im Prinzip zwei Integer zu 2 Byte zusammenfassen.
Bitoperatoren funktionieren auf nem Integer ja nicht. Gibt es noch ne elegantere Lösung als für jedes Bit zu schauen ob man es braucht?
Weil das sind bei mir einige unschöne if - Abfragen…

Danke für euere Hilfe…


Prinzipiell sollte der Algorithmus auch auf ZIP- oder XLS-Dateien funktionieren, allerdings ist dabei alles andere als eine Verkleinerung zu erwarten…

Es könnte vielleicht sein, dass es deswegen nicht geht, weil in Java Byte als vorzeichenbehaftete Zahl interpretiert wird; sobald das oberste Bit gesetzt ist, ist’s negativ (–> Zweierkomplement!), und vielleicht hat dein Programm damit irgendwelche Probleme…

Und die bitweisen Operatoren funktionieren auf einem Integer durchaus, allerdings hab ich eine ganze Zeit gebraucht, um herauszufinden, wie genau. Denn auch hier wird zum Teil auf das Vorzeichen geachtet – warum auch immer…
Die brauchbaren wären (mit ein bisschen Vorsicht, und gelegentlich auch mal einem Cast nach [m]long[/m]): [m]& | << >>>[/m]


Oh Danke für die schnelle Antwort…
Ja scheint wohl an meinem Algorithmus zu liegen.
Bei 90% aller Textdateien funktioniert er ohne Problem aber bei wenigen Ausnahmen, vor allem sehr großen Textdateien wird mal 1 Zeichen vergessen. Hab wohl noch nen Fehler drin. Muss mich mal auf die Suche machen.


Arbeitet ihr beim Einpacken mit einer Schlange oder mit getrennten Schlangen für den Vorschau und den Suchbereich?
Ich finds außerdem irgendwie komisch, dass die den Offset von rechts zählen, wäre das von links nicht einfacher?


Also das Problem schein bei mir zu sein, dass ich halt maximal solange einlese, bis mir leseByte -1 zurückgibt.
Allerdings kann man ja auch Bytes einlesen die -1 sind…
Jetzt hab ihc dann natürlich das Problem, dass ich zwischen EOF und Bytewert -1 unterscheiden müsste.
Hat diesbzgl. irgendwer ne Idee? Mir fällt atm nichts ein :wand:


InputStream.read gibt dir einen [m]int[/m] im Bereich 0…255 oder -1 zurück. Wenn du den nach [m]byte[/m] castest bzw. an eine [m]byte[/m]-Variable zuweist, werden einfach die untersten 8 Bit verwendet und das -1 geht verloren.

=> Lösung: zuerst in eine [m]int[/m]-Variable einlesen, auf -1 abfragen, und dann ein [m]byte[/m] draus machen.


Doch, Bitoperationen funktionieren auch auf Integer, die schönen Schiebeoperationen funktionieren sogar nur auf int und long, nicht auf byte… (bis ich da drauf gekommen bin…) Das bedeutet, dass er ein byte erstmal nach int castet, bevor er es verschiebt… :wand:

Ach ja, binäre Dateien kann mein Packer verarbeiten, auch wenn er sie um ca 50% aufbläht :wink:

Und ich hab mal (mir war etwas langweilig) ein paar Tests für die Zirkuläre Reihung und die Halde geschrieben:
http://wwwcip.informatik.uni-erlangen.de/~siliwoit/


[s]Kann vielleicht jmd ein paar Worte dazu sagen, wie der Lehrstuhl 9 das ganze umgesetzt haben will?
Das Prinzip von LZ77-Komprimierer ist ja klar, aber ich blick nicht ganz durch wie sich der Lehrstuhl 9 sich das ganze vorstellt. :vogel:

Thx[/s]

Hat sich erledigt. Thx anyway.


Welche Aspekte sind denn unklar bzw was hättest du dir anders vorgestellt?
Ich hab mir da keine grossen Gedanken gemacht wie die sich das vllt gewünscht hätten. Kann sowieso nicht wirklich nachvollziehen warum man einige Sachen so kompliziert machen soll.


Ich weiß GENAU was du meinst.
Aber irgendwann hab ich mich auch gefragt: hey Moment, der wird doch byte nicht erst auf int casten…

Der Test für die Halde ist cool! (Wobei ich mich ehrlich frag, warum das Interface nicht auch eine Methode „getPriority“ vorgibt? Braucht man so oder so um zu vergleichen… Warum haben die das also nicht gleich mit ins Interface?)


Wie habt ihr eigentlich die Problematik mit den inkompatiblen Typen int zu byte geloest?

Ich hab hier folgendes:

int index = in.read(); //in.read() returns an integer!
lookPuffer.append((byte) index);

ist klar, lookPuffer bekommt jedes Mal den Wert null, da sich integer nicht zu byte typen lassen. Wie habt ihr das ganze geloest? Vielleicht bin ich auch mit dem in.read total falsch.

Thx im Voraus


mindex[/m] sollte eigentlich schon funktionieren – es werden halt einfach die niedrigsten 8 Bit des [m]int[/m]s verwendet.
Funktioniert bei mir jedenfalls…

A ja, und primitive Typen wie [m]byte[/m] oder [m]int[/m] können als Wert gar nicht die [m]null[/m]-Referenz haben… ?


ja, geht. ich hab ein fehler in ner for-schleife gehabt, deswegen war mein array irgendwie total verunstaltet. :wink:


hmm, mein Decoder geht soweit, nur folgendes, ich bekomm immer das tupel

(0, 0, ’
')

beim ende der zu encodierenden datei zureuck. normal oder nicht? ;=)

thx


hellseh Deine Testdatei endet vermutlich mit einem Zeilenumbruch.


hmm, eben nicht, dass ist ja das verwunderliche :stuck_out_tongue:


Hm… Unter Linux sind ja einige Programme ziemlich empfindlich was das [m]\ n[/m] am Dateiende betrifft… Und nachdem ich mal davon ausgeh, dass du durchaus in der Lage bist, einen Zeilenumbruch zu finden :wink: , würd ich mal vermuten, dass das vielleicht tatsächlich irgendein Linux-Java-Automatismus ist, der dafür sorgt, dass wirklich an jeder Datei ein Zeilenumbruch hängt…
Jedenfalls hat mich der Sch… auch schon ziemlich geärgert; ich weiß zwar nicht mehr so genau, wie das gegangen ist, aber ich hatte meine Binärdaten plötzlich als “Unicode” in der Datei stehen…

Natürlich alles nur Spekulationen, aber…

Wär natürlich interessant, was dabei rauskommt, wenn du am Dateiende wirklich einen Umbruch hast – zwei Stück oder doch nur einer?


Ok. hab des irgendwie gefixed. Frag mich nicht wie, aber scheint zu gehen. :*)
Kann vielleicht jmd mal das Wort “blablabla” komprimieren? ich bekomm als Ergebniss:

(0, 0, ‘b’)
(0, 0, ‘l’)
(0, 0, ‘a’)
(3, 3, ‘b’)
(3, 3, ‘’)

Kann das Jemand bestaetigen?