crc algo

@kkaw: ok lauft nun auch mit deinem fix...findest du den bugfix durch volkard nicht effizienter?

volkard

Algorithmann schrieb:

@kkaw: ok lauft nun auch mit deinem fix...findest du den bugfix durch volkard nicht effizienter?

Aber meiner ist eher geraten. Ich würde ihn nicht einsetzen, ohne ihn mit ein paar Millionen Tests gegen kkaws Version laufen zu lassen.

Das, was ich geschrieben habe, bezog sich auf die zuletzt hier gezeigte Tabellengenerierung, wo -- und das ist mir jetzt aufgefallen -- die Richtung des Shifts nicht mit dem übereinstimmt, was Du hier zu erst gezeigt hattest.

Algorithmann schrieb:

@kkaw: ok lauft nun auch mit deinem fix...findest du den bugfix durch volkard nicht effizienter?

Ist das ein Bugfix? Das sieht für mich nämlich in erster Linie nach einer CRC mit Polynom x⁸+x⁴+x+1 aus, wobei die oberen 4 Bits aschließend weggeschmissen werden. Ich denke nicht, dass das äquivalent ist.

Bzgl Effizienz: Das sollte keinen Unterschied machen, es sei denn vielleicht, Du rufst calcCrc für jedes Byte einzeln auf.