text:
Compute the Adler-32 checksum
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)

Task
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 code-golf 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.

@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.

@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.

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.

Ah, ok. Missed the bit about ASCII, and you're correct about 4104.

Using signed integer division, the longest string of ~ (126) that still works correctly is std::string(5837, '~').  5838 fails.  (In my x86-64 asm version, it fails with a SIGFPE divide error, because I picked noisy failure over wrong answers).  @miles: Not sure what you mean.  I think it makes a lot more sense to require actual correct results for ASCII-only strings up to 4096 bytes.  This is not a problem for anything using 32bit or wider integers.  It intentionally disqualifies delayed-modulo implementations that use narrower integers.

When you say "array of integers", do you mean with every ASCII character zero-padded to 32-bits?  That's incredibly convenient and generous, and I guess will save 2B in my x86 asm version (lodsd).  I guess you're aiming to not bloat the code for languages that don't easily treat strings as arrays of numbers?

@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.

Yeah, I agree with that motivation.  It just feels weird for languages like C or asm that have no problem with byte arrays to save 2 bytes by requiring their caller to do a huge amount of memory copying to checksum a string.  I listed both counts in my update, with / without taking advantage of that.  There was some interesting golfing involved in saving 2 bytes, not just one, taking advantage of the known zero-padding.  But it still feels wrong for that language, so it's a side-note, not the main code.  Any thoughts?  We should continue this discussion under my answer, if there's more to say.

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 I have outgolfed your 18-byte then.

Well, you have outgolfed..

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&

Welcome, you can call #1 as simply # to save a few bytes. Based on @Alex A.'s solution, {1,4^8}.{Tr@#+1,Tr[Accumulate@#+1]}~Mod~65521& using 46 bytes can be used.

...Did you just golf your own famous algorithm?

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!

Not all that big.

We can also use ## to reduce #+#2+{0,#[[1]]}& to ##+{0,#[[1]]}& in your Fold.

And #&@@# is the standard trick for #[[1]]. :)

@MartinBüttner Wow, that's an amazing trick. It's nice how Mathematica's parser allows so many nested anonymous functions.

I suspect that you thought about this puzzle before the question was posted. :D And of course that's perfectly fine!

If you mean me, this is the first time I thought of implementing Adler-32 in Mathematica.

Or perhaps you've got this solution ready since you joined Code Golf, just waiting for it to be asked. "Finally!" ;-)

@MarkAdler: Yes, I did mean you, but I certainly wasn't implying that you didn't put any thought into solving this puzzle, or that you've got nothing better to do with your time than to sit around thinking about how to implement Adler-32 in various languages.

(cont) I, too, was a little star-struck when I learned that you participate on Stack Exchange. FWIW, I got a chuckle from the comment interchange on this answer when I saw it a few days ago. So thanks for being here, and thanks for Adler-32, and your contributions to gzip, PNG, etc. It must feel nice to have made such a significant impact on the digital world.

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 I have Sp3000 and Dennis to thank for most of the cleverness. :)

x86-64 machine code function: 33 32 bytes  (or 31 30 bytes with an int[] input instead of char[])
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
0000000000401120 <golfed_adler32_amd64>:
  401120:       31 c0                   xor    eax,eax
  401122:       99                      cdq
  401123:       8d 7a 01                lea    edi,[rdx+0x1]
0000000000401126 <golfed_adler32_amd64.byteloop>:
  401126:       ac                      lods   al,BYTE PTR ds:[rsi]
  401127:       01 c7                   add    edi,eax
  401129:       01 fa                   add    edx,edi
  40112b:       e2 f9                   loop   401126 <golfed_adler32_amd64.byteloop>
000000000040112d <golfed_adler32_amd64.end>:
  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
0000000000401140 <golfed_adler32_amd64_end>:

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

    xor     eax,eax         ; scratch reg for loading 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
golfed_adler32_amd64_end_v3:

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
golfed_adler32_int_array:
    ; 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
    ;cdq               ; edx=0 already, ready for div
    ; 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: 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.

@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--){}.

The length will be positive. I've added that to the question.

@Dennis: thanks.  I notice most answers don't explain at length how they were developed, or mention ideas that didn't pan out.  Is that discouraged?  It makes my answer gigantic and takes a lot of space on the page, so I could see it being annoying if everyone was as bad at writing short answers as I am.  I could put the commented source and C++ caller on gist.github or something.

When it comes to explanations, the more detailed, the better.

Oh my god. Are you a masochist?

@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.

Also, the reason most languages' / peoples' explanations are less thorough is because there's a lot less work that goes into higher-level code, even if the result is less readable than ASM. ASM answers always have great explanations, like this one: http://codegolf.stackexchange.com/a/76908/46231 Keep up the great answers, though! :D

I'm thinking about an ARM version.  Using predication to do if (low>=m) low-=m; maybe avoids the need for a div.

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

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.

Actually, 36 bytes
;Σu@;╗lR`╜HΣu`MΣk`:65521@%`M1#84ⁿ@q*

Try it online!
Explanation:
;Σu@;╗lR`╜HΣu`MΣk`:65521@%`M1#84ⁿ@q*
;Σu                                   sum(input)+1
   @;╗lR                              push a copy of input to reg0, push range(1, len(input)+1)
        `╜HΣu`M                       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]

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!"

PS B:\Marvin\Desktop\Piet> .\npiet.exe adler32.png
? 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):
action: add
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):
action: add
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):
action: add
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):
action: add
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):
action: add
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):
action: add
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):

Labyrinth, 37 36 32 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.
+   Add it to HIGH.

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.
+        Add it to LOW.
!        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.

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...

This implementation made a nice starting point for my x86 asm version.

Can save 1 byte using for instead of while: for(h=0,l=1;*B;)h+=l+=*B++;

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.

Haskell, 54 50 bytes
m=(`mod`65521).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=(`mod`65521).sum g x=m(-1:scanl(+)1x)*4^8+m(1:x). There's probably a better way to fix the sums than prepending.

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...

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 &&
   g++ -DTEST_16BIT -m32 -std=gnu++11 -O1 -g -Wall -Wextra -o test-adler32-x16  adler32-x86-16+32.o  test-adler32.cpp -lz &&
   ./test-adler32-x16
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, 25 24 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:

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.
map$h+=$.+=$_,@F means that for each element in @F we add that element to $. and then add $. to $h.
Then we do the modular arithmetic $.%65521+$h%65521*4**8 (that is, ($. % 65521) + ( ($h % 65521) * (4**8) ) and say (print) the result.

Factor, 112 109 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~ }
IN: scratchpad [ adler-32 ] time
Running time: 7.326900000000001e-05 seconds

--- Data stack:
2181038080
IN: scratchpad 10,000 63 <array>

--- Data stack:
2181038080
{ 63 63 63 63 63 63 63 63 63 63 63 63 63 63 ~9986 more~ }
IN: scratchpad [ adler-32 ] time
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
Based on @Mark Adler's solution.
(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

Javascript (130 Characters Golfed)
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 I believe it does, but I'm not sure if it really supports "tuples?"

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.

So, it's okay to use in CodeGolf?

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

Since you're new here (and to Stack Exchange), welcome, again, to the vast network of communities and be sure to check out Standard Loopholes that are forbidden by default and the rest of the FAQ. You can find the welcoming community of PPCG in chat if you have questions.

@cat We don't require languages to be Turing complete.

@Dennis Oh, oops.

The interpreter doesn't work for me. I get: lua: /home/cat/projects/lua/code/tmp.lua:16: attempt to perform arithmetic on local 'b' (a string value)

It works for me... Make sure you're passing in bytes, not a string.

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 Thanks for the tip. It's fixed now.

@Sp3000 So? It would matter if they added some bytes, but the fact that they add no bytes rests fine with me.

4**8 is a byte shorter than 65536.

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 Well, for some reason, iterating from 0 to len(w) yields the wrong answer on each test case for some reason. I will, however, use your tip for removing the brackets around the generator. Thanks! :)

You'd use w[:i+1] in that case.

@Dennis Thanks! :)

@Sp3000 Okay, I got rid of them.

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 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.

@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.

ABAP, 118 bytes
FORM a TABLES t USING l h.l = 1.LOOP AT t.ADD:t TO l,l TO h.ENDLOOP.l = l MOD 65521 + 65536 * ( h MOD 65521 ).ENDFORM.

Ungolfed
FORM a TABLES t USING l h.
  l = 1.
  LOOP AT t.
    ADD: t TO l,
         l TO h.
  ENDLOOP.
  l = l MOD 65521 + 65536 * ( h MOD 65521 ).
ENDFORM.

This is my first try at code golfing, if I did anything wrong please let me know! I used ABAP because that's my main programming language. Now for the explanation:
FORM a TABLES t USING l h.
  ...
ENDFORM.

This declares the function "a" with the inputs t, l and h. I defined t as a table of integers and filled it with the different numbers from the original post (for test purposes). l and h are defined as DEC variables with length 31 (highest it can go in ABAP). l is also used as the returning variable for the function so I don't have to use an additional variable.
  LOOP AT t.
    ...
  ENDLOOP.

This is a loop over the table t, which is defined as a table with header-line. This means that the table has a header-line which acts as a variable ("t") and it also has a table body ("t[ ]") at the same time. So "LOOP AT t" reads the rows in the table t[ ] (in order) into the header-line t. Header-lines are obsolete but they save quite a bit of bytes over the now used "LOOP AT table INTO variable.".
    ADD: t TO l,
         l TO h.

Within the loop I'm starting a slightly modified version (pretty much just rearranged) of the calculation that Dennis has in his original post. l = low, h = high. I'm adding the current value in the table to the variable l (which i define to start at 1 in the line "l = 1."). Each step in the loop I'm also adding l to h.
I use "ADD" because ABAP doesn't have "l += t" and using the code above is shorter than:
l = l + t.
h = h + l.

After the loop we have the following:

l = (1 + b1 + ⋯ + bn)
h = ((1 + b1) + (1 + b1 + b2) + ⋯ (1 + b1 + ⋯ + bn))

At the end I'm doing the final calculation:
  l = l MOD 65521 + 65536 * ( h MOD 65521 ).

Sadly you need spaces between the operators and numbers/variables because ABAP uses the operators without spaces for different things. For example:
char+4 = 'A'.

This sets the 5th character (because the offset is set as "4") of the character variable "char" as 'A'. So if "char" was "BBBBB" before that line, it would be "BBBBA" after.
I hope this explanation isn't too long (which I think it is, since the code is really straight forward). ABAP doesn't have bitwise operations AFAIK so I couldn't use a shorter algorithm but I think 118 bytes is still pretty good.
Here's the full program in case anyone can and wants to test it:
REPORT z_adler_checksum.

DATA:
  lt_i TYPE TABLE OF i WITH HEADER LINE, "Input table
  l_l  TYPE zz, "Calculation and return variable
  l_h  TYPE zz. "Calculation variable

DO 1040 TIMES. "Filling the table for the last test case in the original post
  APPEND 63 TO lt_i.
ENDDO.

PERFORM a TABLES lt_i USING l_l l_h. "Calling the function

WRITE l_l. "Output of the result

FORM a TABLES t USING l h.
  l = 1.
  LOOP AT t.
    ADD: t TO l,
         l TO h.
  ENDLOOP.
  l = l MOD 65521 + 65536 * ( h MOD 65521 ).
ENDFORM.

K (ngn/k), 32 bytes
{+/1 65536*65521!(*|x),+/x:1+\x}

Try it online!

Husk, 22 bytes
+*□256₁m→∫¹₁:1
%65521Σ

Try it online!
May be shorter with a lambda.
Explanation
%65521Σ Function ₁:
      Σ sum of elements of the argument
%65521Σ modulo 65521

+*□256₁m→∫¹₁:1 main program:
           ₁:1 prepend 1(to the input), apply Function ₁
+              plus
         ∫¹    cumulative sums of the input
       m→      increment each sum
      ₁        apply function 1
 *□256         multiply with 256² (65536)

Scala, 94 Bytes
(s:String)=>{
val t=((1L,0L)/:s){(r,c)=>val a=(c+r._1)%65521
(a,(a+r._2)%65521)};t._1+(t._2<<16)
}

Performs Adler-32 Checksum on Strings, using the alternate for foldLeft, /:

Postgresql, 164 bytes
SELECT t,((SUM(b)+1)%65521)+65536*(SUM(1+b*(LENGTH(t)-r+1))%65521)
FROM v,LATERAL generate_series(1,LENGTH(t))r
,LATERAL(SELECT ASCII(SUBSTRING(t,r,1))b)z GROUP BY t;

SqlFiddleDemo
Output:
╔═══════════════════════════════════╦════════════╗
║                t                  ║  ?column?  ║
╠═══════════════════════════════════╬════════════╣
║ PostgreSQL can handle it          ║ 1850149040 ║
║ ?(x1040)                          ║ 2181038080 ║
║ Programming Puzzles & Code Golf   ║ 3133147946 ║
║ Eagles are great!                 ║  918816254 ║
║ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ║   68095937 ║
╚═══════════════════════════════════╩════════════╝

Version with parameter as subquery:
SELECT((SUM(b)+1)%65521)+65536*(SUM(1+b*(LENGTH(t)-r+1))%65521)
FROM(SELECT text'Eagles are great!'t)s,LATERAL generate_series(1,LENGTH(t))r
,LATERAL(SELECT ASCII(SUBSTRING(t,r,1))b)z;

SqlFiddleDemo2

Forth (gforth), 117 bytes
: f 2dup bounds 1 -rot do i c@ + loop 65521 mod -rot dup 0 do i for over i + c@ + next loop 65521 mod nip 65536 * + ;

Try it online!
Code explanation
: f                 \ start a new word definition
\ Calculate Low:
  2dup bounds       \ copy the string start address and length and get string end address
  1 -rot            \ start an accumulator to hold low (initialize to 1)
  do                \ loop from start address to end-address
    i c@ +          \ get ascii value for each char and add to accumulator
  loop              \ end loop
  65521 mod -rot    \ get value % 65521 to get Low and move off top of stack

\ Calculate High:
  dup 0 do          \ loop from 0 to string-length - 1
    i for           \ loop from outer-loop index to 0
      over i +      \ get address of current ascii char
      c@ +          \ get value of current char and add to total
    next            \ end inner loop
  loop              \ end outer loop
  65521 mod         \ get value % 65521 to get High
  nip               \ remove extraneous value from stack

\ Calculate Checksum
  65536 * +         \ multiply High by 65536 and add to Low
;                   \ end word definition

Japt, 23 bytes
[UåÄ Up1]®x uFnG²²ÃìG²²

Try it

Rockstar, 156 bytes
listen to N
T's1
C's0
while N
let T be+N-0
let C be+T
listen to N

X's65521
let M be C/X
turn down M
let C be-M*X
let M be T/X
turn down M
say T-M*X+C*65536

Try it here (Code will need to be pasted in, with input as newline separated codepoints)

Thunno 2, 16 bytes
ṡ⁺S$S⁺,»¢¢ȯ»%ɠ²ḋ

Try it online!
Port of Leaky Nun's Jelly answer.
Explanation
ṡ⁺S$S⁺,»¢¢ȯ»%ɠ²ḋ  # Implicit input
ṡ⁺                # Cumulative sums, increment
  S               # Sum the resulting list
   $S⁺,           # Pair with sum(input) + 1
       »¢¢ȯ»%     # Mod by 65521
             ɠ²ḋ  # Convert from base 65536
                  # Implicit output


text:
How many shapes are in this picture?
Children are very good at classifying objects and counting them. Computers seem to have more trouble. This is a simplified version of this problem. Can you write a small program that can classify and count objects in an image?
The problem: Given an image containing one or more circles and rectangles, return 2 integers
with the count of circles and count of rectangles.
Rules

The input image will be black figures on a white background in any bitmap
format you choose.
The image width and height will be between 100 and 1000 pixels.
Figures will be fully contained within the image.
Figures will have 1 pixel line width.
Images will not use anti-aliasing. They will be black on white only.
Figures may touch, intersect, or be inside another figure.
Intersecting figures will have a maximum of 4 common pixels.
Circles will have a diameter of 20 pixels or more.
Rectangle sides will be 10 or more pixels long.
You may not use any built-ins or libraries that recognize shapes, or any other
function that makes this challenge trivial.
Return or print 2 integers with the counts of circles and rectangles.

Example 1

Answer: 3 4
Example 2:

Answer: 4 13
This is a code golf challenge, so the shortest program or function in each language will win.

I can already tell, counting the rectangle will be about counting corners.Circles will be a lot harder though.

PHP – 355 bytes
The byte count doesn't include '<image-url>'.
<?php
m('<image-url>');function m($f){$i=imagecreatefrompng($f);$r=f($i,17);$c=f($i,9);echo($c-$r).' '.$r."\n";}function f($i,$k){$w=imagesx($i);$h=imagesy($i);$r=0;for($y=0;$y<$h;$y++)for($x=0;$x<$w;$x++)if(!imagecolorat($i,$x,$y))$r+=g($i,$x,$y,$w,$k);return$r;}function g($i,&$x,$y,$w,$k){$l=$x;while(!imagecolorat($i,$x,$y)&&$x<$w)$x++;return($x-$l>$k)?1/2:0;}

In the two test cases, the URLs I used are https://i.stack.imgur.com/qnIFk.png and https://i.stack.imgur.com/HV9k3.png.
Counts horizontal lines and divides by two to get the number of shapes. Relies on the observation that circles have shorter horizontal segments and rectangles have longer horizontal segments.
Admitted hack, not guaranteed to work for anything other than the test cases!
I tried rotating the images by ± 45° and detecting for horizontal lines. This would be equivalent to checking for diagonal lines and would pick up the circles better, but I couldn't find an interpolation algorithm which left clean enough edges to work with. For example, they might smudge a line into two rows of pixels and mess up the count.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
exponential without exponential
Your goal is to calculate the exponential of a float (e**x) up to 2 decimal places for any float within 1 to 10. The accepted error range is 0.01.
However, you must not use the built-in exponential function or the logarithm function.
In fact, attempts to circumvent this by (2**x)**(1/ln(2)) are prohibited, even if you hardcode the ln(2).
Basically, the power function is fine, as long as the index is not derived from the input.
Shortest solution in bytes wins.
(You may include an extra solution which uses the built-in, but which does not affect the score in any way.)
Specs

Program or function
Any reasonable input/output format

Testcases
1 -> 2.71 or 2.72 or 2.73

you must not use the built-in exponential function would seem to collide with the power function is fine

x** 3 is allowed while 3**x is not.

What about 3 ^ 3, or x ^ y>? (I'm not suggesting hardcoding the output, I just don't get the difference)

The index cannot be any function of the input.

related

Does float imply 32bit floats, namely the range -3.4E+38 to +3.4E+38?

We've calculated e^x and ln(x) before. http://codegolf.stackexchange.com/questions/9080/calculate-ex-and-lnx/9081

Matlab, 17 bytes
@(x)(1+x/1e9)^1e9

I'm deeply confused as to why this works.

exp(x) = limit (1+x/n)^n as n->infinity. As long as you only have a fixed range you just need to choose n big enough.

OH. Welp. My Taylor series workings out are now useless. xD

The talyor series are also quite well known exp(x) = sum x^n / n! for n=0 upto inftinity, converges everywhere.

Well, yeah - I meant porting it to AS.

Haskell, 19 bytes
(**1e9).(1+).(/1e9)

or alternatively a named function:
f x=(1+x/1e9)**1e9

AppleScript, 204 bytes
set x to(display dialog""default answer"")'s text returned
set r to 1
set i to 1
repeat 29
set r to r+(x^i)/f(i)
set i to i+1
end
return r
on f(a)
set x to a
repeat x-1
set a to a-1
set x to a*x
end
x
end
Yeah, it's kinda long. This uses the 30th term Taylor polynomial representation for e^x.
How this works:
The Taylor series expansion for ex is:

Now, according to the Lagrange error bound, I know that any given Taylor polynomial can get a precision to the first unused term of the Taylor series.
In more mathematical terms, I know that:

where I will have a precision to ex of ak+1.
Since the OP specified that I must have a precision of 2 decimal places or better, ak+1 must be less than or equal to 1/100. I need to work out the point at which the maximum error of the function possible, located at 10 in this case is less than said error. After a little trial and error, I found that:

Which means that:

For as far as our precision is concerned. The code reflects this in that I will calculate:

AppleScript, 62 bytes
Okay, limit approximation of ex is better. ;P Thanks, flawr.
(1+(display dialog""default answer"")'s text returned/1e9)^1e9

MATL, 9 bytes
1e9/Q1e9^

Based upon @flawr's answers.
Try it Online
Explanation
        % Implicitly grab input as a number
1e9     % Number literal
/       % Divide the input by 1e9
Q       % Add one
1e9     % Number literal
^       % Exponent
        % Implicitly display result

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Calculate the a ^ b WITHOUT using *, / and ^
Challenge
Your goal is, given two positive integer numbers a and b, to calculate (and output) a ^ b without using either multiplication, division and the power itself (not directly, at least).
And, of course, built-in exponentiation functions.
Scoring
This is code-golf, so the shorter, the better.
Test cases
Input => Output
2, 3 => 8
5, 5 => 3125
100, 4 => 100000000
17, 9 => 118587876497
0, 1 => 0
3921, 0 => 1

I assume by ^ you mean exponentiation? In some languages ^ has a different meaning.

Welcome to Programming Puzzles & Code Golf. This is currently underspecified, since the symbols ^, *, / and ^ can have a completely different meaning in my language of choice than you intended. Please note that do X without Y challenges are rather hard to write, because of loopholes, ambiguities and similarity to other restricted-source challenges.

I think it's a possible duplicate of Exponentiation of natural numbers using only primitive integer operations (which might not really be a duplicate, although it's currently marked as such)

k (19 bytes)
This is slow and uses lots of memory:
{#,//(x#,:)/[y;0b]}

The /s are not division, it's the converge operator.


text:
Will it float?
The challenge
Given a 2d string representing the bottom of a boat as an input, you must determine whether or not the boat will float. This 2D string can be in whatever format is most convenient. (String with newlines, list of string, list of list of chars, etc.) Print a truthy value if it will float, and a falsey value if it will sink.
A boat will tip over if the bottom has an inconsistent density, so every character of must be the same. Also, if a boat has large holes in it, represented by spaces, it will sink, so your boat must have no holes with an area greater than 4. Here is an example:
########
#   ####
########
#  ## ##
#  #####
########

This boat is valid because the largest hole in it has an area of 4. This boat:
########
########
#     ##
#  #####
########

is invalid because it has a hole with an area of 7. You can safely assume that the outside of every input will be a solid rectangle with no holes. Here are some more tests:
$$$$$$$$
***$$$$$
***$$$$$
***$$$$$
$$$$$$$$
Invalid density. Sink.

%%%%%%%%
%    % %
%%%%%  %
%    % %
%%%%%%%%
None of the holes are larger than 4. Float.

OOOOOOOO
OOOOOOO
OOOOOOOO
OOOOOOOO
OOOOOOOO
The outside border is not solid. Undefined.

&&&&&&&&&&&&&
& & & & & & &
&& & & & & &&
& & & & & & &
&& & & & & &&
& & & & & & &
&&&&&&&&&&&&&
Although I would not be comfortable riding in this boat myself,
none of the holes are larger than 4. It floats.

@@@@@
@   @
@   @
@   @
@@@@@
It sinks.

Rules

IO can be in any reasonable format.
Standard loopholes apply.
Shortest answer in bytes wins.
The given string will entirely consist of printable ASCII.

What is the bottom? What is the frame?

@flawr The bottom is the string you take as input. The frame is a poor choice of wording that I will edit out.

A "2d string"? You mean a list of strings?

I think the & boat exists

"A boat will tip over if the bottom has an inconsistent density, so every character of must be the same."  If the outside border was one character and the interior were a different character it would be inconsistent density but it wouldn't tip over would it?

I would like to see an answer using PMA/Snails...

Matlab, 106 bytes
s=input('');im=~(s-32);c=bwconncomp(im,4);disp(~nnz(cellfun(@nnz,c.PixelIdxList)>3)&nnz(unique(s(~im)))<2)

The input is a matrix of characters, e.g. for the first test case:
`['$$$$$$$$';'***$$$$$';'***$$$$$';'***$$$$$';'$$$$$$$$']`

Explanation:
s=input('');           %read input
im=~(s-32);            %convert input to bw image (space = black)
c=bwconncomp(im,4);    %calculate the connected components (4 connectivity)

disp(
     ~nnz(cellfun(@nnz,c.PixelIdxList)>3) %find out whether we have components that have more at least 4 pixels
     &nnz(unique(s(~im)))<2)              %find out if we have more than 1 non-space character

APL (Dyalog Unicode), 76 bytes
{(1=≢∪' '~⍨∊⍵)∧×/5>a/⍨×a←∊g↓⍉↑(g←{⊃,/{×⊃⍵:+/⍵⋄⍵}¨⍵⊂⍨1,2{≠/0=⊃¨⍺⍵}/⍵}¨)' '=⍵}

Try it online!
Accepts input as a list of strings.
1 for floating, and 0 for sinking.
Explanation
{(1=≢∪' '~⍨∊⍵)∧×/5>a/⍨×a←∊g↓⍉↑(g←{⊃,/{×⊃⍵:+/⍵⋄⍵}¨⍵⊂⍨1,2{≠/0=⊃¨⍺⍵}/⍵}¨)' '=⍵}
                                                                      ' '=⍵ boolean array for spaces
                              (g←{⊃,/{×⊃⍵:+/⍵⋄⍵}¨⍵⊂⍨1,2{≠/0=⊃¨⍺⍵}/⍵}¨)       apply the following function g to each row:
                                                    1,2{≠/0=⊃¨⍺⍵}/⍵         get the start of each group of zeroes/nonzero values
                                                 ⍵⊂⍨                        cut the list according to that
                                     {×⊃⍵:+/⍵⋄⍵}¨                           sum each nonzero array
                                  ⊃,/                                       join all of that together
                         g↓⍉↑                                               apply g again on the transpose
                  a/⍨×a←∊                                                   flatten and remove zeroes
              ×/5>                                                          are all sums ≤ 4?
             ∧                                                              and
     ' '~⍨∊⍵                                                                the boat with spaces removed
    ∪                                                                       uniquified
 1=≢                                                                        has only 1 element?

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Compute CRC32 Hash
Credits
This challenge originated from @miles.

Create a function that computes the CRC32 hash of an input string. The input will be an ASCII string of any length. The output will be the CRC32 hash of that input string.
Explanation
The algorithm of CRC32 and other CRC are essentially the same, so only CRC3 will be demonstrated here.
Firstly, you have the generator polynomial, which is actually a 4-bit [n+1] integer (would be 33-bit in CRC32).
In this example, the generator polynomial is 1101.
Then, you will have the string to be hashed, which in this example would be 00010010111100101011001101.
00010010111100101011001101|000 (1)    append three [n] "0"s
   1101                        (2)    align with highest bit
00001000111100101011001101|000 (3)    XOR (1) and (2)
    1101                       (4)    align with highest bit
00000101111100101011001101|000 (5)    XOR (3) and (4)
     1101                      (6)    align with highest bit
00000011011100101011001101|000 (7)    XOR (5) and (6)
      1101                     (8)    align with highest bit
00000000001100101011001101|000 (9)    XOR (7) and (8)
          1101                 (10)   align with highest bit
00000000000001101011001101|000 (11)   XOR (9) and (10)
             1101              (12)   align with highest bit
00000000000000000011001101|000 (13)   XOR (11) and (12)
                  1101         (14)   align with highest bit
00000000000000000000011101|000 (15)   XOR (13) and (14)
                     1101      (16)   align with highest bit
00000000000000000000000111|000 (17)   XOR (15) and (16)
                       110 1   (18)   align with highest bit
00000000000000000000000001|100 (19)   XOR (17) and (18)
                         1 101 (20)   align with highest bit
00000000000000000000000000|001 (21)   XOR (19) and (20)
^--------REGION 1--------^ ^2^

The remainder obtained at (21), when region 1 is zero, which is 001, would be the result of the CRC3 hash.
Specs

The generator polynomial is 0x104C11DB7, or 0b100000100110000010001110110110111, or 4374732215.
Input can be a string or a list of integers, or any other reasonable format.
Output be a hex string or just an integer, or any other reasonable format.
Built-ins that compute the CRC32 hash are not allowed.

Goal
Standard rules for code-golf apply.
The shortest code wins.
Test cases
input         output      (hex)
"code-golf"   147743960   08CE64D8
"jelly"       1699969158  65537886
""            0           00000000

If I understand right, this is doing polynomial division modulo 2 and finding the remainder, i.e. the analogue of mod in XOR multiplication.

Yep. This is not xnor modulo though, this is xor modulo.

For CRC32, do you first append 31 0's?

Yes  – – – – – – – – –

@KennyLau you can ping people with their name, just like chat.

In your example, why is the remainder 001 rather than 1100?

@Dennis Added .

Are builtins for polynomial division allowed?

@LuisMendo I don't think there will be any built-in suitable for this challenge. Would you care to provide an example?

But isn't the CRC in your example a 3-bit hash?

@KennyLau I meant this. I'm not sure it helps. It's standard polynomial division

@Dennis Should be fixed now?

@LuisMendo I don't think that would be useful.

You say the string in the example is 00010010111100101011001010, but the last four bits in stage 1 are 1101.

Intel x86, 34 30 29 27 bytes
Takes the address of the zero-terminated string in ESI, and returns the CRC in EBX:
31 db ac c1 e0 18 74 01 31 c3 6a 08 59 01 db 73
06 81 f3 b7 1d c1 04 e2 f4 eb e7

Disassembly (AT&T syntax):
00000000    xorl    %ebx, %ebx
00000002    lodsb   (%esi), %al
00000003    shll    $24, %eax
00000006    je      0x9
00000008    xorl    %eax, %ebx
0000000a    pushl   $8
0000000c    popl    %ecx
0000000d    addl    %ebx, %ebx
0000000f    jae     0x17
00000011    xorl    $0x4c11db7, %ebx
00000017    loop    0xd
00000019    jmp     0x2
0000001b

Incorporating suggestions from Peter Cordes to save four more bytes. This assumes a calling convention where the direction flag for string instructions is cleared on entry.
Incorporating suggestion of Peter Ferrie to use push literal and pop to load a constant, saving one byte.
Incorporating suggestion of Peter Ferrie to jump to the second byte of an xorl %eax, %ebx instruction which is a retl instruction, combined with changing the interface of the routine to take a zero-terminated string instead of length, saving two bytes in total.

Use a calling convention that requires the direction flag to be cleared on entry, so you can save the cld insn (like I did in my adler32 answer).  Is it normal practice to allow totally arbitrary calling conventions for asm answers?

Anyway, it looks like your code will work as x86-64 machine code, and you could use the x86-64 SysV x32 calling convention to take count in edi and the pointer in esi (maybe not zero-extended, so maybe fudge things and require a 64bit zero-extended pointer).  (x32 so you can safely use 32bit pointer math, but still have the register-args calling convention.  Since you don't use inc, there's no downside to long mode.)

Did you consider keeping edx in byte-reversed order?  bswap edx is only 2B.  shr %edx is 2B, same as your left-shift with add %edx,%edx.  This probably isn't helpful; Unless it enables more optimization, you save 3B for the shl $24, %eax, but you spend 4B for xor %eax,%eax at the start and bswap %edx at the end.  Zeroing eax does let you use cdq to zero %edx, so overall it's a wash.  It would perform better, though: it avoids the partial-register stall/slowdown on every iteration from writing al and then reading eax with shl. :P

If you limit the input length to 0..INT_MAX (signed), then you can save 3B (in 32bit code) by looping with dec %ebx / jge instead of comparing with an end pointer (this saves the addl    %esi, %ebx as well as cmp->dec).  jge instead of jne is the trick to still returning in the len=0 case.  In 64bit code, dec %ebx is 2B instead of 1B, so I guess nvm my suggestion to use the x32 ABI.  But requiring the direction flag to be cleared on call/ret is standard for many calling conventions, so you shouldn't worry about requiring it if you're already doing stuff like returning in edx.

Thanks! I incorporated the use of jge (there is in fact a limit on the length in the rules), and took out the cld. The byte swap would not work at all, since then the bits are in the wrong place to use a one-bit shift right.

Oh right, silly me, forgot about the bitwise part.  BTW, I think disassembly output showing the instruction bytes would be ideal.  I like being able to see which instructions are which length just from counting the bytes, not from subtracting addresses.  Branch labels are a bonus, too.  objdump -d is nice.  Putting a label after the last instruction byte means gives you the byte count without having to remember to count the ret byte.

The question says "ASCII string of any length", but a length limit of 2GiB (signed length) should be acceptable if a limit of ~4GiB (32bit pointer) is acceptable.  Fun fact, even if the crc32 instruction was allowed, it's not useful because it uses the now-prefered CRC32C polynomial (0x11EDC6F41), rather than the question's 0x104C11DB7.

Got confused with the Adler-32 question, which has a length limit. This question doesn't have an explicit length limit.

There might be a way to make this shorter with the PCLMULQDQ instruction. However its use tends to need a lot of constants, so possibly not.

Interesting.  Intel has a paper on using it for CRC with arbitrary polynomials, obviously focusing on performance (not code size).  Even movd to get the result back into an integer register is 4B.  Vector code can be many fewer insns, but most integer insns are at least 4B.  (SSE ps instructions like xorps are 3B, when the operands only require a one-byte mod/rm).  There's no 1B-shorter MMX version of pclmul, and its encoding is 6B (including the imm8)

Ah, I see you already wrote an SO answer to a question about that paper.  :P  Anyway, it's going to be a rare question where SSE helps at all for golfing, because Intel didn't leave much opcode space for short instructions.  And if you need to handle input lengths that aren't multiples of 16, then you need a scalar cleanup loop (or for some algorithms like min(), do a potentially-overlapping unaligned last vector of data if it doesn't matter that you see some elements multiple times.)

the "xorl %ecx,%ecx/movb $8,%cl" can be "push $8/pop %ecx" to save one byte.  If the string is always non-NULL, then the "jmp 0x1a" can be removed, to save two bytes, because the CRC will calculate as zero. If the CRC were stored in %ebx instead, then the exit condition could branch to the $0xC3 part of the $0x31 $0xC3-encoded XOR instruction, to save another byte.

@peterferrie Thanks! I incorporated the pop and the jump into the xor, as well as making an assumption that it is a zero-terminated string.

Jelly, 34 bytes
l2_32Ḟ4374732215æ«^
Oḅ⁹æ«32Çæ»32$¿

Try it online!

Ruby, 142 bytes
Anonymous function; takes a string as input, returns an integer.
->s{z=8*i=s.size;r=0;h=4374732215<<z
l=->n{j=0;j+=1 while 0<n/=2;j}
s.bytes.map{|e|r+=e*256**(i-=1)};r<<=32
z.times{h/=2;r^=l[h]==l[r]?h:0}
r}

Can you change your name so that people can distinguish us? XD

@KennyLau must you be so picky... OK fine

I was just kidding xd

Jelly, 23 bytes
ḅ⁹Bµ4374732215B×ḢḊ^µL¡Ḅ

Input is in form of a list of integers. Try it online! or verify all test cases.
How it works
While Jelly has bitwise XOR, padding the input with zeroes and aligning the polynomial with the most significant binary digit makes this approach, which uses lists of bits instead, a tad shorter.
ḅ⁹Bµ4374732215B×ḢḊ^µL¡Ḅ  Main link. Argument: A (list of bytes)

ḅ⁹                       Convert A from base 256 to integer.
  B                      Convert the result to binary, yielding a list.
   µ                     Begin a new, monadic chain. Argument: B (list of bits)
    4374732215B          Convert the integer to binary, yielding a list.
                Ḣ        Pop and yield the first, most significant bit of B.
               ×         Multiply each bit in the polynomial by the popped bit.
                 ^       Compute the element-wise XOR of both lists.
                         If one of the lists is shorter, the elements of the other
                         lists do not get modified, thus avoiding the necessity
                         of right-padding B with zeroes.
                  µ      Convert the previous chain into a link.
                   L¡    Execute the chain L times, where L is the number of bits
                         in the original bit list.
                     Ḅ   Convert from binary to integer.

Pyth, 42 bytes
?!Q0h<#^2 32.uxN.<4374732215.as-lN32.<CQ32

Test suite.

CJam, 37 36 bytes
q256b32m<{Yb4374732215Yb.^Yb_Yb32>}g

Test it here.
Explanation
q               e# Read input.
256b            e# Convert to single number by treating the character codes
                e# as base-256 digits.
32m<            e# Left-shift the number by 32 bits, effectively appending 32
                e# zeros to the binary representation.
{               e# While the condition on top of the stack is truthy...
  Yb            e#   Convert the number to base 2.
  4374732215Yb  e#   Convert the polynomial to base 2.
  .^            e#   Take the bitwise XOR. If the number is longer than the
                e#   polynomial, the remaining bits will be left unchanged.
  Yb            e#   Convert the list back from base 2, effectively stripping
                e#   leading zeros for the next iteration.
  _             e#   Duplicate the result.
  Yb            e#   Convert back to base 2.
  32>           e#   Remove the first 32 bits. If any are left, continue the loop.
}g

q256bYb_,{(4374732215Ybf*1>.^}*Yb saves a few bytes.

@Dennis That's really clever, feel free to make it a separate answer. :)

Pyth, 28 bytes
uhS+GmxG.<C"Á·"dlhG.<Cz32

Try it online: Demonstration or Test Suite
Explanation:
uhS+GmxG.<C"..."dlhG.<Cz32   implicit: z = input string
                      Cz     convert to number
                    .<  32   shift it by 32 bits
u                            apply the following expression to G = ^,
                             until it get stuck in a loop:
     m           lhG            map each d in range(0, log2(G+1)) to:
          C"..."                   convert this string to a number (4374732215)
        .<      d                  shift it by d bits
      xG                           xor with G
   +G                           add G to this list
 hS                             take the minimum as new G

JavaScript (ES6), 180 bytes
f=(s,t=(s+`\0\0\0\0`).replace(/[^]/g,(c,i)=>(c.charCodeAt()+256*!!i).toString(2).slice(!!i)))=>t[32]?f(s,t.replace(/.(.{32})/,(_,m)=>(('0b'+m^79764919)>>>0).toString(2))):+('0b'+t)

The lack of a 33-bit XOR operator, or even an unsigned 32-bit XOR operator, is unhelpful.

CJam, 33 bytes
q256bYb_,{(4374732215Ybf*1>.^}*Yb

Input is in form of a string. Try it online!
How it works
q                                  Read all input from STDIN.
 256bYb                            Convert it from base 256 to base 2.
       _,{                   }*    Compute the length and repeat that many times:
          (                          Shift out the first bit.
           4374732215Yb              Convert the integer to base 2.
                       f*            Multiply each bit by the shifted out bit.
                         1>          Remove the first bit.
                           .^        Compute the element-wise XOR of both lists.
                                     If one of the lists is shorter, the elements
                                     of the other lists do not get modified, thus
                                     avoiding the necessity of right-padding B with
                                     zeroes.
                               Yb  Convert the final result from base 2 to integer.