Projekt Testen / Verifizieren

[habermann24]

Hi

Ich bin der Meinung mein HuffmanAlgo funktioniert, jedoch würde ich ganz gerne mal mit jemanden vergleichen.
Wäre ganz cool, wenn man die Md5-Summe der tuvision.huf vergleicht ... wäre natürlich gut, wenn wir wüssten welche die Richtige ist. Hier ist meine:

MD5 (tuvision.huf) = d0a3e4a573feee7e04875fb17da8c1c7


Ansonsten würde ich ganz gerne wissen, ob die Unit tests, die das Projekt durchlaufen soll irgendwie zur Verfügung stehen? Habe keine lust irgendwelche Punkte zu versäumen, nur weil die sich wieder irgendwelche dummen Spezielfälle überlegen, die wir hätten abdecken sollen...

Sonst noch Ideen wie wir untereinander die Funktionsweise testen können? In der Aufgabenstellung steht noch es sollen beliebige pgm Bilder eingelesen werden können... vielleicht kann man im Forum ein paar andere zum Vergleichen hochladen?

Naja kA

Gruß!

EDIT

Noch ne Frage: Soll die .huf Datei wirklich ohne die CodeTable weggespeichert werden? So wäre es ja unmöglich sie wieder zu "dekodieren"... ist die implementierung vom einlesen (read) also egal?

[Rosenstiel]

Ansonsten würde ich ganz gerne wissen, ob die Unit tests, die das Projekt durchlaufen soll irgendwie zur Verfügung stehen? Habe keine lust irgendwelche Punkte zu versäumen, nur weil die sich wieder irgendwelche dummen Spezielfälle überlegen, die wir hätten abdecken sollen...

Wir stellen die Unit Tests nicht zur Verfügung. Wir denken uns keine dummen Spezialfälle aus.

Noch ne Frage: Soll die .huf Datei wirklich ohne die CodeTable weggespeichert werden? So wäre es ja unmöglich sie wieder zu "dekodieren"... ist die implementierung vom einlesen (read) also egal?

Ja das ist so korrekt.

Viele Grüße

Marcus Rosenstiel

[murbeos]

Hmm.. meine tuvision.huf:

414462c034a3e9c08d7e5b0a3e42c33a

Wär jetzt natürlich ganz gut, noch ein paar mehr Meinungen zu haben..

[xift]

auf brumms seite!
meine tuvision.huf gibt auch 414462c034a3e9c08d7e5b0a3e42c33a

(JUHUUU)

[fuesika]

Ich hätte noch eine dritte Checksumme im Angebot.. allerdings mit richtigen Zwischenwerten und zwei verschiedenen Methoden zur Erstellung der *.huf-Datei. Vielleicht gibt es da Zusammenhänge mit dem System auf dem kompiliert wurde? (Herr Rosenstiel erwähnte so etwas)

@xift, brumm, habermann24: Auf welcher Architektur und mit welchem Compiler habt ihr gearbeitet?

Hier meine md5sum(tuvision.huf): 3dfd73dd9238aa2fbe26ad260e1713d8
(Linux mit gcc 4.3.2)

Zum Vergleich der Algorithmen habe ich noch weitere Dateien erstellt, die wir mit mehreren Leuten 'huffen' und deren Checksummen wir vergleichen könnten. Wer mitmachen möchte meldet sich für den Zugang zu den Dateien am Besten per pn bei mir und kann sich dann unter http://tu.fuesika.de/infing2/ die pgm' herunterladen.

[xift]

Ich hätte noch eine dritte Checksumme im Angebot.. allerdings mit richtigen Zwischenwerten und zwei verschiedenen Methoden zur Erstellung der *.huf-Datei.

Die richtigen Zwischenwerte habe ich auch... Daran wirds nicht liegen. Ich habe mir außerdem die ersten paar Werte der Datei angesehen und es steht wirklich das codierte Bild drin ^^
Was meinst du mit zwei verschiedenen Methoden?

Habe ebenfalls linux mit gcc 4.3.2 verwendet

Gruß,
Michi

[fuesika]

und es steht wirklich das codierte Bild drin ^^

Hm.. vielleicht ist die Frage, was man genau reinschreibt bzw. wie.

Was meinst du mit zwei verschiedenen Methoden?

Nach Zweifeln an meinem Ergebnis habe ich jemanden angeschrieben, mit dem ich mich bis dahin nicht über das Programm ausgetauscht hatte und ersetzte meine CHuffmanFile::write durch seine.

//edit: Werde meine huf-Datei nochmal überprüfen..

[xift]

Da sind wir wieder bei meinem Lieblingsproblem: Der Aufgabenstellung!!!

Es ist nämlich unklar was wir in die Datei schreiben sollen. Es steht in der Aufgabenstellung verändern Sie bitte auf keinen Fall die Art in der die Bits in die Bytes geschrieben werden.
Aber mal ehrlich... Wer hätte zuerst an diese Art gedacht
Jetzt ist es mir immernoch ein Rätsel ob wir das berücksichtigen sollen und das ganze sozusagen umdrehen (erst bit7 dann bit6 dann bit5 ...) oder ob wir das so lassen sollen wie es ist.
bei mir siehts jetzt so aus:

_____Byte 1_______________ Byte 2____________________Byte 3
8 7 6 5 4 3 2 1_______16 15 14 13 12 11 10 9 _____24 23 22 21 20 19 18 17

Die Nummern stehen dabei für die Bits des Codes (hoffe das ist verständlich).
Das macht die Datei schlecht lesbar (nur von hinten lesbar) ^^

Wäre nett wenn Herr Rosenstiel sich dazu mal äußern würde.

Gruß,
Michi

Edit: Habe jetzt Unterstriche zur Formatierung verwendet. Sieht doof aus aber Leerzeichen werden gekillt

[xift]

moon.huf - 00bdadbc64547c57084d3036c0ac0b17
moon2.huf - 38f1b98cc27e809ddc61fdc8e8d4f0e8
rainbow.huf - 4519be5309f9f036be1c6a5c94f8dca5

[mps]

Zum Thema CBitArray:

Ich fülle das BitArray mit der Methode SetBit(), sodass die verdrehte Reihenfolge entsteht, wie Xift es schematisiert hat.

Anschließend hole ich mir einfach das ganze Array und schreibe es dann mit dieser vorgegebenen (verdrehten) Reihenfolge in die .huf Datei.

Ist dies jetzt der Aufgabenstellung konform?

vielen Dank
Michael