The specification does have a hierarchical outline, and you can click on cross references too. Of course navigation can still be cumbersome, linking to chapters can also be awkward (tip: right click on outline element and copy link works in Firefox).
There are some problems of the spec though, and navigation is not the most pressing one. The spec is huge, support for less used parts is spotty in various PDF readers. It also has inaccuracies (not corrected in errata) and underspecified parts.
Ah, thanks for the link. For some reason that link doesn't turn up in google search for me, however hard I try. Of course the ISO one is also authoritative, but not free.
Oh, mea culpa. Honestly I just found the opening page and didn't notice it needed payment to get to the rest of it. I naively assumed that since Adobe had published it with ISO's permission, it was free in both places.
No worries! How did you find the "opensource.adobe.com" link? I can't hit it with google, even with aggressive searches like "site:opensource.adobe.com filetype:pdf". And I can't seem to navigate there from the main page.
You can have the numpad on the left, but I rarely saw keyboards like that. I saw some odd "left-handed" rubber dome keyboards, but that's it. You can also have a distinct numpad and put it anywhere.
This is why I use TKLs. I use a separate Leopold mechanical numpad placed on the left, so that the home row keys are more or less centered in my keyboard tray and under my monitor.
Also much nicer for playing Civ and other games that don't use WASD for camera control.
Sometimes the bottleneck is on the server end, and often they throttle throughput per connection. Some download mangers allow you to download the same file through multiple connections and range request. Having said that I think it's a little bit rude to work around the intended throughput limitation.
My impression is that arithmetic coding is the inverse. You have N symbols with different known probabilities, and you turn it into a stream of 1/2 probability random bits.
edit: On second thought this is probably a bijection and you can call it "arithmetic coding" in either direction.
As far as I can tell, arithmetic coding needs both a compressor and a decompressor. Otherwise it's relatively useless in eg your fancy video file format.
bits of entropy from 1000 coin flips, where "p" is the probablity of flipping heads.
Neumann's method generates 1000/(p(1-p)) bits of entropy from 1000 coin flips. The theoretical maximum is
-1000*log_2(p^p * (1-p)^(1-p))
but it requires knowing "p" exactly. This method is close to the theoretical maximum. I didn't plug in numbers, or analyise further, but it's far better than Neumann's method.
One obvious drawback is that you have to flip the coin a 1000 times to produce the first unbiased random bit, while Neumann's method starts producing bits much earlier.
> One obvious drawback is that you have to flip the coin a 1000 times to produce the first unbiased random bit, while Neumann's method starts producing bits much earlier.
Definitely. Though you could fix that problem relatively easily.
I think you might even be able to run von Neumann's method first, but store the coin flips; and then once you've got enough stored, extract a few more bits from the already used flips.
Perhaps like this:
When you do two flips, you add one of three possible tokens to your list:
'double-heads', 'double-tails' or 'mixed'.
Crucially, you only store 'mixed' and not whether it was 'head-tails' or 'tails-heads' because that information was already used to produce the von-Neuman-bit.
After your list has 1000 entries, you run an algorithm a bit like what I originally described to extract bits. The complication is that the table you construct has all possibilities of shuffling a fixed number of 'double-heads', 'double-tails' or 'mixed' tokens.
It feels like an awkward middle ground. Like this method has a limited entropy output for the first 2000 coin flips (first 1000 double-heads/double-tails/mixed entries), and then suddenly it adds back a ton of lost entropy.
An other commenter linked to some papers for asymptotically optimal entropy generation, I wonder if there is more of a streaming method there. It feels like there has to be, even maybe after a slow start. My naive intuition is that after 1000000 coin flips you have a good idea what p is, and then you can basically do arithmetic coding from there. Of course a theoretically correct method can't do exactly this, but it might asymptotically approach it.
Oh, if you want something practical, the approach that Linux's /dev/random takes is probably the one to go.
/dev/random being unbiased relies on some assumptions about cryptography; but in practice these assumptions are at least as well-founded as our assumption that our coin flips are independent.
Look at some of the papers mentioned in other comments on this submission. There are (near) optimal streaming methods.
There are some problems of the spec though, and navigation is not the most pressing one. The spec is huge, support for less used parts is spotty in various PDF readers. It also has inaccuracies (not corrected in errata) and underspecified parts.