Historical errata for Data Crunching

The horizontal bracket showing the extent of group 1 is too wide: it should not include the final “(.*)” of the regular expression.

The horizontal bracket showing the extent of group 2 is too wide: it should not include the trailing “*)”, which is actually the end of group 1.

“if val > 127” in code fragment should be “if val > 255”

The last “\\d{3}” in each RE\t should be “\\d{4}” (to capture the last four digits in each phone number).

All implementations of Java in widespread use today will optimize repeated string concatenation, so that “abc”“def”“ghi” doesn’t allocate an unnecessary intermediate buffer.

The description for the SQL type DECIMAL should be “…one that has a fixed number of digits…”

The methods for storing integers as binary data are namend packVec() and unpackVec(), but the text relates to them as packIntVec() and unpackIntVec() respectively.

The first paragraph of section 6.6 should end with “…who didn’t understand that data is for grepping”.

The listing of the Regular Expressions search pattern contains an error - at least according to running the program on page 48 in python22 on windows. Here are my results:

’’ a b Xab aXb abX ab aXXXb a.b
’’ + + + + + + + + +
a - + - + + + + + +
a.b - - - - + - - - +
a?b - - + + + + + + +
a*b - - + + + + + + +
a+b - - - + - + + - -
a\\.b - - - - - - - - +
a\\+b - - - - - - - - -
.*ab - - - + - + + - -

The error is that obviously “a?b” matches “aXb” when searching, as it should match the same as “b” or “ab”.

The error propagates down page 49 in the 3rd paragraph. The last sentence reads: “or aXb (the a and the b aren’t adjacent).” Well, they’re not and they don’t have to be.

The following paragraph on the other hand is perfect even though the description clashes with the faulty table and the description just provided.

First paragraph reads:
“Bytes in the range 0-255 (hex 0000-007f)”
Should read:
“Bytes in the range 0-127 (hex 0000-007f)”

2nd paragraph end with:
“And once again, the only way to solve the problem is case by case (Figure 3.3).”

There are other options, e.g. the pattern “<[^>]*>” which matches anything enclosed in <>-brackets, that is: start, end, and selfclosing tags.

Ok, this solution does not use as much reg.exp. as figure 3.3, but whenever there are multiple solutions neither of these can be considered “the only one”.

In the “Joe Asks” block it says:
“15 (base 10) (negative acknowledge)”
Which should be:
“15 (base 16) (negative acknowledge)”

Near the bottom it says:
“32-bit integer 1027(base 10) (which is 0x0407 (base 16))”

Should be:
“32-bit integer 1031(base 10) (which is 0x0407 (base 16))”

The query “Find people in 904 or 905, but not both.” is incorrect.

SELECT Person.FirstName, Person.LastName
FROM Person, Assigned
WHERE (Person.EmpId = Assigned.EmpId)
AND ((Assigned.ProjId = 904) OR (Assigned.ProjId = 905))
AND (Assigned.ProjId NOT IN
(SELECT A.ProjId
FROM Assigned A, Assigned B
WHERE (A.ProjId = 904) AND (B.ProjId = 905)));

is a clumsy way of saying: “People not assigned to project 904”

And the result is not the same as “Select people who are assigned to exactly one project” - which it should be, as stated in the text.

The correct query is:
— Find people in 904 or 905, but not both.
SELECT Person.FirstName, Person.LastName
FROM Person, Assigned
WHERE (Person.EmpId = Assigned.EmpId)
AND ((Assigned.ProjId = 904) OR (Assigned.ProjId = 905))
AND (Person.EmpId NOT IN
(SELECT A.EmpId
FROM Assigned AS A, Assigned AS B
WHERE (A.ProjId = 904) AND (B.ProjId = 905) AND A.EmpId = B.EmpId));

The result is:
Dave|Thomas
Andy|Hunt
Grace|Hopper
Chuck|Babbage

which, of course, is not the result stated in the book.

In “Joe Asks…” you mix up the counting in the last paragraph. Your writing “The third is mostly..” probably meant “The fourth is mostly..”. An explanation for the third bullet would be nice too.

findhome.sh & it’s output is incorrect

uid is the entire line
echo $uid echo’s this not just the uid, and using this to grep /etc/passwd ain’t pretty

To the best of my knowledge, the domain component of an email address has to contain two segments, e.g. a@b.c is OK but a@b isn’t. Your RE matches a@b.

If I’m right, the correct RE is more like:

([\\w.-]@([\\w]\\.)[\\w])(.*)

(That includes your group 3 for matching the rest of the line.)

Great book!

You have included a CustId column in the Assigned table. I don’t think it is ever used from there, and it really shouldn’t be there because it is not normalized - you can get it from the Project table, based on the Projid.

Also, this is very minor but your capitalization of Id fields is inconsistent. In a couple of places on that page CustId has the “I” capitalized, and in others it isn’t. In Empid and Projid the “i” is never capitalized.

According to SQL standards, as I understand them, the statement near the bottom of the page that the condition CustId <> 1027 will match rows where CustId is NULL is wrong. Thus, the alternate query at the bottom of the page is not required. NULL does not compare to any value, using any comparison operator. Thus, NULL = 0, NULL <> 0, NULL < 0, and NULL > 0 all evaluate to false.

Page 23
Near the middle it says:
… keys didn’t actually have to be unique within sections.
Should be:
… keys only have to be unique within each section.

And also remove “WindowSize=1280,1024” in the [View]listing that follows this paragraph

Near the bottom it says:
It will read from all the files the user specifies (…), unless the -o argument is used, …

Should be:
It will read from all the files the user specifies (…) and write to stdout, unless the -o argument is used, …

In the first paragraph that starts on the page, “/project/*/author” will match only authors of tickets. It will NOT match authors of comments. To match authors of comments, “/project/*/*/author” works. To match authors of both tickets and comments, use “/project//author.”

Base-64 Encoding

The order of the characters for base64 is not arbitrary. The author wonders, why the list of characters doesn’t start with digits 0-9. This is because it is not really a number system like binary, decimal or hexa-decimal system, but simply the 6-bit value added to the ASCII-value of the letter ‘A’. So the “encoding characters” are exactly used as ni the ASCII standard.

A simply base-64 conversion would be
int _6bitval = —-
char base64Val = ‘A’ + _6bitval;

This leads to all characters being printable in the 7-bit ASCII-encoding.

“And do the CMPND and AUTHOR lines..”
CMPND should be COMPND

The PDB URL has suffered from link rot.

Under section “6.1 Simple Queries”.
Original Text: “[…] To get them, we need to know which table to examine, and which columns to get from it. The answer is Person; the answer to the second, FirstName and LastName”"
Figure 6.1, FirstName and LastName under the “Person” table are rows, not columns.
My love for this book is the motivation for this errata submission. Many thanks to Mr. Wilson and Pragmatic Programmers for the wonder publication.

Warmest Regards

+z$8frZdyL%68pSU/:>w<:E3.lG-!XIB

Shell script at top and text at bottom mention using cut -f 5 to extract the fifth field, but as field numbers start from 1, the sixth field contains the user’s home directory.

Trying to read the .mobi version using the Kindle for PC reader, it seems that all pages consisting of only source code show black boxes instead of words.

I put a screenshot on (since hyperlinks aren’t allowed in this description):

www dot flickr dot com slash photos slash 37513585@N00 slash 7896207608

Pages that don’t consist of only source code appear fine. I have never noticed this in any other Kindle book on the PC reader.