Errata

There is a subtle bug in the implementation of the turns() function in Example 2-1. The calculation of the midpoint will overflow to a negative integer whenever low + high is larger than 2^31 - 1 (i.e. Integer.MAX_VALUE).

So, for example, we have:

turns(1, 1, 100) = 6

but if we offset n, low, and high by a constant, we get a different answer:

turns(1073742801, 1073742801, 1073742900) = 2

Note that these arguments are in the neighborhood of 0.5 * Integer.MAX_VALUE, and not exceptional.

Instead of calculating the midpoint this way,

int mid = (low + high)/2;

instead use

int mid = low + ((high - low) / 2);

Don't worry, you're in good company:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

double firstAngle = ... should be '- lowestY' and not '-lowest'.
Same with the next line starting with 'double lastAngle ='.

In figure 4-8 for Median Sort, line 5, where it says:

for left=0 to mid-1 do

it should say instead:

for i=0 to mid-1 do

In line 4 of the extract function in Figure 4-18 on p. 94, the line is
"for m = 1 to size(B[i]) do"

However, should this be "for m = 0 to size(B[i]) - 1 do"?

Since B[i] is an array, the first element starts at index 0, not index 1. So if we use m = 1, the first element in bucket B[i] at index 0 is never assigned to the array A. I think we need to start with m = 0 if we are to assign each element in bucket B[i] to array A...

Author claims that the linked list implementation is about 30-40% faster what IMHO is not true.
Array is the best container for small number of elements. Linked list is able to outperform an array only when dealing with huge number of elements. One of the reason is that a linked list isn't cache friendly.
Now, the algorithm assumes uniform distribution. Consequently, each bucket shall contain single element on average. In this situation, an ordinary array should be the best choice. I compiled and ran the code and I was surprised. The implementation with linked list was better. I went through source code and I found this in the array based implementation:
#define BUCKET SIZE 16
Allocating memory for 16 elements make no sense if we expect one element per bucket on average. I changed it to 2 and reran my test:
#define BUCKET SIZE 2
As I suspected, the array based implementation is better.
Here are my results:

Linked list:
N =2000, time=0
N =4000, time=0
N =8000, time=0
N =16000, time=1
N =32000, time=2
N =64000, time=7
N =128000, time=18
N =256000, time=44
N =512000, time=100
N =1024000, time=215
N =2048000, time=448
N =4096000, time=930
N =8192000, time=1837
N =16384000, time=4064
N =32768000, time=8641

Array:
N =2000, time=0
N =4000, time=0
N =8000, time=2
N =16000, time=2
N =32000, time=2
N =64000, time=5
N =128000, time=17
N =256000, time=38
N =512000, time=81
N =1024000, time=172
N =2048000, time=357
N =4096000, time=743
N =8192000, time=1414
N =16384000, time=3135
N =32768000, time=6584

It says the final value of ix identifies the index value which the missing element can be inserted. It should be the 'low' index.

If array [1,2,3,4] and value to look for is '5', before method returns false high=3,ix=3,low=4. 'ix' thereby cannot be the index.

Line 135 of the provided source code for algs.model.searchtree.debug.DepthFirstSearch.java has an error on line 135:

return new Solution (initial, n, debug);

The code should be:

return new Solution (initial, successor, debug);

The consequence of this minor technical mistake is that the solution returned is missing the final move.

The corresponding line in the book is the third from the bottom (not counting blanks and closing brackets). It's correct there and in the algs.model.searchtree.DepthFirstSearch.