Merge pull request #8792 from jwilk/spelling

DOC: Fix typos

48 files changed, 105 insertions, 105 deletions

diff --git a/doc/CAPI.rst.txt b/doc/CAPI.rst.txt
index 7c9f10b5b..7da36ad2e 100644
--- a/doc/CAPI.rst.txt
+++ b/doc/CAPI.rst.txt
@@ -62,7 +62,7 @@ This is a very flexible function.
 ``subtype`` : ``PyTypeObject *``
     The subtype that should be created (either pass in
     ``&PyArray_Type``,  or ``obj->ob_type``,
-    where ``obj`` is a an instance of a subtype (or subclass) of
+    where ``obj`` is an instance of a subtype (or subclass) of
     ``PyArray_Type``).
 
 ``descr`` : ``PyArray_Descr *``
@@ -184,7 +184,7 @@ function calls still remain but they are loose wrappers around the
         not it is safe.
 
 ``context`` : ``PyObject *``
-    If the Python object ``op`` is not an numpy array, but has an
+    If the Python object ``op`` is not a numpy array, but has an
     ``__array__`` method, context is passed as the second argument to
     that method (the first is the typecode). Almost always this
     parameter is ``NULL``.
diff --git a/doc/HOWTO_RELEASE.rst.txt b/doc/HOWTO_RELEASE.rst.txt
index bad3e22d8..52c8ff56a 100644
--- a/doc/HOWTO_RELEASE.rst.txt
+++ b/doc/HOWTO_RELEASE.rst.txt
@@ -86,7 +86,7 @@ The same gcc version is used as the one with which Python itself is built on
 each platform. At the moment this means:
 
 * OS X builds on travis currently use `clang`.  It appears that binary wheels
-  for OSX >= 10.6 can be safely built from from the travis-ci OSX 10.9 VMs
+  for OSX >= 10.6 can be safely built from the travis-ci OSX 10.9 VMs
   when building against the Python from the Python.org installers;
 * Windows builds use the MSVC version corresponding to the Python being built
   against;
diff --git a/doc/f2py/FAQ.txt b/doc/f2py/FAQ.txt
index 2481b5b95..979a20179 100644
--- a/doc/f2py/FAQ.txt
+++ b/doc/f2py/FAQ.txt
@@ -300,7 +300,7 @@ Q: How F2PY distinguishes from Pyfort?
 
 F2PY and Pyfort have very similar aims and ideology of how they are
 targeted. Both projects started to evolve in the same year 1999
-independently. When we discovered each others projects, a discussion
+independently. When we discovered each other's projects, a discussion
 started to join the projects but that unfortunately failed for
 various reasons, e.g. both projects had evolved too far that merging
 the tools would have been impractical and giving up the efforts that
@@ -493,7 +493,7 @@ __ http://www.prism.enes.org/WPs/WP4a/Slides/pyfort/pyfort.html
 
 __ http://www.astro.uni-bonn.de/~heith/lecture_pdf/friedrich5.pdf
 
-+ Wiki topics on `Wrapping Tools`__ and `Wrapping Bemchmarks`__ for Climate
++ Wiki topics on `Wrapping Tools`__ and `Wrapping Benchmarks`__ for Climate
   System Center at the University of Chicago.
 
 __ https://geodoc.uchicago.edu/climatewiki/DiscussWrappingTools
diff --git a/doc/f2py/HISTORY.txt b/doc/f2py/HISTORY.txt
index 4326e4852..5ab09ae1a 100644
--- a/doc/f2py/HISTORY.txt
+++ b/doc/f2py/HISTORY.txt
@@ -49,7 +49,7 @@ Release 2.46.243
   - Fixed FORTRANAME typo, relevant when wrapping scalar functions with
     ``--no-wrap-functions``.
   - Improved failure handling for callback functions.
-  - Fixed bug in writting F90 wrapper functions when a line length
+  - Fixed bug in writing F90 wrapper functions when a line length
     is exactly 66.
 
 * cfuncs.py
@@ -336,7 +336,7 @@ Release 2.39.235_1660
 
 * f90mod_rules.py
 
-  - Splitted generated documentation strings (to avoid MSVC issue when
+  - Split generated documentation strings (to avoid MSVC issue when
     string length>2k)
 
   - Ignore ``private`` module data.
@@ -505,7 +505,7 @@ Release 2.35.229-1505
     len(vars) is large.
   - Fixed callback string argument detection.
   - Fixed evaluating expressions: only int|float expressions are
-    evaluated succesfully.
+    evaluated successfully.
 
 * docs
 
@@ -748,7 +748,7 @@ Older Releases
 
 ::
 
- *** Fixed copying of non-contigious 1-dimensional arrays bug.
+ *** Fixed copying of non-contiguous 1-dimensional arrays bug.
     (Thanks to Travis O.).
 
 
diff --git a/doc/f2py/Makefile b/doc/f2py/Makefile
index 2f241da0a..2dd168fad 100644
--- a/doc/f2py/Makefile
+++ b/doc/f2py/Makefile
@@ -19,7 +19,7 @@ TTHFILTER3 = sed -e "s/{{}\\\verb@/\\\texttt{/g" | sed -e "s/@{}}/}/g" | $(TTH)
 TTHMISSING = "\
 ***************************************************************\n\
 Warning:        Could not find tth (a TeX to HTML translator)  \n\
-                or an error arised was by tth\n\
+                or an error was arisen by tth\n\
 You can download tth from http://hutchinson.belmont.ma.us/tth/  \n\
 or\n\
 use your favorite LaTeX to HTML translator on file tmp_main.tex\n\
diff --git a/doc/f2py/README.txt b/doc/f2py/README.txt
index 971183bb0..76e1fed97 100644
--- a/doc/f2py/README.txt
+++ b/doc/f2py/README.txt
@@ -305,7 +305,7 @@ __ https://github.com/numpy/numpy/blob/master/numpy/f2py/docs/HISTORY.txt
  Mailing list
 ===============
 
-A mailing list f2py-users@cens.ioc.ee is open for F2PY releated
+A mailing list f2py-users@cens.ioc.ee is open for F2PY related
 discussion/questions/etc.
 
 * `Subscribe..`__
diff --git a/doc/f2py/TESTING.txt b/doc/f2py/TESTING.txt
index a6df92c48..00817e48f 100644
--- a/doc/f2py/TESTING.txt
+++ b/doc/f2py/TESTING.txt
@@ -57,7 +57,7 @@ Tests
   where ``<type>`` is integer, real, logical, complex, or character.
   Test scripts options are described below.
 
-  A test is considered succesful if the last printed line is "ok".
+  A test is considered successful if the last printed line is "ok".
 
   If you get import errors like::
 
diff --git a/doc/f2py/bugs.tex b/doc/f2py/bugs.tex
index 699ecf530..bbfce0f9a 100644
--- a/doc/f2py/bugs.tex
+++ b/doc/f2py/bugs.tex
@@ -85,7 +85,7 @@ information on compilers and linkers that you use to the bug report.
   time and rewrote the tool from scratch. The most important result of
   this rewriting was the code that reads real Fortran codes and
   determines the signatures of the Fortran routines. The main
-  attention was payed in particular to this part so that the tool
+  attention was paid in particular to this part so that the tool
   could read arbitrary Fortran~77/90/95 codes. As a result, the other
   side of the tools task, that is, generating Python C/API functions,
   was not so great. In public, this version of the tool was called
diff --git a/doc/f2py/fortranobject.tex b/doc/f2py/fortranobject.tex
index 88a56835e..a30b4b6c9 100644
--- a/doc/f2py/fortranobject.tex
+++ b/doc/f2py/fortranobject.tex
@@ -52,7 +52,7 @@ determined in runtime providing a compiler independent solution.
 
 To use Fortran objects from Python in unified manner, \fpy introduces
 \texttt{PyFortranObject} to hold pointers of the Fortran objects and
-the corresponing wrapper functions.  In fact, \texttt{PyFortranObject}
+the corresponding wrapper functions.  In fact, \texttt{PyFortranObject}
 does much more: it generates documentation strings in run-time (for
 items in \texttt{COMMON} blocks and data in F90 modules), provides
 methods for accessing Fortran data and for calling Fortran routines,
diff --git a/doc/f2py/index.html b/doc/f2py/index.html
index 9f3720e68..f155b1c97 100644
--- a/doc/f2py/index.html
+++ b/doc/f2py/index.html
@@ -166,7 +166,7 @@ well. Additions to the list of platforms/compilers where
 <P>
 <em>Note:</em>
 Using Compaq Fortran
-compiler on Alpha Linux is succesful unless when
+compiler on Alpha Linux is successful unless when
 wrapping Fortran callback functions returning
 <code>COMPLEX</code>. This applies also for IRIX64.
 <P>
diff --git a/doc/f2py/multiarray/array_from_pyobj.c b/doc/f2py/multiarray/array_from_pyobj.c
index 237d16dbc..fba14ac71 100644
--- a/doc/f2py/multiarray/array_from_pyobj.c
+++ b/doc/f2py/multiarray/array_from_pyobj.c
@@ -3,7 +3,7 @@
  *
  * Description:
  * ------------
- * Provides array_from_pyobj function that returns a contigious array
+ * Provides array_from_pyobj function that returns a contiguous array
  * object with the given dimensions and required storage order, either
  * in row-major (C) or column-major (Fortran) order. The function
  * array_from_pyobj is very flexible about its Python object argument
diff --git a/doc/f2py/multiarray/fortran_array_from_pyobj.txt b/doc/f2py/multiarray/fortran_array_from_pyobj.txt
index e351e8e89..e0f383fbd 100644
--- a/doc/f2py/multiarray/fortran_array_from_pyobj.txt
+++ b/doc/f2py/multiarray/fortran_array_from_pyobj.txt
@@ -16,7 +16,7 @@ In the following I will use the following definitions:
 1) A matrix is a mathematical object that represents a collection of
    objects (elements), usually visualized in a table form, and one can
    define a set of various (algebraic,etc) operations for matrices.
-   One can think of a matrix as a defintion of a certain mapping:
+   One can think of a matrix as a definition of a certain mapping:
          (i) |--> A(i)
    where i belongs to the set of indices (an index itself can be a
    sequence of objects, for example, a sequence of integers) and A(i)
diff --git a/doc/f2py/oldnews.html b/doc/f2py/oldnews.html
index 0e09c032f..054643174 100644
--- a/doc/f2py/oldnews.html
+++ b/doc/f2py/oldnews.html
@@ -2,7 +2,7 @@
 <HTML>
 <HEAD>
 <META name="Author" content="Pearu Peterson">
-<!-- You may add here some keywords (comma separeted list) -->
+<!-- You may add here some keywords (comma separated list) -->
 <META name="Keywords" content="fortran,python,interface,f2py,f2py2e,wrapper,fpig">
 <TITLE>F2PY - Fortran to Python Interface Generator</TITLE>
 <LINK rel="stylesheet" type="text/css" href="/styles/userstyle.css">
diff --git a/doc/f2py/options.tex b/doc/f2py/options.tex
index 84d9410f8..4e67fb162 100644
--- a/doc/f2py/options.tex
+++ b/doc/f2py/options.tex
@@ -48,7 +48,7 @@ where
 \item[\texttt{<fortran files>}] --- are the paths to Fortran files or
   to signature files that will be scanned for \texttt{<fortran
     functions>} in order to determine their signatures.
-\item[\texttt{<fortran functons>}] --- are the names of Fortran
+\item[\texttt{<fortran functions>}] --- are the names of Fortran
   routines for which Python C/API wrapper functions will be generated.
   Default is all that are found in \texttt{<fortran files>}.
 \item[\texttt{only:}/\texttt{skip:}] --- are flags for filtering
diff --git a/doc/f2py/python9.tex b/doc/f2py/python9.tex
index fdcd32f46..524d61113 100644
--- a/doc/f2py/python9.tex
+++ b/doc/f2py/python9.tex
@@ -514,7 +514,7 @@ low-level names of module routines which makes it impossible (at
 least directly) to call such routines from C when using the MIPSpro 7
 C Compiler.
 
-In order to overcome this difficulty, FPIG introduces an unique
+In order to overcome this difficulty, FPIG introduces a unique
 solution: instead of using low-level symbols for calling Fortran
 module routines from C, the references to such routines are determined
 at run-time by using special wrappers. These wrappers are called once
diff --git a/doc/f2py/win32_notes.txt b/doc/f2py/win32_notes.txt
index 691cac26e..40b7d549a 100644
--- a/doc/f2py/win32_notes.txt
+++ b/doc/f2py/win32_notes.txt
@@ -4,7 +4,7 @@ My Setup:
 
 For Python/Fortran development, I run Windows 2000 and use the mingw32
 (www.mingw.org) set of gcc/g77 compilers and tools (gcc 2.95.2) to build python
-extensions.  I'll also ocassionally use MSVC for extension development, but
+extensions.  I'll also occasionally use MSVC for extension development, but
 rarely on projects that include Fortran code.  This short HOWTO describes how
 I use f2py in the Windows environment.  Pretty much everything is done from
 a CMD (DOS) prompt, so you'll need to be familiar with using shell commands.
@@ -41,12 +41,12 @@ automatically.  Here are the download steps:
 
         This will install f2py in the c:\python21\f2py2e directory.  It
         also copies a few scripts into the c:\python21\Scripts directory.
-        Thats all there is to installing f2py.  Now lets set up the environment
-        so that f2py is easy to use.
+        That's all there is to installing f2py.  Now let's set up the
+        environment so that f2py is easy to use.
 
-    4.  You need to set up a couple of environement variables.  The path
+    4.  You need to set up a couple of environment variables.  The path
         "c:\python21\Scripts" needs to be added to your path variables.
-        To do this, go to the enviroment variables settings page.  This is
+        To do this, go to the environment variables settings page.  This is
         where it is on windows 2000:
 
          Desktop->(right click)My Computer->Properties->Advanced->
diff --git a/doc/neps/datetime-proposal.rst b/doc/neps/datetime-proposal.rst
index f8e67340c..76c361f4f 100644
--- a/doc/neps/datetime-proposal.rst
+++ b/doc/neps/datetime-proposal.rst
@@ -598,7 +598,7 @@ There is a new ufunc C-API call to set the data for a particular
 function pointer (for a particular set of data-types) to be the list of arrays
 passed in to the ufunc.
 
-Array Intervace Extensions
+Array Interface Extensions
 --------------------------
 
 The array interface is extended to both handle datetime and timedelta
diff --git a/doc/neps/math_config_clean.rst b/doc/neps/math_config_clean.rst
index 26511d7bf..27c0adfa1 100644
--- a/doc/neps/math_config_clean.rst
+++ b/doc/neps/math_config_clean.rst
@@ -22,7 +22,7 @@ Current problems
 
 Currently, the math configuration mainly test for some math functions, and
 configure numpy accordingly. But instead of testing each desired function
-independantly, the current system has been developed more as workarounds
+independently, the current system has been developed more as workarounds
 particular platform oddities, using platform implicit knowledge. This is
 against the normal philosophy of testing for capabilities only, which is the
 autoconf philosophy, which showed the path toward portability (on Unix at
@@ -38,7 +38,7 @@ sizeof(double).
 
 Another example is the testing for set of functions using only one function: if
 expf is found, it is assumed that all basic float functions are available.
-Instead, each function should be tested independantly (expf, sinf, etc...).
+Instead, each function should be tested independently (expf, sinf, etc...).
 
 Requirements
 ============
@@ -52,12 +52,12 @@ Proposal
 ========
 
 We suggest to break any implicit assumption, and test each math function
-independantly from each other, as usually done by autoconf. Since testing for a
+independently from each other, as usually done by autoconf. Since testing for a
 vast set of functions can be time consuming, we will use a scheme similar to
 AC_CHECK_FUNCS_ONCE in autoconf, that is test for a set of function at once,
 and only in the case it breaks, do the per function check. When the first check
 works, it should be as fast as the current scheme, except that the assumptions
-are explicitely checked (all functions implied by HAVE_LONGDOUBLE_FUNCS would
+are explicitly checked (all functions implied by HAVE_LONGDOUBLE_FUNCS would
 be checked together, for example).
 
 Issues
diff --git a/doc/neps/missing-data.rst b/doc/neps/missing-data.rst
index 9dc509c53..00a6034f4 100644
--- a/doc/neps/missing-data.rst
+++ b/doc/neps/missing-data.rst
@@ -79,7 +79,7 @@ Unknown Yet Existing Data (NA)
 
 This is the approach taken in the R project, defining a missing element
 as something which does have a valid value which isn't known, or is
-NA (not available). This proposal adopts this behavior as as the
+NA (not available). This proposal adopts this behavior as the
 default for all operations involving missing values.
 
 In this interpretation, nearly any computation with a missing input produces
diff --git a/doc/neps/new-iterator-ufunc.rst b/doc/neps/new-iterator-ufunc.rst
index e62c910cf..7a9e7627c 100644
--- a/doc/neps/new-iterator-ufunc.rst
+++ b/doc/neps/new-iterator-ufunc.rst
@@ -413,7 +413,7 @@ parameter to control the layout of their output(s).
 
 The iterator can do automatic casting, and I have created a sequence
 of progressively more permissive casting rules.  Perhaps for 2.0, NumPy
-could adopt this enum as its prefered way of dealing with casting.::
+could adopt this enum as its preferred way of dealing with casting.::
 
     /* For specifying allowed casting in operations which support it */
     typedef enum {
@@ -943,7 +943,7 @@ Construction and Destruction
             If the operand is flagged as write-only and a copy is needed,
             an uninitialized temporary array will be created and then copied
             to back to ``op[i]`` on destruction, instead of doing
-            the unecessary copy operation.
+            the unnecessary copy operation.
 
         ``NPY_ITER_NBO``, ``NPY_ITER_ALIGNED``, ``NPY_ITER_CONTIG``
 
diff --git a/doc/neps/newbugtracker.rst b/doc/neps/newbugtracker.rst
index f4b029b47..5af633552 100644
--- a/doc/neps/newbugtracker.rst
+++ b/doc/neps/newbugtracker.rst
@@ -5,7 +5,7 @@ Replacing Trac with a different bug tracker
 :Author: David Cournapeau, Stefan van der Walt
 
 Some release managers of both numpy and scipy are becoming more and more
-disatisfied with the current development workflow, in particular for bug
+dissatisfied with the current development workflow, in particular for bug
 tracking. This document is a tentative to explain some problematic scenario,
 current trac limitations, and what can be done about it.
 
@@ -28,7 +28,7 @@ The workflow for a release is roughly as follows:
 
 Most of those tasks are quite inefficient in the current trac as used on scipy:
 
-        * it is hard to keep track of issues. In particular, everytime one goes
+        * it is hard to keep track of issues. In particular, every time one goes
           to trac, we don't really know what's new from what's not. If you
           think of issues as emails, the current situation would be like not
           having read/unread feature.
@@ -77,7 +77,7 @@ may solve some of the issues.
 
         * Multi-project support: we have three trac instances, one for scipy,
           one for numpy, one for scikits. Creating accounts, maintaining and
-          updating each of them is a maintainance burden. Nobody likes to do
+          updating each of them is a maintenance burden. Nobody likes to do
           this kind of work, so anything which can reduce the burden is a plus.
           Also, it happens quite frequently that a bug against numpy is filled
           on scipy trac and vice and versa. You have to handle this manually,
@@ -132,7 +132,7 @@ Pros:
         * Support most features (except xmlrpc ?). Multi-project, etc...
 
         * (subjective): I (cdavid) find the out-of-the-box experience with
-          redmine much more enjoyable. More informations are available easily,
+          redmine much more enjoyable. More information is available easily,
           less clicks, more streamlined. See
           http://www.redmine.org/wiki/redmine/TheyAreUsingRedmine for examples
 
diff --git a/doc/neps/ufunc-overrides.rst b/doc/neps/ufunc-overrides.rst
index 98380ee97..f0e51b90b 100644
--- a/doc/neps/ufunc-overrides.rst
+++ b/doc/neps/ufunc-overrides.rst
@@ -103,7 +103,7 @@ Returning ``NotImplemented`` to user should not happen. Moreover::
                         <3x3 sparse matrix of type '<class 'numpy.int64'>'
                     with 8 stored elements in Compressed Sparse Row format>]], dtype=object)
 
-Here, it appears that the sparse matrix was converted to a object array
+Here, it appears that the sparse matrix was converted to an object array
 scalar, which was then multiplied with all elements of the ``b`` array.
 However, this behavior is more confusing than useful, and having a
 ``TypeError`` would be preferable.
@@ -136,7 +136,7 @@ Here:
 
 The ufunc's arguments are first normalized into a tuple of input data
 (``inputs``), and dict of keyword arguments. If there are output
-arguments they are handeled as follows:
+arguments they are handled as follows:
 
 - One positional output variable x is passed in the kwargs dict as ``out :
   x``.
diff --git a/doc/neps/warnfix.rst b/doc/neps/warnfix.rst
index 93ef26488..4b0a2a56e 100644
--- a/doc/neps/warnfix.rst
+++ b/doc/neps/warnfix.rst
@@ -19,7 +19,7 @@ free.
 Warning flags
 =============
 
-Each compiler detects a diffferent set of potential errors. The baseline will
+Each compiler detects a different set of potential errors. The baseline will
 be gcc -Wall -W -Wextra. Ideally, a complete set would be nice:
 
 -W -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return
diff --git a/doc/release/1.12.0-notes.rst b/doc/release/1.12.0-notes.rst
index 9889abb42..58a570b54 100644
--- a/doc/release/1.12.0-notes.rst
+++ b/doc/release/1.12.0-notes.rst
@@ -239,7 +239,7 @@ unpredictable writes.
 ``axes`` keyword argument for ``rot90``
 ---------------------------------------
 The ``axes`` keyword argument in ``rot90`` determines the plane in which the
-array is rotated. It defaults to ``axes=(0,1)`` as in the originial function.
+array is rotated. It defaults to ``axes=(0,1)`` as in the original function.
 
 Generalized ``flip``
 --------------------
@@ -457,7 +457,7 @@ Improved precision of ``ndarray.mean`` for float16 arrays
 The computation of the mean of float16 arrays is now carried out in float32 for
 improved precision. This should be useful in packages such as Theano
 where the precision of float16 is adequate and its smaller footprint is
-desireable.
+desirable.
 
 
 Changes
@@ -476,7 +476,7 @@ Operations on np.memmap objects return numpy arrays in most cases
 Previously operations on a memmap object would misleadingly return a memmap
 instance even if the result was actually not memmapped.  For example,
 ``arr + 1`` or ``arr + arr`` would return memmap instances, although no memory
-from the output array is memmaped. Version 1.12 returns ordinary numpy arrays
+from the output array is memmapped. Version 1.12 returns ordinary numpy arrays
 from these operations.
 
 Also, reduction of a memmap (e.g.  ``.sum(axis=None``) now returns a numpy
diff --git a/doc/release/1.13.0-notes.rst b/doc/release/1.13.0-notes.rst
index 5f8c40cd2..27e1d65d0 100644
--- a/doc/release/1.13.0-notes.rst
+++ b/doc/release/1.13.0-notes.rst
@@ -282,7 +282,7 @@ Boolean indexing changes
 
 * Boolean indexes must match the dimension of the axis that they index.
 
-* Boolean indexes used on the lhs of an assigment must match the dimensions of
+* Boolean indexes used on the lhs of an assignment must match the dimensions of
   the rhs.
 
 * Boolean indexing into scalar arrays return a new 1-d array.  This means that
diff --git a/doc/release/1.3.0-notes.rst b/doc/release/1.3.0-notes.rst
index 73743bbcf..b5e43155b 100644
--- a/doc/release/1.3.0-notes.rst
+++ b/doc/release/1.3.0-notes.rst
@@ -85,7 +85,7 @@ Nan handling in max/min
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 The maximum/minimum ufuncs now reliably propagate nans. If one of the
-arguments is a nan, then nan is retured. This affects np.min/np.max, amin/amax
+arguments is a nan, then nan is returned. This affects np.min/np.max, amin/amax
 and the array methods max/min. New ufuncs fmax and fmin have been added to deal
 with non-propagating nans.
 
@@ -112,7 +112,7 @@ New ufuncs
 #. logaddexp - add numbers stored as logarithms and return the logarithm
    of the result.
 #. logaddexp2 - add numbers stored as base 2 logarithms and return the base 2
-   logarithm of the result result.
+   logarithm of the result.
 
 Masked arrays
 ~~~~~~~~~~~~~
@@ -123,7 +123,7 @@ Several new features and bug fixes, including:
 	  (r6463, r6324, r6305, r6300, r6294...)
 	* Minor bug fixes (r6356, r6352, r6335, r6299, r6298)
 	* Improved support for __iter__ (r6326)
-	* made baseclass, sharedmask and hardmask accesible to the user (but
+	* made baseclass, sharedmask and hardmask accessible to the user (but
 	  read-only)
 	* doc update
 
diff --git a/doc/release/1.4.0-notes.rst b/doc/release/1.4.0-notes.rst
index 9e3819229..9b53c1261 100644
--- a/doc/release/1.4.0-notes.rst
+++ b/doc/release/1.4.0-notes.rst
@@ -37,10 +37,10 @@ Automatic detection of forward incompatibilities
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, if an extension was built against a version N of NumPy, and used on
-a system with NumPy M < N, the import_array was successfull, which could cause
+a system with NumPy M < N, the import_array was successful, which could cause
 crashes because the version M does not have a function in N. Starting from
 NumPy 1.4.0, this will cause a failure in import_array, so the error will be
-catched early on.
+caught early on.
 
 New iterators
 ~~~~~~~~~~~~~
@@ -58,7 +58,7 @@ is not compatible with the current polynomial support in numpy, but is much
 like the new chebyshev module. The most noticeable difference to most will
 be that coefficients are specified from low to high power, that the low
 level functions do *not* work with the Chebyshev and Polynomial classes as
-arguements, and that the Chebyshev and Polynomial classes include a domain.
+arguments, and that the Chebyshev and Polynomial classes include a domain.
 Mapping between domains is a linear substitution and the two classes can be
 converted one to the other, allowing, for instance, a Chebyshev series in
 one domain to be expanded as a polynomial in another domain. The new classes
@@ -159,8 +159,8 @@ Improvements
     #. The type comparison functions have been made consistent with the new
        sort order of nans. Searchsorted now works with sorted arrays
        containing nan values.
-    #. Complex division has been made more resistent to overflow.
-    #. Complex floor division has been made more resistent to overflow.
+    #. Complex division has been made more resistant to overflow.
+    #. Complex floor division has been made more resistant to overflow.
 
 Deprecations
 ============
@@ -199,8 +199,8 @@ Use C99 complex functions when available
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The numpy complex types are now guaranteed to be ABI compatible with C99
-complex type, if availble on the platform. Moreoever, the complex ufunc now use
-the platform C99 functions intead of our own.
+complex type, if available on the platform. Moreover, the complex ufunc now use
+the platform C99 functions instead of our own.
 
 split multiarray and umath source code
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/release/1.8.0-notes.rst b/doc/release/1.8.0-notes.rst
index f06785f5d..5eed57129 100644
--- a/doc/release/1.8.0-notes.rst
+++ b/doc/release/1.8.0-notes.rst
@@ -37,7 +37,7 @@ probably be some changes to make it more useable.
 The diagonal method currently returns a new array and raises a
 FutureWarning. In 1.9 it will return a readonly view.
 
-Multiple field selection from a array of structured type currently
+Multiple field selection from an array of structured type currently
 returns a new array and raises a FutureWarning. In 1.9 it will return a
 readonly view.
 
@@ -199,7 +199,7 @@ percentiles of samples.
 New functions `nanmean`, `nanvar` and `nanstd`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 New nan aware statistical functions are added. In these functions the
-results are what would be obtained if nan values were ommited from all
+results are what would be obtained if nan values were omitted from all
 computations.
 
 New functions `full` and `full_like`
diff --git a/doc/release/1.9.0-notes.rst b/doc/release/1.9.0-notes.rst
index 37343ec6d..1ffbf8d4b 100644
--- a/doc/release/1.9.0-notes.rst
+++ b/doc/release/1.9.0-notes.rst
@@ -381,7 +381,7 @@ compiled on import.
 More GIL releases
 ~~~~~~~~~~~~~~~~~
 Several more functions now release the Global Interpreter Lock allowing more
-efficient parallization using the ``threading`` module. Most notably the GIL is
+efficient parallelization using the ``threading`` module. Most notably the GIL is
 now released for fancy indexing, ``np.where`` and the ``random`` module now
 uses a per-state lock instead of the GIL.
 
diff --git a/doc/source/dev/gitwash/development_workflow.rst b/doc/source/dev/gitwash/development_workflow.rst
index b788a042c..83464bf47 100644
--- a/doc/source/dev/gitwash/development_workflow.rst
+++ b/doc/source/dev/gitwash/development_workflow.rst
@@ -97,7 +97,7 @@ In more detail
 
 #. Optional: Compare the changes with the previous version using with ``git
    diff`` (`git diff`_). This brings up a simple text browser interface that
-   highlights the difference between your files and the previous verison.
+   highlights the difference between your files and the previous version.
 
 #. Add any relevant modified or new files using  ``git add modified_file``
    (see `git add`_). This puts the files into a staging area, which is a queue
diff --git a/doc/source/f2py/advanced.rst b/doc/source/f2py/advanced.rst
index 7990a9ce4..c9f3862e6 100644
--- a/doc/source/f2py/advanced.rst
+++ b/doc/source/f2py/advanced.rst
@@ -25,7 +25,7 @@ In Python:
 Modifying the dictionary of a F2PY generated module
 ===================================================
 
-The following example illustrates how to add an user-defined
+The following example illustrates how to add a user-defined
 variables to a F2PY generated extension module. Given the following
 signature file
 
diff --git a/doc/source/f2py/array_session.dat b/doc/source/f2py/array_session.dat
index fa2d1db14..069530d03 100644
--- a/doc/source/f2py/array_session.dat
+++ b/doc/source/f2py/array_session.dat
@@ -39,7 +39,7 @@ copied an array using copy_ND_array: size=6, elsize=8
 >>> print b
 [[ 1.  4.  5.]
  [ 2.  5.  6.]]
->>> a is b                       # a and b are acctually the same objects
+>>> a is b                       # a and b are actually the same objects
 1
 >>> print arr.foo([1,2,3])       # different rank arrays are allowed
 copied an array using PyArray_CopyFromObject: size=3, elsize=8
diff --git a/doc/source/f2py/getting-started.rst b/doc/source/f2py/getting-started.rst
index b54d1aba8..fffd61c45 100644
--- a/doc/source/f2py/getting-started.rst
+++ b/doc/source/f2py/getting-started.rst
@@ -170,7 +170,7 @@ one.
   .. include:: fib1.pyf
      :literal:
 
-* Next, we'll teach F2PY that the argument ``n`` is a input argument
+* Next, we'll teach F2PY that the argument ``n`` is an input argument
   (use ``intent(in)`` attribute) and that the result, i.e. the
   contents of ``a`` after calling Fortran function ``FIB``, should be
   returned to Python (use ``intent(out)`` attribute). In addition, an
diff --git a/doc/source/f2py/python-usage.rst b/doc/source/f2py/python-usage.rst
index f5f1d2304..79860173b 100644
--- a/doc/source/f2py/python-usage.rst
+++ b/doc/source/f2py/python-usage.rst
@@ -10,7 +10,7 @@ objects.
 
 All ``fortran`` type object have attribute ``_cpointer`` that contains
 CObject referring to the C pointer of the corresponding Fortran/C
-function or variable in C level. Such CObjects can be used as an
+function or variable in C level. Such CObjects can be used as a
 callback argument of F2PY generated functions to bypass Python C/API
 layer of calling Python functions from Fortran or C when the
 computational part of such functions is implemented in C or Fortran
@@ -120,7 +120,7 @@ There are two types of proper-contiguous NumPy arrays:
 
 For one-dimensional arrays these notions coincide.
 
-For example, an 2x2 array ``A`` is Fortran-contiguous if its elements
+For example, a 2x2 array ``A`` is Fortran-contiguous if its elements
 are stored in memory in the following order::
 
   A[0,0] A[1,0] A[0,1] A[1,1]
@@ -279,7 +279,7 @@ but the following Python function
      ...
      return y_1,...,y_l
 
-is provided by an user, and in addition,
+is provided by a user, and in addition,
 
 ::
 
diff --git a/doc/source/f2py/signature-file.rst b/doc/source/f2py/signature-file.rst
index 6afcdeb8c..090a5eca5 100644
--- a/doc/source/f2py/signature-file.rst
+++ b/doc/source/f2py/signature-file.rst
@@ -56,7 +56,7 @@ A ``python module`` block has the following structure::
     ]...
   end [python module [<modulename>]]
 
-Here brackets ``[]`` indicate a optional part, dots ``...`` indicate
+Here brackets ``[]`` indicate an optional part, dots ``...`` indicate
 one or more of a previous part. So, ``[]...`` reads zero or more of a
 previous part.
 
@@ -326,7 +326,7 @@ The following attributes are used by F2PY:
   default. You need to specify ``required`` only if there is a need to
   disable automatic ``optional`` setting when ``<init_expr>`` is used.
 
-  If Python ``None`` object is used as an required argument, the
+  If Python ``None`` object is used as a required argument, the
   argument is treated as optional. That is, in the case of array
   argument, the memory is allocated. And if ``<init_expr>`` is given,
   the corresponding initialization is carried out.
@@ -370,7 +370,7 @@ The following attributes are used by F2PY:
       slices data pointers may point to unallocated memory area.
 
   + ``out``
-      The argument is considered as an return variable. It is appended
+      The argument is considered as a return variable. It is appended
       to the ``<returned variables>`` list. Using ``intent(out)``
       sets ``intent(hide)`` automatically, unless also
       ``intent(in)`` or ``intent(inout)`` were used.
diff --git a/doc/source/reference/arrays.datetime.rst b/doc/source/reference/arrays.datetime.rst
index cbc696ae8..139f23f11 100644
--- a/doc/source/reference/arrays.datetime.rst
+++ b/doc/source/reference/arrays.datetime.rst
@@ -146,7 +146,7 @@ other units based on input data.
 
 Datetimes are always stored based on POSIX time (though having a TAI
 mode which allows for accounting of leap-seconds is proposed), with
-a epoch of 1970-01-01T00:00Z. This means the supported dates are
+an epoch of 1970-01-01T00:00Z. This means the supported dates are
 always a symmetric interval around the epoch, called "time span" in the
 table below.
 
@@ -341,7 +341,7 @@ printing it would convert from or to local time::
     >>>> np.datetime64('2000-01-01T00:00:00')
     numpy.datetime64('2000-01-01T00:00:00-0800')  # note the timezone offset -08:00
 
-A concensus of datetime64 users agreed that this behavior is undesirable
+A consensus of datetime64 users agreed that this behavior is undesirable
 and at odds with how datetime64 is usually used (e.g., by pandas_). For
 most use cases, a timezone naive datetime type is preferred, similar to the
 ``datetime.datetime`` type in the Python standard library. Accordingly,
diff --git a/doc/source/reference/arrays.dtypes.rst b/doc/source/reference/arrays.dtypes.rst
index 01a969826..594b94608 100644
--- a/doc/source/reference/arrays.dtypes.rst
+++ b/doc/source/reference/arrays.dtypes.rst
@@ -388,7 +388,7 @@ Type strings
     .. admonition:: Example
 
        Data type with fields ``r``, ``g``, ``b``, ``a``, each being
-       a 8-bit unsigned integer:
+       an 8-bit unsigned integer:
 
        >>> dt = np.dtype({'names': ['r','g','b','a'],
        ...                'formats': [uint8, uint8, uint8, uint8]})
diff --git a/doc/source/reference/c-api.array.rst b/doc/source/reference/c-api.array.rst
index 2a7bb3a32..5fb7e3a9f 100644
--- a/doc/source/reference/c-api.array.rst
+++ b/doc/source/reference/c-api.array.rst
@@ -1030,12 +1030,12 @@ Converting data types
     exception is that 64-bit integers are allowed to be cast to 64-bit
     floating point values even though this can lose precision on large
     integers so as not to proliferate the use of long doubles without
-    explict requests. Flexible array types are not checked according
+    explicit requests. Flexible array types are not checked according
     to their lengths with this function.
 
 .. c:function:: int PyArray_CanCastTo(PyArray_Descr* fromtype, PyArray_Descr* totype)
 
-    :c:func:`PyArray_CanCastTypeTo` supercedes this function in
+    :c:func:`PyArray_CanCastTypeTo` supersedes this function in
     NumPy 1.6 and later.
 
     Equivalent to PyArray_CanCastTypeTo(fromtype, totype, NPY_SAFE_CASTING).
@@ -1356,7 +1356,7 @@ of the constant names is deprecated in 1.7.
 
     The data area can be written to.
 
-    Notice that the above 3 flags are are defined so that a new, well-
+    Notice that the above 3 flags are defined so that a new, well-
     behaved array has these flags defined as true.
 
 .. c:var:: NPY_ARRAY_UPDATEIFCOPY
@@ -1485,7 +1485,7 @@ For all of these macros *arr* must be an instance of a (subclass of)
 
 .. c:function:: PyArray_ISBEHAVED(arr)
 
-    Evalutes true if the data area of *arr* is aligned and writeable
+    Evaluates true if the data area of *arr* is aligned and writeable
     and in machine byte-order according to its descriptor.
 
 .. c:function:: PyArray_ISBEHAVED_RO(arr)
@@ -1659,7 +1659,7 @@ Shape Manipulation
     Equivalent to :meth:`ndarray.reshape` (*self*, *shape*) where *shape* is a
     sequence. Converts *shape* to a :c:type:`PyArray_Dims` structure and
     calls :c:func:`PyArray_Newshape` internally.
-    For back-ward compatability -- Not recommended
+    For back-ward compatibility -- Not recommended
 
 .. c:function:: PyObject* PyArray_Squeeze(PyArrayObject* self)
 
@@ -1975,7 +1975,7 @@ Calculation
 
     Equivalent to :meth:`ndarray.conjugate` (*self*).
     Return the complex conjugate of *self*. If *self* is not of
-    complex data type, then return *self* with an reference.
+    complex data type, then return *self* with a reference.
 
 .. c:function:: PyObject* PyArray_Round(PyArrayObject* self, int decimals, PyArrayObject* out)
 
@@ -2230,7 +2230,7 @@ an element copier function as a primitive.::
     void free_element_doubler_aux_data(NpyAuxData *data)
     {
         eldoubler_aux_data *d = (eldoubler_aux_data *)data;
-        /* Free the memory owned by this auxadata */
+        /* Free the memory owned by this auxdata */
         NPY_AUXDATA_FREE(d->funcdata);
         PyArray_free(d);
     }
@@ -3020,7 +3020,7 @@ Internal Flexibility
 .. c:function:: PyObject* PyArray_GetNumericOps(void)
 
     Return a Python dictionary containing the callable Python objects
-    stored in the the internal arithmetic operation table. The keys of
+    stored in the internal arithmetic operation table. The keys of
     this dictionary are given in the explanation for :c:func:`PyArray_SetNumericOps`.
 
 .. c:function:: void PyArray_SetStringFunction(PyObject* op, int repr)
diff --git a/doc/source/reference/c-api.ufunc.rst b/doc/source/reference/c-api.ufunc.rst
index 892ccbdc7..35dcd6cfa 100644
--- a/doc/source/reference/c-api.ufunc.rst
+++ b/doc/source/reference/c-api.ufunc.rst
@@ -57,7 +57,7 @@ Macros
     Deprecated: use npy_clear_floatstatus from npy_math.h instead.
 
     A macro that expands to platform-dependent code. The *ret*
-    variable can can be any integer. The :c:data:`UFUNC_FPE_{ERR}` bits are
+    variable can be any integer. The :c:data:`UFUNC_FPE_{ERR}` bits are
     set in *ret* according to the status of the corresponding error
     flags of the floating point processor.
 
@@ -342,7 +342,7 @@ structure.
 
     This general purpose 1-d core function assumes that *func* is a string
     representing a method of the input object. For each
-    iteration of the loop, the Python obejct is extracted from the array
+    iteration of the loop, the Python object is extracted from the array
     and its *func* method is called returning the result to the output array.
 
 .. c:function:: void PyUFunc_OO_O_method(char** args, npy_intp* dimensions,
@@ -372,7 +372,7 @@ structure.
                PyObject *callable;
            } PyUFunc_PyFuncData;
 
-    At each iteration of the loop, the *nin* input objects are exctracted
+    At each iteration of the loop, the *nin* input objects are extracted
     from their object arrays and placed into an argument tuple, the Python
     *callable* is called with the input arguments, and the nout
     outputs are placed into their object arrays.
diff --git a/doc/source/reference/distutils.rst b/doc/source/reference/distutils.rst
index 7aed4e90d..289822909 100644
--- a/doc/source/reference/distutils.rst
+++ b/doc/source/reference/distutils.rst
@@ -213,7 +213,7 @@ build phase of setup, if a template file named <somefile>.src is
 encountered, a new file named <somefile> is constructed from the
 template and placed in the build directory to be used instead. Two
 forms of template conversion are supported. The first form occurs for
-files named named <file>.ext.src where ext is a recognized Fortran
+files named <file>.ext.src where ext is a recognized Fortran
 extension (f, f90, f95, f77, for, ftn, pyf). The second form is used
 for all other cases.
 
diff --git a/doc/source/reference/swig.interface-file.rst b/doc/source/reference/swig.interface-file.rst
index 94fe83d36..22b5f757a 100644
--- a/doc/source/reference/swig.interface-file.rst
+++ b/doc/source/reference/swig.interface-file.rst
@@ -142,7 +142,7 @@ lines 19 and 20 so that we can call the underlying C function at line
 created a new array that is no longer needed.
 
 This code has a significant amount of error handling.  Note the
-``SWIG_fail`` is a macro for ``goto fail``, refering to the label at
+``SWIG_fail`` is a macro for ``goto fail``, referring to the label at
 line 28.  If the user provides the wrong number of arguments, this
 will be caught at line 10.  If construction of the NumPy array
 fails or produces an array with the wrong number of dimensions, these
@@ -337,7 +337,7 @@ Argout Arrays
 Argout arrays are arrays that appear in the input arguments in C, but
 are in fact output arrays.  This pattern occurs often when there is
 more than one output variable and the single return argument is
-therefore not sufficient.  In Python, the convential way to return
+therefore not sufficient.  In Python, the conventional way to return
 multiple arguments is to pack them into a sequence (tuple, list, etc.)
 and return the sequence.  This is what the argout typemaps do.  If a
 wrapped function that uses these argout typemaps has more than one
@@ -556,7 +556,7 @@ and the argument you are passing is an integer extracted from a
 NumPy array, then you have stumbled upon this problem.  The
 solution is to modify the `SWIG`_ type conversion system to accept
 NumPy array scalars in addition to the standard integer types.
-Fortunately, this capabilitiy has been provided for you.  Simply copy
+Fortunately, this capability has been provided for you.  Simply copy
 the file::
 
     pyfragments.swg
@@ -577,7 +577,7 @@ inserted into your wrapper code once.
 
 There is a fragment for converting a Python integer to a C
 ``long``.  There is a different fragment that converts a Python
-integer to a C ``int``, that calls the rountine defined in the
+integer to a C ``int``, that calls the routine defined in the
 ``long`` fragment.  We can make the changes we want here by changing
 the definition for the ``long`` fragment.  `SWIG`_ determines the
 active definition for a fragment using a "first come, first served"
@@ -590,7 +590,7 @@ in ``numpy.i``, they would be ignored.
 Helper Functions
 ----------------
 
-The ``numpy.i`` file containes several macros and routines that it
+The ``numpy.i`` file contains several macros and routines that it
 uses internally to build its typemaps.  However, these functions may
 be useful elsewhere in your interface file.  These macros and routines
 are implemented as fragments, which are described briefly in the
diff --git a/doc/source/user/basics.io.genfromtxt.rst b/doc/source/user/basics.io.genfromtxt.rst
index 1fed3fe8e..5870b5af2 100644
--- a/doc/source/user/basics.io.genfromtxt.rst
+++ b/doc/source/user/basics.io.genfromtxt.rst
@@ -29,7 +29,7 @@ Defining the input
 The only mandatory argument of :func:`~numpy.genfromtxt` is the source of
 the data. It can be a string, a list of strings, or a generator. If a
 single string is provided, it is assumed to be the name of a local or
-remote file, or a open file-like object with a :meth:`read` method, for
+remote file, or an open file-like object with a :meth:`read` method, for
 example, a file or :class:`StringIO.StringIO` object. If a list of strings
 or a generator returning strings is provided, each string is treated as one
 line in a file.  When the URL of a remote file is passed, the file is
diff --git a/doc/source/user/building.rst b/doc/source/user/building.rst
index c823ec570..fa3f2ccb4 100644
--- a/doc/source/user/building.rst
+++ b/doc/source/user/building.rst
@@ -114,7 +114,7 @@ How to check the ABI of blas/lapack/atlas
 
 One relatively simple and reliable way to check for the compiler used to build
 a library is to use ldd on the library. If libg2c.so is a dependency, this
-means that g77 has been used. If libgfortran.so is a a dependency, gfortran
+means that g77 has been used. If libgfortran.so is a dependency, gfortran
 has been used. If both are dependencies, this means both have been used, which
 is almost always a very bad idea.
 
diff --git a/doc/source/user/c-info.beyond-basics.rst b/doc/source/user/c-info.beyond-basics.rst
index 81c0d233f..c42310e3e 100644
--- a/doc/source/user/c-info.beyond-basics.rst
+++ b/doc/source/user/c-info.beyond-basics.rst
@@ -129,7 +129,7 @@ the dimension with the largest axis is found and used.
 Iterating over multiple arrays
 ------------------------------
 
-Very often, it is desireable to iterate over several arrays at the
+Very often, it is desirable to iterate over several arrays at the
 same time. The universal functions are an example of this kind of
 behavior. If all you want to do is iterate over arrays with the same
 shape, then simply creating several iterator objects is the standard
@@ -259,7 +259,7 @@ pointer to the data-type you've just defined. In addition, the
 required functions in the ".f" member must be defined: nonzero,
 copyswap, copyswapn, setitem, getitem, and cast. The more functions in
 the ".f" member you define, however, the more useful the new data-type
-will be.  It is very important to intialize unused functions to NULL.
+will be.  It is very important to initialize unused functions to NULL.
 This can be achieved using :c:func:`PyArray_InitArrFuncs` (f).
 
 Once a new :c:type:`PyArray_Descr` structure is created and filled with the
@@ -325,7 +325,7 @@ not presumed to be safely castable to user-defined data-types. This
 situation limits the ability of user-defined data-types to participate
 in the coercion system used by ufuncs and other times when automatic
 coercion takes place in NumPy. This can be changed by registering
-data-types as safely castable from a particlar data-type object. The
+data-types as safely castable from a particular data-type object. The
 function :c:func:`PyArray_RegisterCanCast` (from_descr, totype_number,
 scalarkind) should be used to specify that the data-type object
 from_descr can be cast to the data-type with type number
@@ -404,7 +404,7 @@ with regards to memory management. Sub-typing in C is not difficult
 even if you have only a rudimentary understanding of how to create new
 types for Python. While it is easiest to sub-type from a single parent
 type, sub-typing from multiple parent types is also possible. Multiple
-inheritence in C is generally less useful than it is in Python because
+inheritance in C is generally less useful than it is in Python because
 a restriction on Python sub-types is that they have a binary
 compatible memory layout. Perhaps for this reason, it is somewhat
 easier to sub-type from a single parent type.
@@ -441,9 +441,9 @@ every new Python type.
 Creating sub-types
 ------------------
 
-To create a sub-type, a similar proceedure must be followed except
+To create a sub-type, a similar procedure must be followed except
 only behaviors that are different require new entries in the type-
-object structure. All other entires can be NULL and will be filled in
+object structure. All other entries can be NULL and will be filled in
 by :c:func:`PyType_Ready` with appropriate functions from the parent
 type(s). In particular, to create a sub-type in C follow these steps:
 
diff --git a/doc/source/user/c-info.how-to-extend.rst b/doc/source/user/c-info.how-to-extend.rst
index 340200a19..62ce9f05b 100644
--- a/doc/source/user/c-info.how-to-extend.rst
+++ b/doc/source/user/c-info.how-to-extend.rst
@@ -246,7 +246,7 @@ format_string. Using this function will raise a TypeError if invalid
 keyword arguments are passed in.
 
 For more help on this function please see section 1.8 (Keyword
-Paramters for Extension Functions) of the Extending and Embedding
+Parameters for Extension Functions) of the Extending and Embedding
 tutorial in the Python documentation.
 
 
@@ -373,7 +373,7 @@ writeable). The syntax is
 
     *obj*
 
-        The object can be any Python object convertable to an ndarray.
+        The object can be any Python object convertible to an ndarray.
         If the object is already (a subclass of) the ndarray that
         satisfies the requirements then a new reference is returned.
         Otherwise, a new array is constructed. The contents of *obj*
diff --git a/doc/source/user/c-info.python-as-glue.rst b/doc/source/user/c-info.python-as-glue.rst
index 84248def1..0152ac549 100644
--- a/doc/source/user/c-info.python-as-glue.rst
+++ b/doc/source/user/c-info.python-as-glue.rst
@@ -414,7 +414,7 @@ Python with compiled code while still allowing for separate
 distribution of the extension module. The only draw-back is that it
 requires the existence of a Fortran compiler in order for a user to
 install the code. However, with the existence of the free-compilers
-g77, gfortran, and g95, as well as high-quality commerical compilers,
+g77, gfortran, and g95, as well as high-quality commercial compilers,
 this restriction is not particularly onerous. In my opinion, Fortran
 is still the easiest way to write fast and clear code for scientific
 computing. It handles complex numbers, and multi-dimensional indexing
@@ -643,7 +643,7 @@ order to check the data types and array bounds of objects passed to
 the underlying subroutine. This additional layer of checking (not to
 mention the conversion from ctypes objects to C-data-types that ctypes
 itself performs), will make the interface slower than a hand-written
-extension-module interface. However, this overhead should be neglible
+extension-module interface. However, this overhead should be negligible
 if the C-routine being called is doing any significant amount of work.
 If you are a great Python programmer with weak C skills, ctypes is an
 easy way to write a useful interface to a (shared) library of compiled
@@ -761,7 +761,7 @@ associated. As a result, one can pass this ctypes attribute object
 directly to a function expecting a pointer to the data in your
 ndarray. The caller must be sure that the ndarray object is of the
 correct type, shape, and has the correct flags set or risk nasty
-crashes if the data-pointer to inappropriate arrays are passsed in.
+crashes if the data-pointer to inappropriate arrays are passed in.
 
 To implement the second method, NumPy provides the class-factory
 function :func:`ndpointer` in the :mod:`ctypeslib` module. This
@@ -783,7 +783,7 @@ attributes that may be convenient when passing additional information
 about the array into a ctypes function. The attributes **data**,
 **shape**, and **strides** can provide ctypes compatible types
 corresponding to the data-area, the shape, and the strides of the
-array. The data attribute reutrns a ``c_void_p`` representing a
+array. The data attribute returns a ``c_void_p`` representing a
 pointer to the data area. The shape and strides attributes each return
 an array of ctypes integers (or None representing a NULL pointer, if a
 0-d array). The base ctype of the array is a ctype integer of the same
@@ -935,7 +935,7 @@ The ``code.c`` file also contains the function ``dfilter2d``:
 A possible advantage this code has over the Fortran-equivalent code is
 that it takes arbitrarily strided (i.e. non-contiguous arrays) and may
 also run faster depending on the optimization capability of your
-compiler. But, it is a obviously more complicated than the simple code
+compiler. But, it is an obviously more complicated than the simple code
 in ``filter.f``. This code must be compiled into a shared library. On my
 Linux system this is accomplished using::
 
@@ -1149,7 +1149,7 @@ but the interface file looks a lot like a C/C++ header file. While SIP
 is not a full C++ parser, it understands quite a bit of C++ syntax as
 well as its own special directives that allow modification of how the
 Python binding is accomplished. It also allows the user to define
-mappings between Python types and C/C++ structrues and classes.
+mappings between Python types and C/C++ structures and classes.
 
 
 Boost Python
diff --git a/doc/source/user/install.rst b/doc/source/user/install.rst
index a9ac735b8..dd7543645 100644
--- a/doc/source/user/install.rst
+++ b/doc/source/user/install.rst
@@ -2,7 +2,7 @@
 Installing NumPy
 ****************
 
-In most use cases the best way to install NumPy on your system is by using an
+In most use cases the best way to install NumPy on your system is by using a
 pre-built package for your operating system.  Please see
 http://scipy.org/install.html for links to available options.
 
diff --git a/doc/source/user/numpy-for-matlab-users.rst b/doc/source/user/numpy-for-matlab-users.rst
index cf019f630..2661c79c3 100644
--- a/doc/source/user/numpy-for-matlab-users.rst
+++ b/doc/source/user/numpy-for-matlab-users.rst
@@ -728,7 +728,7 @@ this is just an example, not a statement of "best practices"):
     # Define a Hermitian function
     def hermitian(A, **kwargs):
         return num.transpose(A,**kwargs).conj()
-    # Make some shorcuts for transpose,hermitian:
+    # Make some shortcuts for transpose,hermitian:
     #    num.transpose(A) --> T(A)
     #    hermitian(A) --> H(A)
     T = num.transpose