[pypy-commit] extradoc extradoc: More English improvements and a few commas.

[edelsohn]

Author: edelsohn
Branch: extradoc
Changeset: r4017:15a3491e715a
Date: 2012-01-10 13:44 -0500
http://bitbucket.org/pypy/extradoc/changeset/15a3491e715a/

Log:	More English improvements and a few commas.

diff --git a/blog/draft/laplace.rst b/blog/draft/laplace.rst
--- a/blog/draft/laplace.rst
+++ b/blog/draft/laplace.rst
@@ -38,7 +38,7 @@
 with ``gcc 4.4.5`` at ``-O3``.
 
 A straightforward version of those in Python is implemented in ``laplace.py``
-using respectively ``inline_slow_time_step`` and ``slow_time_step``.
+using, respectively, ``inline_slow_time_step`` and ``slow_time_step``.
 ``slow_2_time_step`` does the same thing, except it copies arrays in-place
 instead of creating new copies.
 
@@ -63,7 +63,7 @@
 independent. The results are in the same ballpark as the C versions --
 **15% - 170%** slower, but the algorithm
 one chooses matters more than the language. By comparison, the slow versions
-take about **5.75s** each on CPython 2.6 per iteration, and by estimation,
+take about **5.75s** each on CPython 2.6 per iteration and, by estimation,
 are about **200x** slower than the PyPy equivalent, if I had the patience to
 measure the full run.
 
@@ -78,7 +78,7 @@
   u[1:-1, 1:-1] = ((u[0:-2, 1:-1] + u[2:, 1:-1])*dy2 +
                          (u[1:-1,0:-2] + u[1:-1, 2:])*dx2)*dnr_inv
 
-We need 3 arrays here - one is an intermediate (PyPy only needs one, for all of
+We need 3 arrays here -- one is an intermediate (PyPy only needs one, for all of
 those subexpressions), one is a copy for computing the error, and one is the
 result. This works automatically because in NumPy ``+`` or ``*`` creates an
 intermediate, while NumPyPy avoids allocating the intermediate if possible.
@@ -92,7 +92,7 @@
 
 except the copy is now explicit rather than implicit.
 
-``numeric_3_time_step`` does the same thing, but notices one doesn't have to copy
+``numeric_3_time_step`` does the same thing, but notice one doesn't have to copy
 the entire array, it's enough to copy the border pieces and fill rest with
 zeros::
 
@@ -156,13 +156,13 @@
 | numeric 5             | 9.3ms       | 21ms           |
 +-----------------------+-------------+----------------+
 
-We think that these preliminary results are pretty good, they're not as fast as
+We think that these preliminary results are pretty good. They're not as fast as
 the C version (or as fast as we'd like them to be), but we're already much
-faster than NumPy on CPython, almost always by more than 2x on this relatively
-real-world example. This is not the end though, in fact it's hardly the
+faster than NumPy on CPython -- almost always by more than 2x on this relatively
+real-world example. This is not the end, though. In fact, it's hardly the
 beginning! As we continue work, we hope to make even more use of the
-high level information that we have. Looking at the generated assembler by
-gcc in this example, it's pretty clear we can outperform it, thanks to better
+high level information that we have. Looking at the assembler generated by
+gcc for this example, it's pretty clear we can outperform it thanks to better
 aliasing information and hence better possibilities for vectorization.
 Stay tuned.