Non-math-geek needs help with CRCs (binascii.crc32)

[nobody]

> >> >Somehow, depending on how the numbers are massaged, the old code based
on
> >> >$EDB88320 is compatible with what the above site documents as
$04C11DB7.
> >> Did you notice that those two numbers are mirror images of each other?
> >> Could just be a difference in interpretation.
> >
> >How does one get the same result with a reflected and non-reflected
> >algorithm using the exact same input?
>
> Well, what I was saying was that perhaps the two algorithms are doing
their
> computations in the opposite order.  It's just suspicious that they are
> reflections of each other.

Errr... according to the document referenced earlier, the reflected
algorithm is due to hardware UARTs supplying the bits in reverse order, so
hardware CRC implementations started doing their calculations in reverse,
hence the back-arsewards $EDB88320 poly.  However, pretty much every
software based algorithm I've seen up to recently has been the reversed
one.. with normal data.. so no need for the backwards poly.. so I dunno WTF
is going on there.