Talk:Adler-32

message: Adler-16 - does it exist? does anyone use it? User:Ojw
:It's not hard to derive from the specification (you need another "base" of course, I'd suggest base 25110) but remember that the fewer bits you use the more "non-unique" and ambiguous the checksum becomes. Use in conjunction with another hash-algorithm Zero2ninE 19:20, 9 September 2007 (UTC)
thread_title: Adler-16

message: The implementation in the RFC is much easier to read. Is there a reason to have a sample implementation here that is optimized for speed rather than clarity? 194.17.253.85 13:23, 11 April 2007 (UTC)
thread_title: Optimized implementation as example?

message: The maximum value of b after the loop is actually 0xfff87 try the following program:
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<inttypes.h>
#define MOD_ADLER 65521
uint32_t
adler(uint8_t *data, size_t len) /* data: Pointer to the data to be summed; len is in bytes */
{
    uint32_t a = 1, b = 0;
    while (len)
    {
        size_t tlen = len > 5550 ? 5550 : len;
        len -= tlen;
        do
        {
            a += *data++;
            b += a;
        } while (--tlen);
        a = (a & 0xffff) + (a >> 16) * (65536-MOD_ADLER);
        b = (b & 0xffff) + (b >> 16) * (65536-MOD_ADLER);
    }
    /* It can be shown that a <= 0x1013a here, so a single subtract will do. */
    if (a >= MOD_ADLER)
            a -= MOD_ADLER;
printf("%x\n", b);
    /* It can be shown that b can reach 0xffef1 here. */
    b = (b & 0xffff) + (b >> 16) * (65536-MOD_ADLER);
    if (b >= MOD_ADLER)
            b -= MOD_ADLER;
    return (b << 16) | a;
}
int main(int argc, char **argv) {
  size_t num = 5550* 3;
  uint8_t *data = malloc(num);
  memset(data, -1, 256);
  memset(data + 256, 0, 5294);
  memset(data + 5550, -1, 5398);
  memset(data + 5550 + 5398, 20, 1);
  memset(data + 5550 + 5398 + 1, 0, 151);
  memset(data + 5550 * 2, -1, 5538);
  memset(data + 5550 * 2 + 5538, 220, 1);
  memset(data + 5550 * 2 + 5539, 0, 10);
  memset(data + 5550 * 2 + 5549, 5, 1);
  printf("%x\n", adler(data, num));
  return 0;
}
--70.48.50.99 (talk) 06:09, 20 November 2007 (UTC)
thread_title: Error in maximum computation of b

message: Preliminary tests showed that simpler code that just use % MOD_ADLER is more than 3x faster on intel core 2 duo (tested on a macbook pro).
  data length: 407076728 (388.219MB)
  adler32: 0x35863d88 (1.219478s 318.348MB/s) adler32 (incremental): 0x35863d88
  adler32_mod: 0x35863d88 (0.365084s 1063.367MB/s)
  adler32_lzo: 0x35863d88 (1.520710s 255.288MB/s)
  fletcher32: 0x2f086256 (0.531902s 729.869MB/s)
  fletcher32a: 0x2f086256 (0.278072s 1396.109MB/s)
Note, the adler32 from lzo library (noted for its speed) uses manual loop unrolling and is the slowest. 
This is an example of premature optimization.  —Preceding unsigned comment added by Vicaya (talk • contribs) 00:56, 3 January 2008 (UTC)
replies: text: I'm OK with having the simpler code example in the article, but please be careful with original research in the future. -- intgr [talk] 01:18, 3 January 2008 (UTC)
replies: text:  I may be wrong, but saying in the article that the code is optimized is itself original research. 173.23.136.211 (talk) 22:49, 4 February 2009 (UTC)
thread_title:  Optimized C code is subpar for current popular CPUs 

message: I don't believe the comment about 5550 on the article page itself is of any use, the current simple code which does a full reduction is indeed safe at the RFC listed value of 5552 (and should be changed to use this value). MaZe Pallas (talk) 11:23, 24 February 2008 (UTC)
replies: text: That is correct.  I just fixed it. Dradler (talk) 19:33, 25 August 2008 (UTC)
thread_title:  Articles comment about 5550 is superfluous 

message: Also see http://groups.google.com/group/comp.compression/browse_thread/thread/5a37a9fcd32786fd.
151.196.21.60 (talk) 10:13, 6 February 2009 (UTC)
replies: text: Usenet is not a reliable source.  Xihr  11:50, 6 February 2009 (UTC)
thread_title:  Usenet Discussion on Adler-32 by Adler 

message: If you give it the 80-character input "12345678901234567890123456789012345678901234567890123456789012345678901234567890" it gives the checksum "69010B697", which, since it has more than 32 bits, is obviously wrong.
I suggest removing the link, since it's not reliable.
Pfeilspitze (talk) 04:16, 10 May 2010 (UTC)
replies: text: You are correct, link removed. Thanks! -- intgr [talk] 08:54, 10 May 2010 (UTC)
thread_title:  Online checker has bugs 

message: This value (5552) according to the RFC is the result of solving for the inequality:
255n(n+1)/2 + (n+1)(BASE-1) <= 2^32-1
Looking at the sequence for B, I can see where the "255n(n+1)/2" comes from. It is simply the maximum value times the summation of 1 to N, but where does the "(n+1)(BASE-1)" come from? From the sequence, all that seems to be remaining for the total is N.  — Preceding unsigned comment added by 192.91.173.36 (talk) 16:15, 5 November 2013 (UTC)
thread_title:  Calculation of modulo delay count