Seite 8 von 10

Verfasst: 18. Jun 2007 18:54
von FloJ
Den Fehler hab ich jetzt auch und wie oben erwähnt bin ich immernoch komplett ratlos.

Verfasst: 18. Jun 2007 19:57
von infinity_dev
@die das Problem betrifft

Schreibt ihr ein byte in den OutputStream oder einen int? Die write() Methode erwartet ja einen int. Ein Byte ist in Java signed, hat also den Range -128 bis 127. Beim Übergeben an die write() Methode wird das byte in einen int konvertiert. Der ist weiterhin negativ (Das Sign-Bit vom byte wird also praktisch in das höchstwertigste Bit vom int geschoben).

Laut dieser Spezifikation, sollte dies durch die Implementierung des verwendeten OutputStream berücksichtigt werden:
http://java.sun.com/j2se/1.5.0/docs/api ... write(int)
Ein Outputstream hat also z.B. sowohl aus 214 als auch aus -42 ein Ö (in ANSI-Code) zu machen.

Hier mal ein Codeschnipsel mit dem man das beim BufferedOutputStream überprüfen kann (hoffe das ist ok):
BufferedOutputStream strm1 = new BufferedOutputStream(new FileOutputStream("writeInt.txt"));
BufferedOutputStream strm2 = new BufferedOutputStream(new FileOutputStream("writeByte.txt"));
strm1.write(214);
strm2.write((byte)214);
strm1.close();
strm2.close();

Ich denke mal hier patzt der in den Testcases verwendete OutputStream, was die neue Fehlermeldung wohl auch unterstreicht. ;)

Verfasst: 18. Jun 2007 21:41
von MisterD123
mal abgesehen davon das er das zu machen "hat", woher wollt ihr solche werte denn haben wenn nicht aus einem bug von euerm programm? oO die files enthalten nirgends codes für negative zeichen und selbst wenn kommen die nicht vor, ihr habt also irgendwas falschgemacht..

Verfasst: 18. Jun 2007 21:44
von corn
jajaja... infinity hat mir fruendlicherweise die stelle in der API gezeigt die ich missachtet hab... wieder mal alles meine schuld ;-) das nächste mal lasse ich dich die Testcases schreiben

Der Test wurde entsprechend geändert.
Alle die nur an dem DecodeTest aus vermutlich diesem Grunde gescheitert sind mögen einfach nochmal Uploaden.

Grundsätzlich gilt dennoch... wenn man casten muss hat man meist was in seinem Programmdesign verkert gemacht... einen int zwischenzeitlich auf byte zu casten bringt _keinen_ geringeren Speicherverbrauch mit sich.

Verfasst: 18. Jun 2007 22:58
von MisterD123
int hat eh nur 4 byte, selbst wenns nur ein byte brauchen würde, mehr als 256*4 = etwas über ein kb speicher spart man damit eh nich oO

Verfasst: 19. Jun 2007 12:28
von marlic
corn hat geschrieben:
Martin K hat geschrieben:
X-Out hat geschrieben:Testcase: testFaust took 1,059 sec
FAILED
Your bitlength differs from the optimium (you: 1041303 optimum: 1041302)
OK, ich weiß woran es liegt nach langem hin und her probieren, hab ich die faust.huffman Datei schließlich 1 Byte kleiner bekommen und somit würde die bitlength wohl wieder stimmen.
Entschuldigung, das ist mein Fehler!
Ich hatte in dem Testcase de Länge des Codes des EoF-Zeichen nicht berücksichtigt. Denkfehler. Fixed.

Ich habe deinen ursprünglichen Upload erfolgreich gegen das neue Testcase getestet. Eine weitere Änderung ist also nicht nötig.
Das gilt vermutlich für alle die Probleme mit der Bitlänge hatten und bei denen die Differenz +1 Bit ist. (Das hängt davon ab wie früh man das EoF Zeichen mit anderen Zeichen zusammenfasst)

Naja so ergeht es dann halt denjenigen die so früh anfangen... sie müssen Versuchskaninchen für Testcases spielen :wink:

So ... wieder da, der Fehler!



Testlauf 7581

Code: Alles auswählen

Testcase: testFaust took 0.965 sec
	FAILED
Your bitlength differs from the optimium (you: 1041303 optimum: 1041302)
junit.framework.AssertionFailedError: Your bitlength differs from the optimium (you: 1041303 optimum: 1041302)
	at TestEncoding.fileTest(TestEncoding.java:32)
	at TestEncoding.testFaust(TestEncoding.java:48)

Verfasst: 19. Jun 2007 12:36
von andy-held
corn hat geschrieben:Wenn sonst noch jemand an einer IOException scheitert möge er/sie sich bei mir melden.

EDIT: Bitte gebt mir auch die Uplaod-Nr eures fehlgeschlagenen Tests an!
Bei mir treten auch IOExceptions auf, im Testsystem, durch eigene Tests habe ich diese noch nicht produzieren können. Die Nummer meines Fehlgeschlagenen Tests ist 7534

Verfasst: 19. Jun 2007 13:34
von Wang Tang
Die IOExceptions hatte ich auch:
Hatte irgendwo einen BufferedReader/FileReader, den hab ich ausgetauscht durch einen FileInputStream -> keine IOExceptions mehr.

Verfasst: 19. Jun 2007 19:32
von Martin K
Wang Tang hat geschrieben:Die IOExceptions hatte ich auch:
Hatte irgendwo einen BufferedReader/FileReader, den hab ich ausgetauscht durch einen FileInputStream -> keine IOExceptions mehr.
Damit hat das aber nichts zu tun.
Liegt viel mehr daran, dass es im Testsystem eine IOException gibt, wenn die Sekunden der aktuellen Uhrzeit gerade auf 42 stehen und es im selben Moment anfängt zu regnen.
Bei mir gabs im selben Code einmal eine IOException und einmal nicht, hat also nix mit deinem Code zu tun!
Melde dich einfach bei corn, und schon wird aus deinem FAILED ein PASSED ;)

Verfasst: 19. Jun 2007 19:49
von sonothar
marlic hat geschrieben:So ... wieder da, der Fehler!

Testlauf 7581

Code: Alles auswählen

Testcase: testFaust took 0.965 sec
	FAILED
Your bitlength differs from the optimium (you: 1041303 optimum: 1041302)
junit.framework.AssertionFailedError: Your bitlength differs from the optimium (you: 1041303 optimum: 1041302)
	at TestEncoding.fileTest(TestEncoding.java:32)
	at TestEncoding.testFaust(TestEncoding.java:48)
ich hatte den Fehler heute mittag auch. dann hab ich das wie Martin K schon mal geschrieben hatte, den Vergleich beim suchen des Knoten mit der kleinsten häufigkeit hab ich mit "<=", statt wie vorher "<", laufen lassen. Nun hab ich da auch passed mit 1041302 bits

Verfasst: 19. Jun 2007 19:55
von Martin K
Hast du auch meinen Nachtrag gelesen?
Martin K hat geschrieben://Nachtrag:
Das mit dem <= und < war nur ne Möglichkeit einen Bit zu sparen, der Fehler in des Testcases wurde aber behoben und mittlerweile sollten beide Methoden funktionieren
corn, der Tutor der für dieses Praktikum verantwortlich ist, hat diesen Fehler behoben:
corn hat geschrieben:Entschuldigung, das ist mein Fehler!
Ich hatte in dem Testcase de Länge des Codes des EoF-Zeichen nicht berücksichtigt. Denkfehler. Fixed.
Anscheind ist nun wieder ein altes Testcase im System oder was auch immer, aber zum Glück habe ich noch mein PASSED und das wieder mit der ursprünglichen Version, also Vergleich mit "<" :)

Verfasst: 19. Jun 2007 19:59
von sonothar
hab den nachtrag gelesen, daher hatte mich das auch gewundert, als der Fehler heute kam. aber offensichtlich ham die lieben tutoren wieder mal was zum schlechteren geändert
Meins is jetzt passed mit "<=", was solls ;)

Verfasst: 19. Jun 2007 20:25
von marlic
hmpf ... hab nicht wirklich lust das nochmal umzuschreiben ... war so schön mit der PriorityQueue ... also ihr meint, man sollte - nach dem Praktikumssystem eher die nehmen, die weiter hinten in der Liste liegen, oder wie? Und wie soll das bitte begründet werden?

Finde ich meines ermessens ziemlich unsinnig.

Außerdem sollte doch eigentlich in jedem fall die Bitlänge gleich - da optimal - sein, oder? Hat da jemand ne idee, woran das liegt?

Mal abwarten, was "corn" dazu sagt ;)

Verfasst: 19. Jun 2007 20:28
von MisterD123
also ich hab mit ner priority queue passed oO aber eventuell in der zeit wo der fehler halt nich in den tests war wenns denn nun einer is oder wie auch immer x)

Verfasst: 19. Jun 2007 20:34
von HolgerF
Ich bin mit einer PriorityQueue noch vor der Behebung dieses Fehlers durch gewesen, also das sollte allemal gehen...