Talk:Fletcher's checksum

message: It seems to me that the magic constant "360" is subopmtimal. Either it should be changed to "720", as "len" denotes the number of bytes rather than 16-bit words, or, "len" should be changed to denote the number of 16-bit words.
To illustrate this, in the worst case, all 16-bit words on input are equal to 65535. In that case sum2 = 65535 + 2*65535 + 3*65535 ... + 361*65535 = (361*362/2)*65535 = 4282122435 < 4294967296 = 2^32. So we still don't overflow, although the length of the array is 722 bytes in this case. (The sum contains 361 uint16's instead of 360 as sum1 is initialized to 65536).
193.85.150.3 (talk) 15:24, 3 October 2011 (UTC)

message: I've attempted an unoptimized version (based on the code in the optimized version, minus the modulo tricks).  I haven't tested or even compiled it though:
uint32_t fletcher32( uint16_t *data, size_t len )
{
        uint32_t sum1 = 0, sum2 = 0;
 
        while (len) {
                --len;
                sum1 += *data++;
                sum2 += sum1;
                sum1 %= 0xffff;
                sum2 %= 0xffff;
        }
        /* ensure sum1 and sum2 are nonzero */
        if (sum1 == 0) sum1 = 0xffff;
        if (sum2 == 0) sum2 = 0xffff;
        return sum2 << 16 | sum1;
}
This is intended as a partial solution to the problems raised by talk.
- 86.172.2.56 (talk) 04:26, 30 November 2009 (UTC)
thread_title:  An unoptimized version 

message: The main example calculation caption doesn't make sense to me.  Shouldn't the check bits actually be 0x03 and 0x04?  — Preceding unsigned comment added by Dcurtis (talk • contribs) 14:32, 24 September 2011 (UTC)
thread_title:  dcurtis's suggestions 

message: The source code snippets appear to suggest that x%255 is the same as x&0xff which it is not. x%256 would be.  — Preceding unsigned comment added by 212.166.112.250 (talk) 15:54, 10 November 2011 (UTC)
thread_title:  Modulo 255 is not the same as And 255 

message: I think the limit of 360 in the optimized example is incorrect, and should be 359.  Here's the reasoning:
* Since the code only does partial reduction each outer loop, the starting values for sum1 and sum2 are at most 2×0xffff = 0x1fffe.
* The largest number that can be accumulated in sum2 without wrapping is 65537×0xffff = 0xffffffff
* Assuming the data being summed is all 0xffff, after n iterations, sum1 is (n+2)×0xffff, and sum2 is 0xffff×(n+1)×(n+4)/2.
* The number of multiples of 0xffff in sum2 after n iterations is f(n) = 2+3+...+(2+n) = (n+1)×(n+4)/2.  This evaluates to f(359) =  65340 ≤ 65537 < f(360) = 65702.
* If sum1 and sum2 started at 1×0xffff, then the limit would be g(n) = 1+2+...+(1+n) = (n+1)×(n+2)/2, and g(360) = 65341, which would be okay.
The same logic applies to the 8-bit code, where f(20) = 252 ≤ 257 < f(21) = 275.  Again, g(21) = 253 ≤ 257.
Since this seems to be solid, I have updated the article.  Comments? 71.41.210.146 (talk) 19:56, 28 March 2012 (UTC)
replies: text: It seems to me that in n iterations you sum n+1 terms, from 2 through 2+n. So I'd say that in the above calculation, you'd have to have f(n) = 3+4+...+(2+n) = n×(n+5)/2. The results are off by 2 from yours, but the inequalities still hold, so I tend to agree with the modification to the article. And thank you for pointing out your reasoning. Martin von Gagern (talk) 16:38, 21 November 2012 (UTC)
thread_title:  Optimization incorrect? 

message: Why are the two optimizations given any faster than any other? Modern compilers are much better at optimizing the code to the target platform than any user could. Even more so the "optimized" examples do many more calculations and use obscure C syntax (which does not! change the optimization).
	sum2 += sum1 += *data++;
is no more optimized than
	sum1 += *data;
	sum2 += sum1;
	++data;
and it is worse because it prevents the compiler from doing as much optimization as it could because incrementing the pointer is worse than using an index into an array.
More so the non-optimized example given should not be using 16 bit integers, it should use two 8bit integers and let the overflow occur which does an automatic modulus.
Ergzay (talk) 21:41, 21 October 2012 (UTC)
thread_title:  Optimizations that aren't optimizations 

message: I found the article very confusing, until I reached the second paragraph of the Fletcher-16 section.  Alarm bells were going off in my head.  I'd bet my experience isn't unique; I propose moving this paragraph up to where the selection of modulus is first discussed, and 255 is mentioned.--Elvey (talk) 08:43, 30 December 2012 (UTC)
thread_title:  Confusing - Choice of modulus 

message: The section "Example calculation of the Fletcher checksum" makes no sense. First of all, what type of Fletcher checksum is this? Is it Fletcher-16? If it is Flether-16, then the result does not match the result of the C code in a later section. Also, the C code makes a lot more sense to me than the English description and table presented in "Example calculation of the Fletcher checksum". I think the C code is correct, and the section "Example calculation of the Fletcher checksum" is either incorrect or is using an algorithm that is not specified. I am not sure so I will not change anything.
Fluoborate (talk) 00:42, 28 May 2013 (UTC)
thread_title:  Section "Example calculation of the Fletcher checksum" makes no sense 

message: I've tried to make it somewhat more clear.  Runxctry (talk) 20:39, 28 May 2013 (UTC)
thread_title:  Thanks for the suggestions 

message: The DJB2 string hashing algorithm (http://www.cse.yorku.ca/~oz/hash.html) is a position-dependent algorithm that can also be used as a high-performance checksum. Is it worth a mention in the article?  — Preceding unsigned comment added by Yoyoyvr (talk • contribs) 19:40, 26 April 2014 (UTC)
replies: text: I don't know about a comparison, it might be a good idea, but certainly a "See also" section with it would be a good idea.Yb2 (talk) 05:41, 13 October 2015 (UTC)

text: Hashes and checksums have different goals and properties and are not interchangeable, thus a comparison between Fletcher and DJB2 is inappropriate.  DES (talk) 15:13, 13 October 2015 (UTC)
thread_title:  comparison to DJB2? 

message: Is there any good reason that all the numbers are in hex format? It doesn't add anything that I can see, but it does add a layer of obfuscation, especially for newcomers.Yb2 (talk) 05:33, 13 October 2015 (UTC)
replies: text: If you know enough to understand the technical part of the article, you know enough to understand hexadecimal notation. DES (talk) 14:51, 13 October 2015 (UTC)
thread_title:  Hex 

message: This is the original description of the 16 bit Fletcher checksum from the referenced document RFC 1146:
"The 8-bit Fletcher Checksum Algorithm is calculated over a sequence of data octets (call them D[1] through D[N]) by maintaining 2 unsigned 1's-complement 8-bit accumulators A and B whose contents are initially zero, and performing the following loop where i ranges from 1 to N:
        A := A + D[i]
        B := B + A
It can be shown that at the end of the loop A will contain the 8-bit 1's complement sum of all octets in the datagram, and that B will contain (N)D[1] + (N-1)D[2] + ... + D[N].
The octets covered by this algorithm should be the same as those over which the standard TCP checksum calculation is performed, with the pseudoheader being D[1] through D[12] and the TCP header beginning at D[13].  Note that, for purposes of the checksum computation, the checksum field itself must be equal to zero.
At the end of the loop, the A goes in the first byte of the TCP checksum and B goes in the second byte.
Note that, unlike the OSI version of the Fletcher checksum, this checksum does not adjust the check bytes so that the receiver checksum is 0."
This is in the past the main implementation, because it's the simplest and fastest one to calculate. This is important for implementation on poor HW plattforms, where the fletcher checksum is a good alternative for a CRC, but only when no divisions are needed. So it makes no sense discussing the best modulus as this generates different checksums. The modulus is dictated by the framework requirements. It's important to mention that the modulus for simplest and original implemention for a 16 bit sum is 256 and for a 32 bit sum is 65536.
In the meantime this article has produced in many cases wrong and incompatible or partial impelemtations, as for example in the famous tool SRecord. Therefore this article is extremly harmful and damaging, as many people have lost much time in finding out where the reasion is for their problems with fletcher. Especially the examples are dangerous, because there is no explanation for this set of problems concering compatibility. Everybody reading this article is thinking your examples are generating a compatible checksum for all purposes, which is not right. This should be clarified!!!  — Preceding unsigned comment added by 91.103.115.13 (talk) 14:11, 13 July 2016 (UTC)
replies: text: The article is correct.  For reference, please read Fletcher's original paper, keeping in mind the difference between ones' complement and two's complement.  The only ambiguity in the paper (which I haven't seen resolved anywhere else) is that it does not address padding.  DES (talk) 07:59, 14 July 2016 (UTC)
replies: text:  Can anyone explain what the RFC could possibly have meant by an "unsigned 1's-complement 8-bit accumulator"? I don't know of any sense in which a storage location can be regarded as both unsigned and 1's-complement at the same time. The concepts of 1's-complement and 2's-complement refer exclusively to how negative numbers are stored and do not apply to unsigned storage. I'm pretty sure the text "1's-complement" is extraneous as Fletcher's checksum calculations never involve negative values. 98.247.224.9 (talk) 05:57, 16 October 2017 (UTC)
replies: text:  It means that all calculations are performed modulo 256 (or modulo 65,536 for the 16-bit version), so overflow and underflow are both well-defined.  DES (talk) 13:29, 17 October 2017 (UTC)
thread_title:  This Article is dangerous 

message: The section shows "(sum & 255) | (sum >> 8)" - I understand "|" as "binary or". And if I got that right, then that line is technically wrong. Instead, it should read "(sum & 255) | (sum >> 8)", as it can also be seen in the code examples, as well as empirical testing that proves that the calculated checksums are only correct if + instead of | is used. Agreed? Tempel (talk) 11:56, 30 April 2017 (UTC)
replies: text: Agreed.  Note that both versions produce an incorrect result, they're just incorrect in different ways.  Not much of an optimization if you need to exchange checksums with other implementations...  DES (talk) 12:20, 5 May 2017 (UTC)
replies: text:  In which case "(sum & 255) + (sum >> 8)" is incorrect? --Cactus26 (talk) 06:48, 27 June 2017 (UTC)

text: Unless I've had a stroke tonight, this comment must be in error too. It says that "(sum & 255) | (sum >> 8)" is wrong and should be "(sum & 255) | (sum >> 8)" (the exact same string) instead. I'm pretty sure I know what the second string was meant to be, but just in case I DID just have a stroke, I'll refrain from shooting my mouth off. 98.247.224.9 (talk) 06:06, 16 October 2017 (UTC)
replies: text:  I assume Tempel meant + as you suspect.  I'll remove the entire section.  DES (talk) 13:36, 17 October 2017 (UTC)

text:  I've replaced the bogus “optimized” code (which produces different output) with my own thoroughly tested implementation based on the Nakassis paper.  DES (talk) 16:39, 17 October 2017 (UTC)
replies: text: Please bring back the optimized code which used shifts and adds instead of the % operator.  It is useful for implementing fletcher checksums in hardware (ie FPGA), or on embedded processors without hardware division.   I strongly disagree with the removal of the hardware friendly implemention.  You could simply add a note stating that it disagrees with the % operator for the value of 0x1FFFF % 0xFFFF (which as far as I know is the only value for which it returns an incorrect result).  — Preceding unsigned comment added by 73.78.143.185 (talk) 02:04, 24 October 2017 (UTC)
replies: text:  No. It produces the wrong result. But feel free to create a page for “Checksum that sort of looks like Fletcher's but isn't, really” and put your “optimized” code there. DES (talk) 18:27, 30 October 2017 (UTC)
thread_title:  Overview for "2K - 1 optimized" should use + (plus) not | (binary or) 

message: I'm amazed, but pleased, that the example implementations and test vectors in this article haven't fallen foul of Wikipedia's prohibition on Original Research, but that's not what I'm here to talk about.
The test vectors for Fletcher-16 and Fletcher-32 would be more useful if the endian-ness of the conversion of the ASCII characters to 16- and 32-bit blocks were stated and how the given word (vector) has been padded to a whole number of blocks.
GrahamDavies (talk) 13:58, 27 April 2018 (UTC)
thread_title:  Test vectors don't specify endian-ness and padding 

message: The following Wikimedia Commons file used on this page has been nominated for speedy deletion:
* 
You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 00:06, 12 December 2019 (UTC)
thread_title:  A Commons file used on this page has been nominated for speedy deletion