### Background

Adler-32 is a 32-bit checksum invented by Mark Adler in 1995 which is part of the widely used zlib library (also developed by Adler). Adler-32 is not as reliable as a 32-bit cyclic redundancy check, but – at least in software – it is much faster and easier to implement.

### Definition

Let B = [b1, ⋯, bn] be a byte array.

The Adler-32 checksum of B is defined as the result of low + 65536 × high, where:

• low := ((1 + b1 + ⋯ + bn) mod 65521)

• high := (((1 + b1) + (1 + b1 + b2) + ⋯ (1 + b1 + ⋯ + bn)) mod 65521)

Given a byte array as input, compute and return its Adler-32 checksum, abiding to the following.

• You can take the input as an array of bytes or integers, or as a string.

In both cases, only bytes corresponding to printable ASCII characters will occur in the input.

You may assume that the length of the input will satisfy 0 < length ≤ 4096.

• If you choose to print the output, you may use any positive base up to and including 256.

If you choose unary, make sure interpreter can handle up to 232 - 983056 bytes of output on a machine with 16 GiB of RAM.

• Built-ins that compute the Adler-32 checksum are forbidden.

• Standard rules apply.

### Test cases

String:     "Eagles are great!"
Byte array: [69, 97, 103, 108, 101, 115, 32, 97, 114, 101, 32, 103, 114, 101, 97, 116, 33]
Checksum:   918816254

String:     "Programming Puzzles & Code Golf"
Byte array: [80, 114, 111, 103, 114, 97, 109, 109, 105, 110, 103, 32, 80, 117, 122, 122, 108, 101, 115, 32, 38, 32, 67, 111, 100, 101, 32, 71, 111, 108, 102]
Checksum:   3133147946

String:     "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
Byte array: [126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126]
Checksum:   68095937

String:     <1040 question marks>
Byte array: <1040 copies of 63>
Checksum:   2181038080

• I will note that many of the answers here will fail with large or very large input sequences when they overflow the 32 or 64-bit integer sums, due to deferring the modulo operation until after the sums are computed. A truly compliant implementation would need to do the modulo operation at least periodically to keep the sums from overflowing. A 32-bit signed integer would overflow after only 4096 0xff's. A 64-bit signed integer would overflow after 256 MiB of 0xff's. – Mark Adler Apr 30 '16 at 19:01
• @MarkAdler Hm, fair point. Since I didn't specify that the solutions would have to work for arbitrarily long strings and I don't want to invalidate existing answers, I'll set a limit for the input's length. – Dennis Apr 30 '16 at 19:20
• @MarkAdler I don't think it matters. I'm fairly certain that overflow (signed 32-bit integers) can occur only with 4104 or more bytes of input, as the maximum value of high before the modulo is n*(n+1)/2*255+n. On top of that, the challenge restricts the input to bytes corresponding to printable ASCII characters. – Dennis Apr 30 '16 at 22:22
• We could also allow languages to overflow their numeric types, and only require that the returned result be equivalent, accounting for overflow, to the correct result. – miles Apr 30 '16 at 23:32
• @PeterCordes Yes, arrays of 32-bit ints a perfectly fine. At least in my opinion, submissions should focus on golfing the algorithm, and pay as little attention as possible to I/O. – Dennis May 1 '16 at 5:53

# Jelly, 19 17 bytes

+\,S‘S€%65521ḅ⁹²¤


Try it online!

+\,S‘S€%65521ḅ⁹²¤    Main monadic chain. Takes array as only argument.

The array is shown here as [b1 b2 ... bn].
+\                   Reduce by addition (+) while returning immediate results.
yields [b1 b1+b2 ... b1+b2+...+bn].

,                  Concatenate with...
S                 the sum of the argument.
yields [[b1 b1+b2 ... b1+b2+...+bn] b1+b2+...+bn].

‘                Increment [each].
yields [[1+b1 1+b1+b2 ... 1+b1+b2+...+bn] 1+b1+b2+...+bn].

S€              Sum each list.
yields [[1+b1+1+b1+b2+...+1+b1+b2+...+bn] 1+b1+b2+...+bn].

%65521        Modulo [each] by 65521.

ḅ⁹²¤    Convert from base    65536    to integer.
⁹                        256
²                           squared

• Better yet: ⁹²¤ – Dennis Apr 30 '16 at 6:15
• @Dennis I have outgolfed your 18-byte then. – Leaky Nun Apr 30 '16 at 6:17
• Well, you have outgolfed.. – Leaky Nun Apr 30 '16 at 6:21

# Mathematica, 46 bytes

{1,4^8}.Fold[##+{0,#&@@#}&,{1,0},#]~Mod~65521&


An anonymous function that takes an integer array and returns the Adler-32, with some improvements from miles and Martin (see comments).

miles' is also 46 bytes, but faster:

{1,4^8}.{Tr@#+1,Tr[Accumulate@#+1]}~Mod~65521&

• ...Did you just golf your own famous algorithm? – Mego Apr 30 '16 at 7:52
• Forgive me if I'm a bit star-struck. It's not everyday that you see such a big name in software engineering on our humble little site. Welcome aboard! – Mego Apr 30 '16 at 7:59
• Not all that big. – Mark Adler Apr 30 '16 at 8:12
• If you mean me, this is the first time I thought of implementing Adler-32 in Mathematica. – Mark Adler Apr 30 '16 at 8:48
• Or perhaps you've got this solution ready since you joined Code Golf, just waiting for it to be asked. "Finally!" ;-) – Antti Haapala Apr 30 '16 at 8:50

# Julia, 73 46 bytes

x->[sum(x)+1;sum(cumsum(x)+1)]%65521⋅[1;4^8]


This is an anonymous function that accepts an array and returns an integer. To call it, assign it to a variable.

We combine sum(x) + 1 and sum(cumsum(x) + 1) into an array, where x is the input array, and take each modulo 65521. We then compute the dot product with 1 and 48, which gives us (sum(x) + 1) + 4^8 * sum(cumsum(x) + 1), which is exactly the Adler-32 formula.

Try it online! (Includes all test cases)

Saved 27 bytes thanks to Sp3000 and Dennis!

• Wow, that's really clever. – cat Apr 30 '16 at 13:53
• @cat I have Sp3000 and Dennis to thank for most of the cleverness. :) – Alex A. Apr 30 '16 at 18:05

# x86-32 machine code function: 31 bytes

As a GNU C inline-asm code fragment: saves 2B 1B (just the ret insn).

## Commented source and test driver on github

The 64bit version is callable directly from C with the standard System V x86-64 ABI (using 2 dummy args to get args in the regs I want). Custom calling conventions are not uncommon for asm code, so this is a bonus feature.

32bit machine code saves 1B, because merging the high and low halves with push16/push16 => pop32 only works in 32bit mode. A 32bit function would need a custom calling convention. We shouldn't hold that against it, but calling from C needs a wrapper function.

After processing 4096 ~ (ASCII 126) bytes, high = 0x3f040000, low = 0x7e001. So high's most-significant bit isn't set yet. My code takes advantage of this, sign-extending eax into edx:eax with cdq as a way of zeroing edx.

# See the NASM source below
401120:       31 c0                   xor    eax,eax
401122:       99                      cdq
401123:       8d 7a 01                lea    edi,[rdx+0x1]
401126:       ac                      lods   al,BYTE PTR ds:[rsi]
40112b:       e2 f9                   loop   401126 <golfed_adler32_amd64.byteloop>
40112d:       66 b9 f1 ff             mov    cx,0xfff1
401131:       92                      xchg   edx,eax
401132:       99                      cdq
401133:       f7 f1                   div    ecx
401135:       52                      push   rdx
401136:       97                      xchg   edi,eax
401137:       99                      cdq
401138:       f7 f1                   div    ecx
40113a:       66 52                   push   dx      # this is the diff from last version: evil push/pop instead of shift/add
40113c:       58                      pop    rax
40113d:       66 5a                   pop    dx
40113f:       c3                      ret


0x40 - 0x20 = 32 bytes.

## Commented NASM source:

tricks:

• xchg eax, r32 is one byte; cheaper than mov. 8086 needed data in ax for a lot more stuff than >= 386, so they decided to spend a lot of opcode-space on the now-rarely-used xchg ax, r16.

• Mixing push64 and push16 for merging high and low into a single register saves reg-reg data movement instructions around two divs. The 32bit version of this trick works even better: push16 / push16 / pop32 is only 5B total, not 6.

Since we push/pop, this isn't safe for inline asm in the SysV amd64 ABI (with a red zone).

golfed_adler32_amd64_v3:   ; (int dummy, const char *buf, int dummy, uint64_t len)

;; args: len in rcx,  const char *buf in rsi
;; Without dummy args, (unsigned len, const char *buf),  mov ecx, edi is the obvious solution, costing 2 bytes

cdq                     ; edx: high=0
lea     edi, [rdx+1]    ; edi: low=1
;jrcxz  .end            ; We don't handle len=0.  unlike rep, loop only checks rcx after decrementing
.byteloop:
lodsb                   ; upper 24b of eax stays zeroed (no partial-register stall on Intel P6/SnB-family CPUs, thanks to the xor-zeroing)
add     edi, eax        ; low += zero_extend(buf[i])
add     edx, edi        ; high += low
loop   .byteloop
.end:
;; exit when ecx = 0, eax = last byte of buf
;; lodsb at this point would load the terminating 0 byte, conveniently leaving eax=0

mov     cx, 65521       ; ecx = m = adler32 magic constant.  (upper 16b of ecx is zero from the loop exit condition.  This saves 1B over mov r32,imm32)
;sub    cx, (65536 - 65521) ; the immediate is small enough to use the imm8 encoding.  No saving over mov, though, since this needs a mod/rm byte

xchg    eax, edx        ; eax = high,  edx = buf[last_byte]
cdq                     ; could be removed if we could arrange things so the loop ended with a load of the 0 byte

div     ecx             ; div instead of idiv to fault instead of returning wrong answers if high has overflowed to negative.  (-1234 % m is negative)
push    rdx             ; push high%m and 6B of zero padding

xchg    eax, edi        ; eax=low
cdq
div     ecx             ; edx = low%m

;; concatenate the two 16bit halves of the result by putting them in contiguous memory
push    dx              ; push low%m with no padding
pop     rax             ; pop  high%m << 16 | low%m   (x86 is little-endian)

pop     dx              ; add rsp, 2 to restore the stack pointer

;; outside of 16bit code, we can't justify returning the result in the dx:ax register pair
ret


I also considered using rcx as an array index, instead of having two loop counters, but adler32(s) != adler32(reverse(s)). So we couldn't use loop. Counting from -len up towards zero and using movzx r32, [rsi+rcx] just uses way too many bytes.

If we want to consider incrementing the pointer ourself, 32bit code is probably the way to go. Even the x32 ABI (32bit pointers) isn't sufficient, because inc esi is 2B on amd64, but 1B on i386. It appears hard to beat xor eax,eax / lodsb / loop: 4B total to get each element in turn zero-extended into eax. inc esi / movzx r32, byte [esi] / loop is 5B.

scas is another option for incrementing a pointer with a 1B instruction in 64bit mode. (rdi/edi instead of rsi, so we'd take the pointer arg in rdi). We can't use the flag result from scas as a loop condition, though, because we don't want to keep eax zeroed. Different register allocation could maybe save a byte after the loop.

### int[] input

The full function taking uint8_t[] is the "main" answer, because it's a more interesting challenge. Unpacking to int[] is an unreasonable thing to ask our caller to do in this language, but it does save 2B.

If we take our input as an unpacked array of 32bit integers, we can save one byte easily (use lodsd and replace xor eax,eax / cdq with just xor edx,edx).

We can save another byte by zeroing edx with lodsd/cdq, and re-arranging the loop so it loads the terminating 0 element before exiting. (We're still assuming it exists, even though this is an array of int, not a string).

; untested: I didn't modify the test driver to unpack strings for this
; xor   edx,edx
lodsd                   ; first element. only the low byte non-zero
cdq                     ; edx: high=0
lea     edi, [rdx+1]    ; edi: low=1
;jrcxz  .end            ; handle len=0?  unlike rep, loop only checks rcx after decrementing
.intloop:
add     edi, eax        ; low += buf[i]
add     edx, edi        ; high += low
lodsd                   ; load buf[i+1] for next iteration
loop   .intloop
.end:
;; exit when ecx = 0, eax = terminating 0

xchg    eax, edx
; same as the char version


I also made an untested version that uses scasd (1B version of add edi,4) and add eax, [rdi] instead of lodsd, but it's also 30 bytes. The savings from having high in eax at the end of the loop are balanced out by larger code elsewhere. It has the advantage of not depending on a terminating 0 element in the input, though, which is maybe unreasonable for an unpacked array where we're also given the length explicitly.

## C++11 test driver

See the github link. This answer was getting too big, and the test driver got more features with bigger code.

• I allowed integers instead of bytes mainly because many languages do not even have a byte type. 32-bit integers may be an unnatural choice for assembly, but code golf is about squeezing out the last byte while staying within the rules. If an "unnatural" choice leads to a lower byte count, I'd say go for it. – Dennis May 1 '16 at 7:09
• @Dennis: I understand the need for the rule for some languages. I wish there was a way for the rule to only let you use int[] if it was necessary, or saved more than 4 bytes of code or something. I have no problem presenting a solution to the adler32(int[]) problem, but I feel that the adler32(char[]) problem is more interesting, since it's the real adler32 function. It's what I really want to be golfing in asm. (And I would dearly love to save one more byte somehow, since in real life asm, 33 bytes = 48 bytes if the next function uses ALIGN 16). I guess I'll keep golfing both. – Peter Cordes May 1 '16 at 14:42
• @Dennis: also, do we need to handle the len=0 case? I save 2B by using a do{}while(--len) style of loop instead of a while(len--){}. – Peter Cordes May 1 '16 at 14:43
• When it comes to explanations, the more detailed, the better. – Dennis May 1 '16 at 16:59
• @cat: No, I don't find asm painful. I wouldn't spend my time writing Stackoverflow answers to asm / performance questions, and updating the x86 tag wiki if I did :P If you want to know why code runs slow or fast, you have to look at and understand the asm. Once you do that for a while, you start seeing when the compiler could have made faster code... and eventually you start thinking about how the compiler might compile code as you write it. Optimizing for code size instead of performance is an interesting change sometimes. – Peter Cordes May 1 '16 at 22:29

# MATL, 22 bytes

tsQwYsQsh16W15-\l8Mh*s


Input can be an array of numbers or the corresponding ASCII string.

Try it online!

### Explanation

t       % Take array or string as input. Duplicate
sQ      % Sum all its values, and add 1
wYsQs   % Swap. Cumulative sum, add 1, sum
h       % Concatenate horizontally
16W     % 2^16: gives 65536
15-     % Subtract 15: gives 65521
\       % Element-wise modulo operation
l       % Push 1
8M      % Push 65536 again
h       % Concatenate horizontally: gives array [1, 65535]
*s      % Element-wise multiplication and sum. Display


## Actually, 36 bytes

;Σu@;╗lR╜HΣuMΣk:65521@%M1#84ⁿ@q*


Try it online!

Explanation:

;Σu@;╗lR╜HΣuMΣk:65521@%M1#84ⁿ@q*
;Σu                                   sum(input)+1
@;╗lR                              push a copy of input to reg0, push range(1, len(input)+1)
╜HΣuM                       map over range: sum(head(reg0,n))+1
Σk                     sum, combine lower and upper into a list
:65521@%M          modulo each by 65521
1#84ⁿ@q*  dot product with [1,4**8]


# Java, 84 bytes

long a(int[]i){long a=1,b=0;for(int p:i)b=(b+(a=(a+p)%(p=65521)))%p;return b<<16|a;}


If Java solutions are always supposed to be complete compilable code please let me know.

### Ungolfed

long a(int[] i) {
long a = 1, b = 0;
for (int p : i) b = (b + (a = (a + p) % (p = 65521))) % p;
return b << 16 | a;
}


### Note

You will have to convert the input String to int[] (int[] is one byte shorter than byte[] or char[]).

### Output

String:     "Eagles are great!"
Byte Array: [69, 97, 103, 108, 101, 115, 32, 97, 114, 101, 32, 103, 114, 101, 97, 116, 33]
Checksum:   918816254
Expected:   918816254

String:     "Programming Puzzles & Code Golf"
Byte Array: [80, 114, 111, 103, 114, 97, 109, 109, 105, 110, 103, 32, 80, 117, 122, 122, 108, 101, 115, 32, 38, 32, 67, 111, 100, 101, 32, 71, 111, 108, 102]
Checksum:   3133147946
Expected:   3133147946

String:     "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
Byte Array: [126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126, 126]
Checksum:   68095937
Expected:   68095937

String:     "?????????...?"
Byte Array: [63, 63, 63, 63, 63, 63, 63, 63, 63, ...,63]
Checksum:   2181038080
Expected:   2181038080

• Nice answer, and welcome to the site! Also, solutions that are not complete and compilable are fine unless the challenge explicitly states that it should be a full program. This is a full function, so it counts. – James Apr 30 '16 at 14:53

# Piet, 120 Codels With codelsize 20: ### Notes / How does it work?

• Since it is not possible to use an array or string as input, this program works by taking a series of integers (representing ascii characters) as inputs. I thought about using character inputs at first but struggled to find a nice solution for termination, so now it terminates when any numer smaller than 1 is entered. It was originally only negative values for termination, but I had to change the initialization after writing the program, so now I can't fit the required 2, only a 1 (26/45 on the trace image). This doesn't matter though because as per the challenge rules, only printable ascii characters are allowed.

• Struggled for a long time with reentering the loop, though I found quite the elegant solution in the end. No pointer or switch operations, only the interpreter running into walls until it transitions back into the green codel to read the input (43->44 on the trace images).

• Loop termination is achived by first duplicating the input, adding 1 and then checking if it is bigger than 1. If it is, the codel chooser is triggered and execution continues on the lower path. If it is not, the program contines left (Bright yellow codels, 31/50 on the trace images).

• The supported input size is interpreter implementation dependent, though it would be possible to support an arbitrarily large input with the right interpreter (Say, for example, a Java interpreter that uses BigInteger as internal values)

• Just saw that the setup includes one unnecessary DUP and CC (7->8->9 in the trace images). No idea how that happened. This is effectively a noop though, it toggles the codel chooser 16 times which results in no change.

### Npiet trace images

Setup and first loop: Loop termination, output and exit: ### Outputs

Forgive me if I only include one output, it just takes a long time to input :^)

String: "Eagles are great!"

? 69
? 97
? 103
? 108
? 101
? 115
? 32
? 97
? 114
? 101
? 32
? 103
? 114
? 101
? 97
? 116
? 33
? -1
918816254


### Npiet trace for [65, -1]

trace: step 0  (0,0/r,l nR -> 1,0/r,l dR):
action: push, value 4
trace: stack (1 values): 4

trace: step 1  (1,0/r,l dR -> 2,0/r,l dB):
action: duplicate
trace: stack (2 values): 4 4

trace: step 2  (2,0/r,l dB -> 3,0/r,l nM):
action: multiply
trace: stack (1 values): 16

trace: step 3  (3,0/r,l nM -> 4,0/r,l nC):
action: duplicate
trace: stack (2 values): 16 16

trace: step 4  (4,0/r,l nC -> 5,0/r,l nY):
action: duplicate
trace: stack (3 values): 16 16 16

trace: step 5  (5,0/r,l nY -> 6,0/r,l nM):
action: duplicate
trace: stack (4 values): 16 16 16 16

trace: step 6  (6,0/r,l nM -> 7,0/r,l nC):
action: duplicate
trace: stack (5 values): 16 16 16 16 16

trace: step 7  (7,0/r,l nC -> 8,0/r,l nY):
action: duplicate
trace: stack (6 values): 16 16 16 16 16 16

trace: step 8  (8,0/r,l nY -> 9,0/r,l lB):
action: switch
trace: stack (5 values): 16 16 16 16 16
trace: stack (5 values): 16 16 16 16 16

trace: step 9  (9,0/r,l lB -> 10,0/r,l dM):
action: multiply
trace: stack (4 values): 256 16 16 16

trace: step 10  (10,0/r,l dM -> 11,0/r,l nR):
action: multiply
trace: stack (3 values): 4096 16 16

trace: step 11  (11,0/r,l nR -> 12,0/r,l lY):
action: multiply
trace: stack (2 values): 65536 16

trace: step 12  (12,0/r,l lY -> 13,0/r,l lM):
action: duplicate
trace: stack (3 values): 65536 65536 16

trace: step 13  (13,0/r,l lM -> 14,0/r,l nM):
action: push, value 3
trace: stack (4 values): 3 65536 65536 16

trace: step 14  (14,0/r,l nM -> 15,0/r,l dM):
action: push, value 2
trace: stack (5 values): 2 3 65536 65536 16

trace: step 15  (15,0/r,l dM -> 16,0/r,l lC):
action: roll
trace: stack (3 values): 16 65536 65536

trace: step 16  (16,0/r,l lC -> 17,0/r,l nB):
action: sub
trace: stack (2 values): 65520 65536

trace: step 17  (17,0/r,l nB -> 18,0/r,l dB):
action: push, value 1
trace: stack (3 values): 1 65520 65536

trace: step 18  (18,0/r,l dB -> 19,0/r,l dM):
trace: stack (2 values): 65521 65536

trace: step 19  (19,0/r,l dM -> 19,1/d,r dC):
action: duplicate
trace: stack (3 values): 65521 65521 65536

trace: step 20  (19,1/d,r dC -> 18,1/l,l lC):
action: push, value 1
trace: stack (4 values): 1 65521 65521 65536

trace: step 21  (18,1/l,l lC -> 17,1/l,l nC):
action: push, value 1
trace: stack (5 values): 1 1 65521 65521 65536

trace: step 22  (17,1/l,l nC -> 16,1/l,l dB):
action: sub
trace: stack (4 values): 0 65521 65521 65536

trace: step 23  (16,1/l,l dB -> 15,1/l,l lB):
action: push, value 1
trace: stack (5 values): 1 0 65521 65521 65536

trace: step 24  (15,1/l,l lB -> 13,2/l,l dG):
action: in(number)
? 65
trace: stack (6 values): 65 1 0 65521 65521 65536

trace: step 25  (13,2/l,l dG -> 12,2/l,l dR):
action: duplicate
trace: stack (7 values): 65 65 1 0 65521 65521 65536

trace: step 26  (12,2/l,l dR -> 11,2/l,l lR):
action: push, value 1
trace: stack (8 values): 1 65 65 1 0 65521 65521 65536

trace: step 27  (11,2/l,l lR -> 10,2/l,l lY):
trace: stack (7 values): 66 65 1 0 65521 65521 65536

trace: step 28  (10,2/l,l lY -> 9,2/l,l nY):
action: push, value 1
trace: stack (8 values): 1 66 65 1 0 65521 65521 65536

trace: step 29  (9,2/l,l nY -> 8,1/l,r nB):
action: greater
trace: stack (7 values): 1 65 1 0 65521 65521 65536

trace: step 30  (8,1/l,r nB -> 7,1/l,r lY):
action: switch
trace: stack (6 values): 65 1 0 65521 65521 65536
trace: stack (6 values): 65 1 0 65521 65521 65536

trace: step 31  (7,1/l,l lY -> 6,2/l,l nY):
action: push, value 2
trace: stack (7 values): 2 65 1 0 65521 65521 65536

trace: step 32  (6,2/l,l nY -> 5,3/l,l dB):
action: pointer
trace: stack (6 values): 65 1 0 65521 65521 65536

trace: step 33  (5,3/r,l dB -> 7,4/r,l dM):
trace: stack (5 values): 66 0 65521 65521 65536

trace: step 34  (7,4/r,l dM -> 8,4/r,l dC):
action: duplicate
trace: stack (6 values): 66 66 0 65521 65521 65536

trace: step 35  (8,4/r,l dC -> 9,3/r,l lC):
action: push, value 3
trace: stack (7 values): 3 66 66 0 65521 65521 65536

trace: step 36  (9,3/r,l lC -> 10,3/r,l nC):
action: push, value 2
trace: stack (8 values): 2 3 66 66 0 65521 65521 65536

trace: step 37  (10,3/r,l nC -> 11,3/r,l dY):
action: roll
trace: stack (6 values): 0 66 66 65521 65521 65536

trace: step 38  (11,3/r,l dY -> 12,3/r,l dG):
trace: stack (5 values): 66 66 65521 65521 65536

trace: step 39  (12,3/r,l dG -> 13,3/r,l lG):
action: push, value 2
trace: stack (6 values): 2 66 66 65521 65521 65536

trace: step 40  (13,3/r,l lG -> 14,3/r,l nG):
action: push, value 1
trace: stack (7 values): 1 2 66 66 65521 65521 65536

trace: step 41  (14,3/r,l nG -> 15,3/r,l dR):
action: roll
trace: stack (5 values): 66 66 65521 65521 65536
trace: white cell(s) crossed - continuing with no command at 17,3...

trace: step 42  (15,3/r,l dR -> 17,3/r,l lB):

trace: step 43  (17,3/r,l lB -> 13,2/l,l dG):
action: in(number)
? -1
trace: stack (6 values): -1 66 66 65521 65521 65536

trace: step 44  (13,2/l,l dG -> 12,2/l,l dR):
action: duplicate
trace: stack (7 values): -1 -1 66 66 65521 65521 65536

trace: step 45  (12,2/l,l dR -> 11,2/l,l lR):
action: push, value 1
trace: stack (8 values): 1 -1 -1 66 66 65521 65521 65536

trace: step 46  (11,2/l,l lR -> 10,2/l,l lY):
trace: stack (7 values): 0 -1 66 66 65521 65521 65536

trace: step 47  (10,2/l,l lY -> 9,2/l,l nY):
action: push, value 1
trace: stack (8 values): 1 0 -1 66 66 65521 65521 65536

trace: step 48  (9,2/l,l nY -> 8,1/l,r nB):
action: greater
trace: stack (7 values): 0 -1 66 66 65521 65521 65536

trace: step 49  (8,1/l,r nB -> 7,1/l,r lY):
action: switch
trace: stack (6 values): -1 66 66 65521 65521 65536
trace: stack (6 values): -1 66 66 65521 65521 65536

trace: step 50  (7,1/l,r lY -> 6,1/l,r dY):
action: pop
trace: stack (5 values): 66 66 65521 65521 65536

trace: step 51  (6,1/l,r dY -> 4,1/l,r lY):
action: push, value 3
trace: stack (6 values): 3 66 66 65521 65521 65536

trace: step 52  (4,1/l,r lY -> 3,1/l,r nY):
action: push, value 2
trace: stack (7 values): 2 3 66 66 65521 65521 65536

trace: step 53  (3,1/l,r nY -> 2,1/l,r nM):
action: duplicate
trace: stack (8 values): 2 2 3 66 66 65521 65521 65536

trace: step 54  (2,1/l,r nM -> 1,1/l,r dG):
action: pointer
trace: stack (7 values): 2 3 66 66 65521 65521 65536

trace: step 55  (1,1/r,r dG -> 2,2/r,r lR):
action: roll
trace: stack (5 values): 65521 66 66 65521 65536

trace: step 56  (2,2/r,r lR -> 2,3/d,l nR):
action: push, value 1
trace: stack (6 values): 1 65521 66 66 65521 65536

trace: step 57  (2,3/d,l nR -> 2,4/d,l lC):
action: switch
trace: stack (5 values): 65521 66 66 65521 65536
trace: stack (5 values): 65521 66 66 65521 65536

trace: step 58  (2,4/d,r lC -> 2,5/d,r nM):
action: mod
trace: stack (4 values): 66 66 65521 65536

trace: step 59  (2,5/d,r nM -> 4,5/r,r dM):
action: push, value 3
trace: stack (5 values): 3 66 66 65521 65536

trace: step 60  (4,5/r,r dM -> 6,5/r,r lM):
action: push, value 2
trace: stack (6 values): 2 3 66 66 65521 65536

trace: step 61  (6,5/r,r lM -> 7,5/r,r nC):
action: roll
trace: stack (4 values): 65521 66 66 65536

trace: step 62  (7,5/r,r nC -> 8,5/r,r dM):
action: mod
trace: stack (3 values): 66 66 65536

trace: step 63  (8,5/r,r dM -> 11,5/r,r lM):
action: push, value 3
trace: stack (4 values): 3 66 66 65536

trace: step 64  (11,5/r,r lM -> 12,5/r,r nM):
action: push, value 1
trace: stack (5 values): 1 3 66 66 65536

trace: step 65  (12,5/r,r nM -> 13,5/r,r dC):
action: roll
trace: stack (3 values): 66 65536 66

trace: step 66  (13,5/r,r dC -> 14,5/r,r nB):
action: multiply
trace: stack (2 values): 4325376 66

trace: step 67  (14,5/r,r nB -> 15,5/r,r nM):
trace: stack (1 values): 4325442

trace: step 68  (15,5/r,r nM -> 16,5/r,r dB):
action: out(number)
4325442
trace: stack is empty
trace: white cell(s) crossed - continuing with no command at 19,5...

trace: step 69  (16,5/r,r dB -> 19,5/r,r nM):


# C89, 70 bytes

h,l,m=65521;A(char*B){h=0;l=1;while(*B)h+=l+=*B++;return h%m<<16|l%m;}


To test (compile with gcc -std=c89 -lm golf.c):

#include <stdio.h>
int main(int argc, char** argv) {
printf("%u\n", A("Eagles are great!"));
printf("%u\n", A("Programming Puzzles & Code Golf"));
printf("%u\n", A("~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"));
return 0;
}

• Is that how the zlib source looks? Hm... – cat Apr 30 '16 at 12:09
• This implementation made a nice starting point for my x86 asm version. – Peter Cordes May 1 '16 at 5:08
• Can save 1 byte using for instead of while: for(h=0,l=1;*B;)h+=l+=*B++; – ninjalj Nov 1 '16 at 9:43

## Labyrinth, 373632 31 bytes

}?"{655:}21:}%=}){%{{36*+!
:++)


Try it online!

Input as a list of integers. The program terminates with an error (whose error message goes to STDERR).

### Explanation

Labyrinth primer:

• Labyrinth has two stacks of arbitrary-precision integers, main and aux(iliary), which are initially filled with an (implicit) infinite amount of zeros.
• The source code resembles a maze, where the instruction pointer (IP) follows corridors when it can (even around corners). The code starts at the first valid character in reading order, i.e. in the top left corner in this case. When the IP comes to any form of junction (i.e. several adjacent cells in addition to the one it came from), it will pick a direction based on the top of the main stack. The basic rules are: turn left when negative, keep going ahead when zero, turn right when positive. And when one of these is not possible because there's a wall, then the IP will take the opposite direction. The IP also turns around when hitting dead ends.
• Digits are processed by multiplying the top of the main stack by 10 and then adding the digit. To start a new number, you can push a zero with _.

Although the code starts with a 4x2 "room", that is actually two separate two-by-two loops squeezed together. The IP just happens to stick to one loop at a time due to the stack values.

So the code starts with a 2x2 (clockwise) loop which reads input while computing prefix sums:

}   Move last prefix sum over to aux.
?   Read an integer from STDIN or push 0 on EOF, which exits the loop.
+   Add current value to prefix sum.
:   Duplicate this prefix sum.


Now we've got all the prefix sums on the aux stack, as well as a copy of the sum over all values and the 0 from EOF on main. With that, we enter another 2x2 (clockwise) loop which sums all the prefix sums to compute HIGH.

"   No-op. Does nothing.
{   Pull one prefix sum over from aux. When we're done, this fetches a 0,
which exits the loop.
)   Increment prefix sum.


The main stack now has LOW - 1 and HIGH and zero, except we haven't taken the modulo yet. The remainder of the code is completely linear:

655      Turn the zero into 655.
:}       Make a copy and shift it over to aux.
21       Turn the copy on main into 65521.
:}       Make a copy and shift it over to aux.
%        Take HIGH mod 65521.
=        Swap HIGH with the other copy of 65521 on aux.
}){      Move 65521 back to aux, increment LOW-1 to LOW,
move 65521 back to main.
%        Take LOW mod 65521.
{        Move HIGH back to main.
{        Move the other copy of 655 back to main.
36       Turn it into 65536.
*        Multiply HIGH by that.
!        Print it.


The IP now hits a dead end and turns around. The + and * are essentially no-ops, due to the zeros at the stack bottom. The 36 now turns the top of main into 63, but the two {{ pull two zeros from aux on top of it. Then % tries to divide by zero which terminates the program.

Note that Labyrinth uses arbitrary-precision integers so deferring the modulo until the end of the sum won't cause problems with integer overflow.

## Python 2, 60 58 bytes

H=h=65521
l=1
for n in input():l+=n;h+=l
print h%H<<16|l%H


A pretty straightforward approach. This is a full program which takes a list of integers via STDIN, e.g. [72, 105, 33].

(Thanks to @xnor for the amazing aliasing/initialisation tip)

• You can do H=h=65521 to initialize h while aliasing 65521. – xnor May 2 '16 at 5:32

# J, 30 bytes

+/(+65536&*)&(65521|+/)&:>:+/\


This could probably be condensed more with a different train.

## Usage

Here x $y creates a list with x copies of y.  f =: +/(+65536&*)&(65521|+/)&:>:+/\ f 69 97 103 108 101 115 32 97 114 101 32 103 114 101 97 116 33 918816254 f 80 114 111 103 114 97 109 109 105 110 103 32 80 117 122 122 108 101 115 32 38 32 67 111 100 101 32 71 111 108 102 3133147946 f (32$ 126)
68095937
f (1040 $63) 2181038080 f (4096$ 255)
2170679522


## Explanation

+/(+65536&*)&(65521|+/)&:>:+/\
f (           g           ) h     Monad train (f g h) y = (f y) g (h y)
+/                                Sum the input list
+/\    Sum each prefix of the input, forms a list
x     f   &   g   &:   h    y     Composed verbs, makes (g (h x)) f (g (h y))
>:       Increment the sum and increment each prefix sum
(m f g) y          Hook, makes m f (g y)
+/            Sum the prefix sums
65521|              Take the sum and prefix total mod 65521
(f g) y                       Hook again
65536&*                       Multiply the prefix total by 65536
This is a bonded verb, it will only multiply
using a fixed value now
+                              Add the sum and scaled prefix total


# Octave, 52 50 bytes

Saved 2 bytes thanks to @LuisMendo

@(B)mod([sum(S=cumsum(B)+1),S(end)],65521)*[4^8;1]


Takes an array of integers as input.

low is taken from the last element of high (before summing) rather than calculating the sum explicitly, saving a grand total of... 1 byte!

Sample run on ideone.

• @LuisMendo Ooh, I forgot about +B. I guess the input spec does say you can take integers, so maybe I'll just do that. – beaker May 1 '16 at 2:16

## CJam, 30 29 bytes

q~{1$+}*]:)_W>]1fb65521f%2G#b  Input as a list of integers. Test it here. ### Explanation q~ e# Read and evaluate input. { e# Fold this block over the list, computing prefix sums. 1$+    e#   Copy the last prefix and add the current element.
}*
]        e# Wrap the prefix sums in an array.
:)       e# Increment each. This will sum to HIGH.
_W>      e# Copy the list and truncate to only the last element, i.e.
e# the sum of the entire input plus 1. This is LOW.
]        e# Wrap both of those lists in an array.
1fb      e# Sum each, by treating it as base 1 digits.
65521f%  e# Take each modulo 65521.
2G#b     e# Treat the list as base 65536 digits, computing 65536*HIGH + LOW.


# Perl 6, 60 bytes

{(.sum+1)%65521+65536*((sum(1,*+.shift...->{!$_})-1)%65521)}  ### Explanation: { #$_ is the implicit parameter for this lambda because this block doesn't have
# an explicit parameter, and @_ isn't seen inside of it.
# ( @_ takes precedence over $_ when it is seen by the compiler ) # .sum is short for$_.sum
( .sum + 1 ) % 65521 + 65536
*
(
(
sum(

# generate a sequence:

1,         # starting with 1
* + .shift # lambda that adds previous result (*) with $_.shift ... # generate until: -> { !$_ } # $_ is empty # ^ I used a pointy block with zero parameters # so that the block doesn't have an implicit parameter # like the surrounding block # this is so that$_ refers to the outer $_ ) - 1 # remove starting value ) % 65521 ) }  ### Test: #! /usr/bin/env perl6 use v6.c; use Test; # give the lambda a name my &Adler32 = {(.sum+1)%65521+65536*((sum(1,*+.shift...->{!$_})-1)%65521)}

my @tests = (
(  918816254,  'Eagles are great!'),
( 3133147946,  'Programming Puzzles & Code Golf'),
(   68095937,  '~' x 32,     "'~' x 32"),
( 2181038080,  63 xx 1040,   "'?' x 1040"),
);

plan +@tests;

for @tests -> ($checksum,$input, $gist? ) { my @array := do given$input {
when Str { .encode.Array }
default { .Array }
}

is Adler32(@array), $checksum,$gist // input.perl }  1..4 ok 1 - "Eagles are great!" ok 2 - "Programming Puzzles \& Code Golf" ok 3 - '~' x 32 ok 4 - '?' x 1040  # Python 3 (79 bytes) Based on R. Kap's solution. lambda w,E=65521:(1+sum(w))%E+(sum(1+sum(w[:i+1])for i in range(len(w)))%E<<16)  I replaced the multiplication by a shift and removed a pair of brackets. Because I can't post comments I made a new answer. # Scheme, 195 bytes (define(a b)(+(let L((b b)(s 1))(if(=(length b)0)s(L(cdr b)(modulo(+ s(car b))65521))))(* 65536(let H((b b)(s 1)(t 0))(if(=(length b)0)t(let((S(+ s(car b))))(H(cdr b)S(modulo(+ t S)65521))))))))  If it weren't for all those parentheses... ## Haskell, 54 50 bytes m=(mod65521).sum g x=m(-1:scanl(+)1x)*4^8+m(1:x)  Usage example: g [69,97,103,108,101,115,32,97,114,101,32,103,114,101,97,116,33]-> 918816254. scanl includes the starting value (-> 1) in the list (-> [1,1+b1,1+b1+b2,..]), so the sum is off by 1, which is fixed by prepending -1 to the list before summing. Edit: Thanks @xnor for 4 bytes. • It looks like you can extract out the summing into m: m=(mod65521).sum g x=m(-1:scanl(+)1x)*4^8+m(1:x). There's probably a better way to fix the sums than prepending. – xnor May 1 '16 at 0:52 ## JavaScript (ES7), 52 50 bytes a=>a.map(b=>h+=l+=b,h=0,l=1)&&l%65521+h%65521*4**8  ES6 takes 51 bytes (replace 4**8 with 65536). If you want a string version, then for 69 bytes: s=>[...s].map(c=>h+=l+=c.charCodeAt(),h=0,l=1)&&l%65521+h%65521*65536  Edit: Saved 2 bytes thanks to @user81655. # ARM Thumb-2 function accepting uint8_t[]: 40 bytes (36B for non-standard ABI and int[]) Features: non-deferred modulo, so arbitrary-size inputs are fine. Doesn't actually use the division instruction, so it's not slow. (err, at least not for that reason :P) Savings from following less strict rules: • -2B if we don't have to save registers before using them. • -2B for requiring the caller to unpack bytes into a uint32_t[] array. So, best-case is 36B. // uint8_t *buf in r0, uint32_t len in r1 00000000 <adler32arm_golf2>: 0: b570 push {r4, r5, r6, lr} // 2: 2201 movs r2, #1 // low 4: 2300 movs r3, #0 // high 6: f64f 75f1 movw r5, #65521 ; 0xfff1 = m 0000000a <adler32arm_golf2.byteloop>: a: f810 4b01 ldrb.w r4, [r0], #1 // post-increment byte-load e: 4422 add r2, r4 // low += *B 10: 4413 add r3, r2 // high += low 12: 42aa cmp r2, r5 // subtract if needed instead of deferred modulo 14: bf28 it cs 16: 1b52 subcs r2, r2, r5 18: 42ab cmp r3, r5 1a: bf28 it cs // Predication in thumb mode is still possible, but takes a separate instruction 1c: 1b5b subcs r3, r3, r5 1e: 3901 subs r1, #1 // while(--len) 20: d1f3 bne.n a <.byteloop2> 22: eac2 4003 pkhbt r0, r2, r3, lsl #16 // other options are the same size: ORR or ADD. 26: bd70 pop {r4, r5, r6, pc} // ARM can return by popping the return address (from lr) into the pc; nifty 00000028 <adler32arm_end_golf2>:  0x28 = 40 bytes ## Notes: Instead of log%m at the end, we do if(low>=m) low-=m inside the loop. If we do low before high, we know that neither can possibly exceed 2*m, so modulo is just a matter of subtracting or not. A cmp and predicated sub is only 6B in Thumb2 mode. The standard idiom for % is 8B in Thumb2 mode: UDIV R2, R0, R1 // R2 <- R0 / R1 MLS R0, R1, R2, R0 // R0 <- R0 - (R1 * R2 )  The implicit-length adler(char *) version is the same code-size as the explicit length adler(uint8_t[], uint32_t len). We can set flags for the loop-exit condition with a single 2B instruction either way. The implicit-length version has the advantage of working correctly with the empty string, instead of trying to loop 2^32 times. ## assemble / compile with: arm-linux-gnueabi-as --gen-debug -mimplicit-it=always -mfloat-abi=soft -mthumb adler32-arm.S  or arm-linux-gnueabi-g++ -Wa,-mimplicit-it=always -g -static -std=gnu++14 -Wall -Wextra -Os -march=armv6t2 -mthumb -mfloat-abi=soft test-adler32.cpp -fverbose-asm adler32-arm.S -o test-adler32 qemu-arm ./test-adler32  Without -static, the process running under qemu-arm didn't find it's dynamic linker. (And yes, I install an ARM cross-devel setup just for this answer, because I thought my predicated-subtract idea was neat.) On amd64 Ubuntu, install gcc-arm-linux-gnueabi, g++-arm-linux-gnueabi. I found gdb-arm-none-eabi sort of barely worked connecting to qemu-arm -g port. ## Commented source: // There's no directive to enable implicit-it=always // gcc uses compiler uses these in its output .syntax unified .arch armv8-a .fpu softvfp .thumb @ aka .code 16 .p2align 4 .globl adler32arm_golf @ put this label on the one we want to test .thumb_func adler32arm_golf: adler32arm_golf2: @ (uint8_t buf[], uint32_t len) @ r0 = buf @ r1 = len push {r4, r5, r6, lr} @ even number of regs keeps the stack aligned. Good style? since there's no code-size saving movs r2, #1 @ r2: low movs r3, #0 @ r3: high @ r4 = tmp for loading bytes movw r5, #65521 @ r5: modulo constant adler32arm_golf2.byteloop2: ldrb r4, [r0], #1 @ *(buf++) post-increment addressing. 4B encoding @ldrb r4, [r0, r1] @ 2B encoding, but unless we make the caller pass us buf+len and -len, it needs extra code somewhere else @ldmia r0!, {r4} @ int[] version: r4 = [r0]; r0+=4; post-increment addressing. 2B encoding. add r2, r2, r4 @ low += tmp add r3, r3, r2 @ high += low; // I think it's safe to do this before the modulo range-reduction for low, but it would certainly work to put it after. cmp r2, r5 subhs r2, r5 @ if(low>=m) low-=m; @ 6B total for %. predicated insns require an IT instruction in thumb2 cmp r3, r5 subhs r3, r5 @ if(high>=m) high-=m; // equivalent to high %= m. @sub r1, #1 @ 4B encoding: sub.w to not set flags with immediate subs r1, #1 @ len-- and set flags. 2B encoding @cmp r4, #0 @ null-termination check. 2B encoding bne adler32arm_golf2.byteloop2 @ udiv r0, r2, r5 @ normal way to do one of the modulos @ mls r2, r5, r0, r2 @ r2 = low % m. 8B total for % PKHBT r0, r2, r3, lsl #16 @ 4B r0 = [ high%m <<16 | low%m ] @orr r0, r0, r4, lsl #16 @ 4B @orr r0, r0, r4 @ 4B @add r0, r2, r3, lsl #16 @ 4B @add r0, r0, r4 @ 2B pop {r4, r5, r6, pc} @ ARM can return by popping the return address (saved from lr) into pc. Nifty adler32arm_end_golf2:  test-adler32.cpp has the same test-cases and main() as for my x86-64 answer, but starts this way: #include <stdint.h> uint32_t adler32_simple(const uint8_t *B) { const uint32_t m=65521; uint32_t h=0, l=1; do { l += *B++; // Borrowed from orlp's answer, as a simple reference implementation h += l; l %= m; h %= m; // with non-deferred modulo if this is uncommented } while(*B); return h%m<<16|l%m; } #include <stdio.h> //#include <zlib.h> #include <string.h> #include <assert.h> #include <string> // useful for the memset-style constructors that repeat a character n times extern "C" { unsigned golfed_adler32_amd64(int /*dummy1*/, const char *buf, int /*dummy2*/, unsigned len); unsigned adler32arm_golf(const char *buf, unsigned len); } #ifdef __amd64__ #define golfed_adler32(buf, len) golfed_adler32_amd64(1234, buf, 1234, len) #elif __arm__ #define golfed_adler32(buf, len) adler32arm_golf(buf, len) #else #error "no architecture" #endif static void test_adler(const char *str) { unsigned len = strlen(str); // unsigned zlib = zlib_adler(len, str); unsigned reference = adler32_simple((const uint8_t*)str); unsigned golfed = golfed_adler32(str, len); printf("%s: c:%u asm:%u\n", str, reference, golfed); assert(reference == golfed); } // main() to call test_adler() unchanged from my amd64 answer, except that the comments about length limits don't apply  # x86 16bit machine code function: 32 bytes using a custom calling convention Args in registers, and not preserving regs other than bp (and sp). In 16bit code, we return a 32bit value in the dx:ax register pair. This means we don't have to spend any instructions merging high and low into eax. (This would save bytes in 32 and 64 bit code, too, but we can only justify offloading this work to the caller in 16bit code.) ### Commented source and test driver on github (for x86 16, 32, and 64bit, and ARM). ### const char *buf in SI, uint16_t len in CX ## returns in dx:ax ## also clobbers bx and di. 00000100 <adler32_x16_v6>: 100: 31 c0 xor ax,ax # set up for lods 102: 99 cwd # dx= high=0 103: bf 01 00 mov di,0x1 # di= low=0 106: bb f1 ff mov bx,0xfff1 # bx= m 00000109 <adler32_x16_v6.byteloop>: 109: ac lods 10a: 01 c7 add di,ax # low+=buf[i]. modulo-reduce on carry, or on low>=m 10c: 72 04 jc 112 <adler32_x16_v6.carry_low> 10e: 39 df cmp di,bx 110: 72 02 jb 114 <adler32_x16_v6.low_mod_m_done> 00000112 <adler32_x16_v6.carry_low>: 112: 29 df sub di,bx 00000114 <adler32_x16_v6.low_mod_m_done>: 114: 01 fa add dx,di # high+=low 116: 0f 92 d0 setb al # store the carry to set up a 32bit dividend. 119: 92 xchg dx,ax 11a: f7 f3 div bx # high (including carry) %= m, in dx. ax=0 or 1 (so we're set for lods next iteration) 11c: e2 eb loop 109 <adler32_x16_v6.byteloop> 11e: 97 xchg di,ax # 11f: c3 ret 00000120 <adler32_x16_v6_end>:  0x120 - 0x100 = 32 bytes Tested by assembling the same code for 32bit mode, so I can call it (with a wrapper function) from C compiled with -m32. For me, 16bit mode is somewhat interesting, DOS system calls are not. All the instructions have explicit operands, except loop and lodsb, so assembling for 32bit mode uses operand-size prefixes. Same instruction, different encoding. But lodsb in 32bit mode will use [esi], so this for-testing version works with 32bit pointers (because we don't do any address-math or pointer increment/compare). No mismatches. My test harness prints a message if there is a mismatch.  yasm -felf32 -Worphan-labels -gdwarf2 adler32-x86-16.asm -o adler32-x86-16+32.o &&
Eagles are great! (len=17): zlib:0x36c405fe  c:0x36c405fe golfed:0x36c405fe
Programming Puzzles & Code Golf (len=31): zlib:0xbac00b2a  c:0xbac00b2a golfed:0xbac00b2a
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (len=32): zlib:0x040f0fc1  c:0x040f0fc1 golfed:0x040f0fc1
?????????????????????????????????????????????????? (len=1040): zlib:0x82000000  c:0x82000000 golfed:0x82000000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (len=4096): zlib:0xb169e06a  c:0xb169e06a golfed:0xb169e06a
(0xFF repeating) (len=4096): zlib:0x8161f0e2  c:0x8161f0e2 golfed:0x8161f0e2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (len=5837): zlib:0x5d2a398c  c:0x5d2a398c golfed:0x5d2a398c
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (len=5838): zlib:0x97343a0a  c:0x97343a0a golfed:0x97343a0a
(0xFF repeating) (len=9999): zlib:0xcae9ea2c  c:0xcae9ea2c golfed:0xcae9ea2c
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (len=65535): zlib:0x33bc06e5  c:0x33bc06e5 golfed:0x33bc06e5


With 16bit registers, we can't defer modulo reduction until after the loop. There's an interesting difference between 16bit and other operand-sizes: m = 65521 (0xFFF1) is more than half 65536. Subtracting m on carry keeps the value below 2*m, even if high=0xFFF0 + 0xFFF0. After the loop, a compare-and-subtract will do the trick, instead of a div.

I came up with a novel technique for modulo-reducing a register after an add that can produce a carry. Instead of zeroing the upper half of the input for div, use setc dl to create a 32bit dividend holding the non-truncated add result (dh is already zeroed). (div does 32b / 16b => 16bit division.)

setcc (3 bytes) was introduced with 386. To run this on 286 or earlier, the best I've come up with uses the undocumented salc instruction (set AL from carry). It's a one-byte opcode for sbb al,al, so we could use salc / neg al before doing the xchg ax, dx (which we need anyway). Without salc, there's a 4B sequence: sbb dx,dx / neg dx. We can't use 3B sbb dx,dx / inc dx, because that would emulate setnc rather than setc.

I tried using 32bit operand-size instead of handling carry, but it's not just the add instructions that need an operand-size prefix. Instructions setting up the constants and so on also need operand-size prefixes, so it ended up not being the smallest.

# Pyth, 2524 23 bytes

1 byte thanks to @Jakube.

1 more byte thanks to @Jakube.

i%R65521sMeBhMsM._Q^4 8


Try it online!

Translation of my answer in Jelly.

# Perl 5, 43 bytes

42 bytes, plus 1 for -aE instead of -e

Input is as decimal integers, space-separated.

map$h+=$.+=$_,@F;say$.%65521+$h%65521*4**8  A tip of my hat to Sp3000, from whom I took ideas for this answer. How it works: 1. Because of -a, $. starts at 1 and @F is the input array. $h starts at 0. $_ is used by map as a placeholder for each element of an array.
2. map$h+=$.+=$_,@F means that for each element in @F we add that element to $. and then add $. to $h.
3. Then we do the modular arithmetic $.%65521+$h%65521*4**8 (that is, ($. % 65521) + ( ($h % 65521) * (4**8) ) and say (print) the result.

# Factor, 112109 103 bytes

Now, this is a literal translation of the algorithm in the question... now that I actually made it, y'know, correct.

[ [ sum 1 + ] [ [ dup length [1,b] reverse v. ] [ length ] bi + ] bi [ 65521 mod ] bi@ 16 shift bitor ]


Ungolfed:

: adler-32 ( seq -- n )
[ sum 1 + ]
[
[ dup length [1,b] reverse v. ]
[ length ] bi +
] bi
[ 65521 mod ] bi@
16 shift bitor
;


Expects any sequence of numbers or a string (not much difference, though they aren't technically the same).

I don't know how this will perform for the given limit on a version of Factor compiled with 32-bit word-size, but on my 6GB 64-bit 2.2GHz machine:

IN: scratchpad 1040 63 <array>

--- Data stack:
{ 63 63 63 63 63 63 63 63 63 63 63 63 63 63 ~1026 more~ }
Running time: 7.326900000000001e-05 seconds

--- Data stack:
2181038080

--- Data stack:
2181038080
{ 63 63 63 63 63 63 63 63 63 63 63 63 63 63 ~9986 more~ }
Running time: 0.000531669 seconds


# Ruby, 91 bytes

->s{b=s.bytes;z=i=b.size
b.inject(1,:+)%65521+b.map{|e|e*(1+i-=1)}.inject(z,:+)%65521*4**8}


# Clojure, 109 bytes

(fn f[s](->> s(reduce #(mapv + %(repeat %2)[0(first %)])[1 0])(map #(rem % 65521))(map *[1 65536])(apply +)))


### Ungolfed

(fn f [s]
(->> s
(reduce #(mapv + % (repeat %2) [0 (first %)]) [1 0])
(map #(rem % 65521))
(map * [1 65536])
(apply +)))


## Usage

=> (def f (fn f[s](->> s(reduce #(mapv + %(repeat %2)[0(first %)])[1 0])(map #(rem % 65521))(map *[1 65536])(apply +))))
=> (f [69 97 103 108 101 115 32 97 114 101 32 103 114 101 97 116 33])
918816254
=> (f [80 114 111 103 114 97 109 109 105 110 103 32 80 117 122 122 108 101 115 32 38 32 67 111 100 101 32 71 111 108 102])
3133147946
=> (f (repeat 32 126))
68095937
=> (f (repeat 1040 63))
2181038080
=> (f (repeat 4096 255))
2170679522


## Ungolfed

function a(b)
{
c=1
for(i=0;i<b.length;i++)
{
c+=b[i]
}
d=c%65521
f=""
e=0
k=""
for(j=0;j<b.length;j++)
{
k+= "+"+b[j]
f+= "(1"+k+")"
e= ((eval(f)))
if(j!=b.length-1){f+="+"}
}
g=e%65521
h=d+65536*g
console.log(h)
}


## Golfed

a=b=>{for(c=1,k=f="",y=b.length,i=0;i<y;i++)c+=x=b[i],f+="(1"+(k+="+"+x)+")",i<y-1&&(f+="+");return z=65521,c%z+65536*(eval(f)%z)}


Paste into Developers Console and then give it an Array of Bytes EG:

[69, 97, 103, 108, 101, 115, 32, 97, 114, 101, 32, 103, 114, 101, 97, 116, 33]


And it will return the checksum to the console

# TMP, 55 bytes

3a1.3b0.1;4+a>T8%a>xFFF14+b>a8%b>xFFF11~5<b>164|b>a2$b$

Implementation in Lua can be found here: http://preview.ccode.gq/projects/TMP.lua

• Welcome to Programming Puzzles and Code Golf! Does this language satisfy our definition of programming languages? – cat May 2 '16 at 1:42
• @cat I believe it does, but I'm not sure if it really supports "tuples?" – brianush1 May 3 '16 at 22:02
• Neither does BrainFuck, so you're probably okay. If it's turing complete, can find prime numbers and can do the basic things any other language can do (and it can), it'll work :) CSS isn't a programming language on its own and neither is HTML but CSS3 + HTML is turing-complete and can find primes. – cat May 3 '16 at 22:05
• So, it's okay to use in CodeGolf? – brianush1 May 3 '16 at 22:06
• I think so -- I know neither TMP nor Lua, so an explanation of this code would be a great help (and would make this a great answer). :D – cat May 3 '16 at 22:16

# Python 3.5, 82 bytes:

(-1 byte thanks to Neil!)

(-1 byte thanks to mathmandan!)

(-4 bytes thanks to Dennis!)

lambda w:((1+sum(w))%65521)+4**8*(sum(1+sum(w[:i+1])for i in range(len(w)))%65521)


An anonymous lambda function. Accepts a byte array, applies the entire algorithm to the array, and outputs the result. Has successfully worked for all the test cases. You call this by assigning a variable to it, and then calling that variable just like you would call a normal function. If you are using the shell, then this should output without a print function. However, if you are not, then you must wrap the function call in the print() function to actually see the output.

Try it online! (Ideone)

• (E+15) is actually a byte longer than 65536. – Neil Apr 30 '16 at 9:33
• @Neil Thanks for the tip. It's fixed now. – R. Kap Apr 30 '16 at 9:38
• @Sp3000 So? It would matter if they added some bytes, but the fact that they add no bytes rests fine with me. – R. Kap Apr 30 '16 at 16:21
• 4**8 is a byte shorter than 65536. – mathmandan Apr 30 '16 at 17:03
• You can save 4 bytes by dropping the brackets around the generator and iterating from 0 to len(w). Another 6 bytes can be saved by exploiting operator precedence. – Dennis Apr 30 '16 at 19:20

# Fission, 324 bytes

          /   M
R_MZ  |S
D ]    |S
/?V?\} {}/  |S /    \
R{/A  Z\$[/   |S/     {\
} J{\      |S      ;_
\^  /       |S   R'~++Y++~'L
/    /      |S       }Y;
\  \        ;^/
/  /         +\+ R'~++A++~'L
\  <Z________________/
;\X       //
\Y/
*


Fair warning, the only implementation I've tested this on is my own port of the language to F#. It's not golfed, mainly because I found it easier to have a couple of long runs while my prime constant cooled along the bottom, so I may come back and tweak it.

How does it work?

• The R'~++Y++~'L block fuses a 256 constant and launches it downwards, setting the mass multiplier of the reactor directly below it.
• The R'~++A++~'A block fuses another 256 and launches it up towards the reactor above, which fissions the particle into two mass multiples of 65536 mass each, launching them left and right (where the right particle is immediately destroyed by the terminator).
• The left particle hits another reactor and undergoes fission, splitting into two particles of equal mass heading up and down.
• The upward travelling power-of-two particle passes through a net-zero mass manipulation, reflects to the left, then sets the mass multiplier of the fusion reactor. This reactor will be how we multiply the H block.
• The downward travelling particle reflects to the left and sheds mass over the long run, ultimately reaching a mass of 65521 (our large prime).
• The rotational mirror (Z) at the end of the run causes the particle to duplicate the prime, sending one back to the right where it ultimately sets the stored mass of the fission reactor (^). This is how we'll be applying the modulus operator to the H block.
• The second copy is reflected back, where it performs an analogous function for the fission reactor (<) we'll be using for the L block.
• Now that our constants are in place, we engage in shenanigans in the upper left to read our input and generate our two lists. To be honest, I forget how those work, but for the empty string I had to slow down the H block summing particle, which explains the |S "cooling tower".
• \Y/ fuses the L block (which comes in through the left channel) and the H block (which comes in through the right channel), then slams them into a terminator which sets the exit code to the fused mass.
• Unless I'm making a mistake somewhere, this doesn't seem to work with the official interpreter (link). Where could I get your port to F#? – Dennis May 4 '16 at 5:57
• @Dennis I'm trying to figure out if the bug is on my end or not, but I can't get the interpreter to work either. I'll see if I can get it working then update my answer if need be. – Andrew Coonce May 4 '16 at 6:12
• @Dennis It appears that the online interpreter doesn't handle error code aborts *, which is how I'm returning the output. I'll see if I can find another interpreter to verify the output tomorrow. – Andrew Coonce May 4 '16 at 6:54