4 files changed, 17 insertions, 17 deletions

diff --git a/doc/source/user/c-info.how-to-extend.rst b/doc/source/user/c-info.how-to-extend.rst
index 5901ce3e3..db6c8e118 100644
--- a/doc/source/user/c-info.how-to-extend.rst
+++ b/doc/source/user/c-info.how-to-extend.rst
@@ -255,7 +255,7 @@ Reference counting
 
 The biggest difficulty when writing extension modules is reference
 counting. It is an important reason for the popularity of f2py, weave,
-pyrex, ctypes, etc.... If you mis-handle reference counts you can get
+Cython, ctypes, etc.... If you mis-handle reference counts you can get
 problems from memory-leaks to segmentation faults. The only strategy I
 know of to handle reference counts correctly is blood, sweat, and
 tears. First, you force it into your head that every Python variable
diff --git a/doc/source/user/c-info.python-as-glue.rst b/doc/source/user/c-info.python-as-glue.rst
index 6ce266859..985d478e0 100644
--- a/doc/source/user/c-info.python-as-glue.rst
+++ b/doc/source/user/c-info.python-as-glue.rst
@@ -1385,7 +1385,7 @@ Simplified Wrapper and Interface Generator (SWIG) is an old and fairly
 stable method for wrapping C/C++-libraries to a large variety of other
 languages. It does not specifically understand NumPy arrays but can be
 made useable with NumPy through the use of typemaps. There are some
-sample typemaps in the numpy/doc/swig directory under numpy.i along
+sample typemaps in the numpy/tools/swig directory under numpy.i together
 with an example module that makes use of them. SWIG excels at wrapping
 large C/C++ libraries because it can (almost) parse their headers and
 auto-produce an interface. Technically, you need to generate a ``.i``
diff --git a/doc/source/user/install.rst b/doc/source/user/install.rst
index 18e036ab0..9d6f61e65 100644
--- a/doc/source/user/install.rst
+++ b/doc/source/user/install.rst
@@ -11,9 +11,9 @@ installable binary package for your operating system.
 Windows
 -------
 
-Good solutions for Windows are, The Enthought Python Distribution `(EPD)
-<http://www.enthought.com/products/epd.php>`_ (which provides binary
-installers for Windows, OS X and Redhat) and `Python (x, y)
+Good solutions for Windows are, `Enthought Canopy
+<https://www.enthought.com/products/canopy/>`_ (which provides binary
+installers for Windows, OS X and Linux) and `Python (x, y)
 <http://www.pythonxy.com>`_. Both of these packages include Python, NumPy and
 many additional packages.
 
diff --git a/doc/source/user/whatisnumpy.rst b/doc/source/user/whatisnumpy.rst
index 1c3f96b8b..cd74a8de3 100644
--- a/doc/source/user/whatisnumpy.rst
+++ b/doc/source/user/whatisnumpy.rst
@@ -86,14 +86,14 @@ code.  In NumPy
   c = a * b
 
 does what the earlier examples do, at near-C speeds, but with the code
-simplicity we expect from something based on Python (indeed, the NumPy
-idiom is even simpler!).  This last example illustrates two of NumPy's
+simplicity we expect from something based on Python. Indeed, the NumPy
+idiom is even simpler!  This last example illustrates two of NumPy's
 features which are the basis of much of its power: vectorization and
 broadcasting.
 
 Vectorization describes the absence of any explicit looping, indexing,
 etc., in the code - these things are taking place, of course, just
-"behind the scenes" (in optimized, pre-compiled C code).  Vectorized
+"behind the scenes" in optimized, pre-compiled C code.  Vectorized
 code has many advantages, among which are:
 
 - vectorized code is more concise and easier to read
@@ -104,25 +104,25 @@ code has many advantages, among which are:
   (making it easier, typically, to correctly code mathematical
   constructs)
 
-- vectorization results in more "Pythonic" code (without
-  vectorization, our code would still be littered with inefficient and
+- vectorization results in more "Pythonic" code. Without
+  vectorization, our code would be littered with inefficient and
   difficult to read ``for`` loops.
 
 Broadcasting is the term used to describe the implicit
 element-by-element behavior of operations; generally speaking, in
-NumPy all operations (i.e., not just arithmetic operations, but
-logical, bit-wise, functional, etc.) behave in this implicit
+NumPy all operations, not just arithmetic operations, but
+logical, bit-wise, functional, etc., behave in this implicit
 element-by-element fashion, i.e., they broadcast.  Moreover, in the
 example above, ``a`` and ``b`` could be multidimensional arrays of the
 same shape, or a scalar and an array, or even two arrays of with
-different shapes.  Provided that the smaller array is "expandable" to
+different shapes, provided that the smaller array is "expandable" to
 the shape of the larger in such a way that the resulting broadcast is
-unambiguous (for detailed "rules" of broadcasting see
-`numpy.doc.broadcasting`).
+unambiguous. For detailed "rules" of broadcasting see
+`numpy.doc.broadcasting`.
 
 NumPy fully supports an object-oriented approach, starting, once
 again, with `ndarray`.  For example, `ndarray` is a class, possessing
-numerous methods and attributes.  Many, of it's methods mirror
-functions in the outer-most NumPy namespace, giving the programmer has
+numerous methods and attributes.  Many of its methods mirror
+functions in the outer-most NumPy namespace, giving the programmer
 complete freedom to code in whichever paradigm she prefers and/or
 which seems most appropriate to the task at hand.