pep-material: comparison handouts/pep-ho.tex

equal deleted inserted replaced

-:acaf2099406a
+:0c2481cd8b1c
 This kind of running code uses a single core of your CPU and goes as
 fast as your CPU frequency, also called clock-speed, allows. The problem
 is that this clock-speed has not much increased over the past decade and
 no dramatic increases are predicted for any time soon. So you are a bit
 stuck. This is unlike previous generations of developers who could rely
-upon the fact that every 2 years or so their code would run twice as
+upon the fact that approximately every 2 years their code would run
-fast  because the clock-speed of their CPUs got twice as fast.
+twice as fast  because the clock-speed of their CPUs got twice as fast.
 Unfortunately this does not happen any more nowadays. To get you out of
 this dreadful situation, CPU producers pile more and more cores into
 CPUs in order to make them more powerful and potentially make software
 faster. The task for you as developer is to take somehow advantage of
 these cores by running as much of your code as possible in parallel on
 as many cores you have available (typically 4 in modern laptops and
-sometimes much more on high-end machines). In this situation,
+sometimes much more on high-end machines). In this situation
 \textit{mutable} variables like \texttt{i} above are evil, or at least a
 major nuisance: Because if you want to distribute some of the
 loop-iterations over the cores that are currently idle in your system,
 you need to be extremely careful about who can read and overwrite the
 variable \texttt{i}.\footnote{If you are of the mistaken belief that
 \noindent The \code{if}-condition in this for-comprehension filters out
 all pairs where the sum is not even (therefore \code{(1, 2)}, \code{(2,
 1)} and \code{(3, 2)} are not in the result because their sum is odd).
-To sum up, maps (or for-comprehensions) transform one collection into
+To summarise, maps (or for-comprehensions) transform one collection into
 another. For example a list of \code{Int}s into a list of squares, and
 so on. There is no need for for-loops in Scala. But please do not be
 tempted to write anything like
 \begin{lstlisting}[numbers=none]
 \subsection*{Aggregates}
 There is one more usage of for-loops in Java, C/C++ and the like:
 sometimes you want to \emph{aggregate} something about a list, for
-example summing up all its elements. In this case you cannot use map,
+example summing up all its elements. In this case you cannot use maps,
 because maps \emph{transform} one data collection into another data
 collection. They cannot be used to generate a single integer
-representing an aggregate. So how is this done in Scala? Let us
+representing an aggregate. So how is this kind of aggregation done in
-suppose you want to sum up all elements from a list. You might
+Scala? Let us suppose you want to sum up all elements from a list. You
-be tempted to write something like
+might be tempted to write something like
 \begin{lstlisting}[numbers=none]
 var cnt = 0
 for (n <- (1 to 8).toList) {
 cnt += n
 \noindent
 and indeed this is accepted Scala code and produces the expected result,
 namely \code{36}, \textbf{BUT} this is imperative style and not
 permitted in PEP. It uses a \code{var} and therefore violates the
-immutability property I ask for in your code. Sorry.
+immutability property I ask for in your code. Sorry!
 So how to do that same thing without using a \code{var}? Well there are
 several ways. One way is to define the following recursive
 \code{sum}-function:
 if (xs.isEmpty) 0 else xs.head + sum(xs.tail)
 \end{lstlisting}
 \noindent
 You can then call \code{sum((1 to 8).toList)} and obtain the same result
-without a mutable variable or for-loop. Obviously for simple things like
+without a mutable variable and without a for-loop. Obviously for simple things like
 sum, you could have written \code{xs.sum} in the first place. But not
 all aggregate functions are pre-defined and often you have to write your
 own recursive function for this.

changeset 278	0c2481cd8b1c
parent 277	acaf2099406a
child 301	c3b33c709696