Talk:Adler-32

Adler-16[edit]

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 251₁₀) 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)[reply]

Merge with Fletcher's checksum?[edit]

Maybe this should be merged with Fletcher's checksum? All that differs is one operation; the demonstration and discussion about performance is relevant for both. Duplicating the information would be unnecessary. Fredrik | talk 20:18, 26 Feb 2005 (UTC)

There's a larger difference in that Fletcher-32 accumulates 16 bits at a time, while Adler-32 accumulates 8 bits at a time. They are still very similar, though. User:68.205.112.194

Aren't you confusing it with Adler-16? Fredrik | talk 15:38, 27 Feb 2005 (UTC)

Example code license[edit]

Perhaps this is adequately covered elsewhere in the 'pedia, but this is the page that inspires the question for me. What's the license on the example code? I'm not entirely clear how the GFDL applies to code contained within. Is it similar to the GPL? -- Ventura 16:55, 2005 May 12 (UTC)

Wikipedia says: "When an author contributes original material to the project, the copyright over it is retained with them, but they agree to make the work available under the GFDL... all text is available under the GFDL"

Information about the license is available at its own page, or at GNU.org Ojw 17:07, 15 May 2005 (UTC)[reply]

Yes, it would be most convenient for me if the [| original author] would specifically say "this implementation public domain".

I'm going to ask at Wikipedia talk:Copyright FAQ. —The preceding unsigned comment was added by 68.0.120.35 (talk) 18:19, 27 January 2007 (UTC).[reply]

Optimized implementation as example?[edit]

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)[reply]

The example code also isn't const-correct, and unnecessarily uses uint32_t; long would suffice, as expressions involving a and b need neither modulo nor unsigned semantics. I find this clearer (as well as being compatible with C90 and C++):

#define MOD_ADLER 65521

long adler32( const unsigned char data [], size_t len )
{
    long a = 1;
    long b = 0;
    size_t i;
    
    for ( i = 0; i < len; i++ )
    {
        a = (a + data [index]) % MOD_ADLER;
        b = (b + a           ) % MOD_ADLER;
    }
    
    return b * 65536 + a;
}

24.155.229.109 (talk) 04:07, 13 May 2010 (UTC)[reply]

Error in maximum computation of b[edit]

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)[reply]

Optimized C code is subpar for current popular CPUs[edit]

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)[reply]

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)[reply]

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)[reply]

Articles comment about 5550 is superfluous[edit]

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)[reply]

That is correct. I just fixed it. Dradler (talk) 19:33, 25 August 2008 (UTC)[reply]

Usenet Discussion on Adler-32 by Adler[edit]

Also see http://groups.google.com/group/comp.compression/browse_thread/thread/5a37a9fcd32786fd.

151.196.21.60 (talk) 10:13, 6 February 2009 (UTC)JW[reply]

Usenet is not a reliable source. Xihr 11:50, 6 February 2009 (UTC)[reply]

Online checker has bugs[edit]

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)[reply]

You are correct, link removed. Thanks! -- intgr [talk] 08:54, 10 May 2010 (UTC)[reply]

Calculation of modulo delay count[edit]

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)[reply]