The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted by |
Date Submitted |
| Printed |
Page 69
middle, the code snippet |
In chapter 3, Lists and Tuples, you present the function `binary_search(needle, haystack)`. This function loops infinitely in one scenario, and that is when needle < min(haystack).
You are covering the scenario of `needle > max(haystack)` (by defining `imin=midpoint+1` in that flow), so I thought that you might have accidentally missed the other scenario, but maybe this was done on purpose, in which case you can ignore my email.
submitted by ian on behalf of enriqueortizcasillas@gmail.com
|
Ian Ozsvald |
Oct 02, 2023 |
| Printed |
Page 4
First paragraph (second line on the page) |
This is in the 2nd edition.
Author says, "Finally, and most importantly for the higher-level programmer, there is the prevalence of multicore architecture. These architectures include multiple CPUs within the same unit..."
I believe the author means multiple cores, not multiple CPUs.
|
Jenna Kwon |
Dec 26, 2020 |
| PDF |
Page 106
last para before Example 6-4 |
",The global variable grid_shape designates"
... sentence starts with a comma.
|
Yury V. Zaytsev |
Aug 12, 2014 |
| PDF |
Page 139
1st para after "Using a C Compiler" |
"Cython uses gcc; Shed Skin uses g++."
This is technically not fully correct; Cython can output both C or C++ depending on your needs. You can select the right mode using a pragma, keyword argument or a command line option "language". Shed Skin, conversely, is only capable of generating C++ code (by design).
Suggest to change this to something like "Cython will generate C code by default (with optional support for C++); Shed Skin is only able to produce C++ code." instead of focusing on compilers.
|
Yury V. Zaytsev |
Aug 11, 2014 |
| PDF |
Page 112
2nd para |
"context-switches and CPU-migrations tell us about how the program was moved
around on the motherboard."
I'm not sure that this statement is fair, if by "motherboard" you actually mean a piece of computer hardware to which the components of the computer are attached.
As you explain later in the text, "context-switch" happens when your application is pre-empted by the process scheduler, which might happen because it's no longer runnable, such as waiting for I/O or a sync operation to complete, or maybe (very often) just in order to ensure a fair distribution of CPU time among the processes with the same level of niceness. In any case, the program doesn't physically move around on the motherboard, and especially if it's being pre-empted due to exceeding its timeslice.
In the case that a CPU-migration occurs, nothing really physically moves either, especially if it's a migration between logical CPUs, which might be different cores on one die, or even different hardware threads in one core.
I would suggest to replace "motherboard" with something like "process scheduler queue", or otherwise reformulate this sentence to make it less inducing of unfair criticism :-)
|
|
Aug 11, 2014 |
| PDF |
Page 97
2nd para |
"Another nicety about organizing analysis this way is it allows us to do more expansive calculations easily, without having to rework large parts of the code."
Here, "expansive calculations" sounds a bit weird to me. Maybe you actually meant "expensive"? If so, then I'm not sure that's really the point. In the case that, in fact, you meant something else, then I think that "expansive" is not a good term, because you contrast the calculation of something in chunks of 5 days versus a moving average of 1 day, and I can't really see how one is more *expansive* (but also *expensive*) of a calculation than another.
Maybe put it like "it allows us to plug in different types of calculations easily", or something along these lines?
|
|
Aug 11, 2014 |
| PDF |
Page 101
Figure 6-1 |
Vertical axis labels look crowded. Consider putting concentration tick marks at intervals of 0.25, rather than 0.2.
It is nice, though, to be able to read the axes without having to squint.
|
dml |
Jul 03, 2014 |