Talk:Computation of cyclic redundancy checks

message: Discussion moved from Talk:Mathematics of CRC#Misimplimentation by Regregex (talk) on 13:53, 23 January 2008 (UTC)
replies: text: The algorithm (2nd box) is correct as I understand it.  The changes would not break it, but would make it harder to implement.  The current shift register lies in bits 0 to n-1, whereas in your case it would lie from bit 1 (as multiplication by x is the last step, so bit 0 = 0) to n (where the top bit is tested.) This would overflow machine registers of size n. -- Regregex (talk) 13:53, 23 January 2008 (UTC)
thread_title:  Misimplimentation 

message: Some HTML/ECMAScript code to display tables as shown in computation of CRC can be found on K5002 talk.
K5002 (talk) 21:08, 30 July 2009 (UTC)
thread_title:  JavaScript used to create the bit-wise equations 

message: A fast parallel CRC algorithm has been published by David Feldmeier
(David C. Feldmeier, Fast Software Implementation of Error Detection Codes.
IEEE TRANSACTIONS ON NETWORKING, VOL. 3, NO. 6, DECEMBER 1995).
This algorithm can be efficiently implemented by using the carryless
multiplication. The algorithm could be added to the article under
parallel computations.Lauri.pirttiaho (talk) 11:25, 5 February 2011 (UTC)
replies: text: Thanks for the reference, looks promising.  I'd add it myself if I had $30 for the paywall: Ten.eleven oh nine, end of the line. – Regregex (talk) 13:07, 7 February 2011 (UTC)
thread_title:  Fast computation using carryless multiplication 

message: The statement "To be precise, the result is the non-inverted CRC of the inversion pattern." appears incorrect.
Background: my test using CRC-32, lsb-first table-driven algorithm, on message: buf[13] = "123456789":
1. Generate message (length = 9) CRC using -1 preset and post-invert (with 0xffffffff), result = 0xcbf43926 (message-specific).  Append this, least-significant byte first, to message (i.e. starting at buf[9]).
2. To check the "transmitted" message, generate buf (length = 13) CRC using -1 preset and post-invert, result = 0x2144df1c (constant for any message with appended CRC-32 as just described).
This is enough to verify any complete message transmission, as section 7.2 states.  
An alternative to step 2 would be to skip the post-invert when checking the "transmitted" message, since it simply complements the result.  The alternative result would therefore be 0xdebb20e3 (constant).
Now for the statement in question.  There are two reasonable interpretations for "non-inverted CRC of the inversion pattern":
(a) CRC of { 0xff, 0xff, 0xff, 0xff }, with no -1 preset (rem = 0) and no post-invert, which yields 0xdebb20e3, or
(b) CRC of { 0xff, 0xff, 0xff, 0xff }, with -1 preset and no post-invert, which yields 0.
It's obvious that case (a) is the correct interpretation, since it is the only non-zero result.  But the value *doesn't* match the result for my original step 2 above.  However, it *does* match the result for my alternative step 2.
Thus, either the existing statement assumes that no post-invert is done on a one-pass check, or the statement is incorrect.  The unstated assumption seems a stretch, and would be kludgy because the CRC function would differ for generation and checking.  So here's my suggested wording for a new statement:
"To be precise, the result is the CRC (without -1 preset, but with post-invert) of the inversion pattern."
I tested this with the common 0xffffffff inversion pattern, yielding 0x2144df1c, as well as an arbitrary pattern of 0xff3f8850, yielding 0xaec8087b.  In each case, the result matched the constant result produced using the CRC algorithm (with -1 preset and post-invert) on the "transmitted" message.
Blott5822 (talk) 08:50, 31 October 2014 (UTC)
thread_title:  7.2 Post-invert -- statement correction justification 

message: A comprehensive table showing the calculation parameters for each CRC type would be a great addition to this article. I have not been able to find a reference that clearly displays the differences between CRCs of the same bit size.
Some key parameters are: Polynomial, Initial Bit Reflection (Y/N), Output Bit Reflection (Y/N), XOR-Input Value (in hex), XOR-Output Value (hex), and the return CRC for the ASCII string "123456789" as a check.  — Preceding unsigned comment added by Cwagner16 (talk • contribs) 15:14, 7 October 2016 (UTC)
thread_title:  CRC Calculation Parameter Table