change all non-code instances of Numpy to NumPy

Instances remain for NumpyVersion and Numpy.rec.fromarrays that are
references to code.

Release notes were left unchanged.

see issue #7986

56 files changed, 168 insertions, 168 deletions

diff --git a/doc/C_STYLE_GUIDE.rst.txt b/doc/C_STYLE_GUIDE.rst.txt
index 4b89b3aea..a5726f16f 100644
--- a/doc/C_STYLE_GUIDE.rst.txt
+++ b/doc/C_STYLE_GUIDE.rst.txt
@@ -6,7 +6,7 @@ The NumPy C coding conventions are based on Python PEP-0007 by Guido van
 Rossum with a few added strictures. There are many C coding conventions and
 it must be emphasized that the primary goal of the NumPy conventions isn't
 to choose the 'best', about which there is certain to be disagreement, but
-to achieve uniformity. Because the Numpy conventions are very close to
+to achieve uniformity. Because the NumPy conventions are very close to
 those in PEP-0007, that PEP is used as a template below with the NumPy
 additions and variations in the appropriate spots.
 
@@ -17,7 +17,7 @@ Introduction
 ------------
 
 This document gives coding conventions for the C code comprising
-the C implementation of Numpy. Note, rules are there to be broken.
+the C implementation of NumPy. Note, rules are there to be broken.
 Two good reasons to break a particular rule:
 
 1. When applying the rule would make the code less readable, even
@@ -53,7 +53,7 @@ C dialect
   Note: this will change with the proposed transition to C++.
 
 * No compiler warnings with major compilers (gcc, VC++, a few others).
-  Note: Numpy still produces compiler warnings that need to be addressed.
+  Note: NumPy still produces compiler warnings that need to be addressed.
 
 
 Code lay-out
@@ -195,7 +195,7 @@ Code lay-out
 Naming conventions
 ------------------
 
-* There has been no consistent prefix for Numpy public functions, but
+* There has been no consistent prefix for NumPy public functions, but
   they all begin with a prefix of some sort, followed by an underscore, and
   are in camel case: ``PyArray_DescrAlignConverter``, ``NpyIter_GetIterNext``.
   In the future the names should be of the form ``Npy*_PublicFunction``,
@@ -213,7 +213,7 @@ Naming conventions
 Function documentation
 ----------------------
 
-Numpy doesn't have a C function documentation standard at this time, but
+NumPy doesn't have a C function documentation standard at this time, but
 needs one. Most numpy functions are not documented in the code and that
 should change. One possibility is Doxygen with a plugin so that the same
 NumPy style used for Python functions can also be used for documenting
diff --git a/doc/HOWTO_BUILD_DOCS.rst.txt b/doc/HOWTO_BUILD_DOCS.rst.txt
index dc0145855..5ce226ad4 100644
--- a/doc/HOWTO_BUILD_DOCS.rst.txt
+++ b/doc/HOWTO_BUILD_DOCS.rst.txt
@@ -3,7 +3,7 @@ Building the NumPy API and reference docs
 =========================================
 
 We currently use Sphinx_ for generating the API and reference
-documentation for Numpy.  You will need Sphinx 1.0.1 or newer.
+documentation for NumPy.  You will need Sphinx 1.0.1 or newer.
 
 If you only want to get the documentation, note that pre-built
 versions can be found at
@@ -18,7 +18,7 @@ in several different formats.
 Instructions
 ------------
 
-If you obtained Numpy via git, get also the git submodules that contain
+If you obtained NumPy via git, get also the git submodules that contain
 additional parts required for building the documentation::
 
     git submodule init
@@ -30,15 +30,15 @@ be installed with or without completely installing Matplotlib: see the
 Matplotlib documentation for more information.
 
 Since large parts of the main documentation are stored in
-docstrings, you will need to first build Numpy, and install it so
+docstrings, you will need to first build NumPy, and install it so
 that the correct version is imported by
 
     >>> import numpy
 
-Note that you can eg. install Numpy to a temporary location and set
+Note that you can eg. install NumPy to a temporary location and set
 the PYTHONPATH environment variable appropriately.
 
-After Numpy is installed, write::
+After NumPy is installed, write::
 
     make html
 
@@ -59,11 +59,11 @@ Instead of the above, you can also do::
 
    make dist
 
-which will rebuild Numpy, install it to a temporary location, and
+which will rebuild NumPy, install it to a temporary location, and
 build the documentation in all formats. This will most likely again
 only work on Unix platforms.
 
-The documentation for Numpy distributed at http://docs.scipy.org in html and
+The documentation for NumPy distributed at http://docs.scipy.org in html and
 pdf format is also built with ``make dist``.  See `HOWTO RELEASE`_ for details on
 how to update http://docs.scipy.org.
 
@@ -73,9 +73,9 @@ how to update http://docs.scipy.org.
 Sphinx extensions
 -----------------
 
-Numpy's documentation uses several custom extensions to Sphinx.  These
+NumPy's documentation uses several custom extensions to Sphinx.  These
 are shipped in the ``sphinxext/`` directory (as git submodules, as discussed
-above), and are automatically enabled when building Numpy's documentation.
+above), and are automatically enabled when building NumPy's documentation.
 
 If you want to make use of these extensions in third-party
 projects, they are available on PyPi_ as the numpydoc_ package.
diff --git a/doc/HOWTO_DOCUMENT.rst.txt b/doc/HOWTO_DOCUMENT.rst.txt
index 954f331e8..169b87df4 100644
--- a/doc/HOWTO_DOCUMENT.rst.txt
+++ b/doc/HOWTO_DOCUMENT.rst.txt
@@ -141,7 +141,7 @@ The sections of the docstring are:
    A section (use if applicable) to warn users that the object is deprecated.
    Section contents should include:
 
-   * In what Numpy version the object was deprecated, and when it will be
+   * In what NumPy version the object was deprecated, and when it will be
      removed.
 
    * Reason for deprecation if this is useful information (e.g., object
@@ -154,8 +154,8 @@ The sections of the docstring are:
 
    ::
 
-     .. note:: Deprecated in Numpy 1.6
-               `ndobj_old` will be removed in Numpy 2.0, it is replaced by
+     .. note:: Deprecated in NumPy 1.6
+               `ndobj_old` will be removed in NumPy 2.0, it is replaced by
                `ndobj_new` because the latter works also with array subclasses.
 
 3. **Extended Summary**
@@ -529,7 +529,7 @@ as appropriate.
 
 Documenting class instances
 ---------------------------
-Instances of classes that are part of the Numpy API (for example `np.r_`
+Instances of classes that are part of the NumPy API (for example `np.r_`
 `np,c_`, `np.index_exp`, etc.) may require some care. To give these
 instances a useful docstring, we do the following:
 
diff --git a/doc/HOWTO_RELEASE.rst.txt b/doc/HOWTO_RELEASE.rst.txt
index 8c180e1e0..6d0d54e89 100644
--- a/doc/HOWTO_RELEASE.rst.txt
+++ b/doc/HOWTO_RELEASE.rst.txt
@@ -302,7 +302,7 @@ to public keyservers, with a command such as::
 
 Apply patch to fix bogus strides
 --------------------------------
-NPY_RELAXED_STRIDE_CHECKING was made the default in Numpy 1.10 and bogus
+NPY_RELAXED_STRIDE_CHECKING was made the default in NumPy 1.10 and bogus
 strides are used in the development branch to smoke out problems. The
 `patch <https://github.com/numpy/numpy/pull/5996>`_ should be updated if
 necessary and applied to the release branch to rationalize the strides.
diff --git a/doc/Py3K.rst.txt b/doc/Py3K.rst.txt
index e06461794..7150430ac 100644
--- a/doc/Py3K.rst.txt
+++ b/doc/Py3K.rst.txt
@@ -11,7 +11,7 @@ Developer notes on the transition to Python 3
 General
 =======
 
-Numpy has now been ported to Python 3.
+NumPy has now been ported to Python 3.
 
 Some glitches may still be present; however, we are not aware of any
 significant ones, the test suite passes.
@@ -125,7 +125,7 @@ F2py is ported to Py3.
 Bytes vs. strings
 -----------------
 
-At many points in Numpy, bytes literals are needed. These can be created via
+At many points in NumPy, bytes literals are needed. These can be created via
 numpy.compat.asbytes and asbytes_nested.
 
 
@@ -245,7 +245,7 @@ Any new ones that need to be added should be added in this file.
 
 .. todo::
 
-   Remove PyString_* eventually -- having a call to one of these in Numpy
+   Remove PyString_* eventually -- having a call to one of these in NumPy
    sources is a sign of an error...
 
 
@@ -527,7 +527,7 @@ There are two issues related to the str/bytes change:
 This entry discusses return values etc. only, the 'S' dtype is a
 separate topic.
 
-All uses of PyString in Numpy should be changed to one of
+All uses of PyString in NumPy should be changed to one of
 
 - PyBytes: one-byte character strings in Py2 and Py3
 - PyUString (defined in npy_3kconfig.h): PyString in Py2, PyUnicode in Py3
@@ -554,7 +554,7 @@ Some specific decisions that have been made so far:
 
 * descriptor.c: dtype field names are UString
 
-  At some places in Numpy code, there are some guards for Unicode field
+  At some places in NumPy code, there are some guards for Unicode field
   names. However, the dtype constructor accepts only strings as field names,
   so we should assume field names are *always* UString.
 
@@ -604,7 +604,7 @@ PyUnicode
 PyUnicode in Py3 is pretty much as it was in Py2, except that it is
 now the only "real" string type.
 
-In Py3, Unicode and Bytes are not comparable, ie., 'a' != b'a'.  Numpy
+In Py3, Unicode and Bytes are not comparable, ie., 'a' != b'a'.  NumPy
 comparison routines were handled to act in the same way, leaving
 comparison between Unicode and Bytes undefined.
 
@@ -627,17 +627,17 @@ PyInt
 -----
 
 There is no limited-range integer type any more in Py3.  It makes no
-sense to inherit Numpy ints from Py3 ints.
+sense to inherit NumPy ints from Py3 ints.
 
 Currently, the following is done:
 
-1) Numpy's integer types no longer inherit from Python integer.
+1) NumPy's integer types no longer inherit from Python integer.
 2) int is taken dtype-equivalent to NPY_LONG
 3) ints are converted to NPY_LONG
 
 PyInt methods are currently replaced by PyLong, via macros in npy_3kcompat.h.
 
-Dtype decision rules were changed accordingly, so that Numpy understands
+Dtype decision rules were changed accordingly, so that NumPy understands
 Py3 int translate to NPY_LONG as far as dtypes are concerned.
 
 array([1]).dtype will be the default NPY_LONG integer.
@@ -645,7 +645,7 @@ array([1]).dtype will be the default NPY_LONG integer.
 .. todo::
 
    Not inheriting from `int` on Python 3 makes the following not work:
-   ``np.intp("0xff", 16)`` -- because the Numpy type does not take
+   ``np.intp("0xff", 16)`` -- because the NumPy type does not take
    the second argument. This could perhaps be fixed...
 
 
@@ -707,7 +707,7 @@ Module initialization
 
 The module initialization API changed in Python 3.1.
 
-Most Numpy modules are now converted.
+Most NumPy modules are now converted.
 
 
 PyTypeObject
@@ -871,7 +871,7 @@ obtained must be closed with fclose after use.
 
    Should probably be done much later on...
 
-   Adapt all Numpy I/O to use the PyFile_* methods or the low-level
+   Adapt all NumPy I/O to use the PyFile_* methods or the low-level
    IO routines. In any case, it's unlikely that C stdio can be used any more.
 
    Perhaps using PyFile_* makes numpy.tofile e.g. to a gzip to work?
@@ -914,4 +914,4 @@ PyCObject / PyCapsule
 The PyCObject API is removed in Python 3.2, so we need to rewrite it
 using PyCapsule.
 
-Numpy was changed to use the Capsule API, using NpyCapsule* wrappers.
+NumPy was changed to use the Capsule API, using NpyCapsule* wrappers.
diff --git a/doc/TESTS.rst.txt b/doc/TESTS.rst.txt
index 690baca3d..7028ca57a 100644
--- a/doc/TESTS.rst.txt
+++ b/doc/TESTS.rst.txt
@@ -382,5 +382,5 @@ Tests on random data are good, but since test failures are meant to expose
 new bugs or regressions, a test that passes most of the time but fails
 occasionally with no code changes is not helpful. Make the random data
 deterministic by setting the random number seed before generating it.  Use
-either Python's ``random.seed(some_number)`` or Numpy's
+either Python's ``random.seed(some_number)`` or NumPy's
 ``numpy.random.seed(some_number)``, depending on the source of random numbers.
diff --git a/doc/cdoc/README b/doc/cdoc/README
index 98be85484..a5363cfa1 100644
--- a/doc/cdoc/README
+++ b/doc/cdoc/README
@@ -1,7 +1,7 @@
 cdoc
 ====
 
-This is a simple Doxygen project for building Numpy C code documentation,
+This is a simple Doxygen project for building NumPy C code documentation,
 with docstrings extracted from the C sources themselves.
 
 The understood syntax for documentation in the C source is
diff --git a/doc/neps/missing-data.rst b/doc/neps/missing-data.rst
index 17fb06491..9dc509c53 100644
--- a/doc/neps/missing-data.rst
+++ b/doc/neps/missing-data.rst
@@ -884,7 +884,7 @@ a few different access patterns people use to get ahold of the numpy array data,
 here we examine a few of them to see what numpy can do. These examples are
 found from doing google searches of numpy C API array access.
 
-Numpy Documentation - How to extend NumPy
+NumPy Documentation - How to extend NumPy
 -----------------------------------------
 
 http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#dealing-with-array-objects
diff --git a/doc/neps/new-iterator-ufunc.rst b/doc/neps/new-iterator-ufunc.rst
index 6d132f9a5..e62c910cf 100644
--- a/doc/neps/new-iterator-ufunc.rst
+++ b/doc/neps/new-iterator-ufunc.rst
@@ -51,7 +51,7 @@ NumPy defaults to returning C-contiguous arrays from UFuncs.  This can
 result in extremely poor memory access patterns when dealing with data
 that is structured differently.  A simple timing example illustrates
 this with a more than eight times performance hit from adding
-Fortran-contiguous arrays together.  All timings are done using Numpy
+Fortran-contiguous arrays together.  All timings are done using NumPy
 2.0dev (Nov 22, 2010) on an Athlon 64 X2 4200+, with a 64-bit OS.::
 
     In [1]: import numpy as np
diff --git a/doc/neps/ufunc-overrides.rst b/doc/neps/ufunc-overrides.rst
index be3b8b4aa..98380ee97 100644
--- a/doc/neps/ufunc-overrides.rst
+++ b/doc/neps/ufunc-overrides.rst
@@ -176,7 +176,7 @@ The ``__numpy_ufunc__`` mechanism is fully independent of Python's
 standard operator override mechanism, and the two do not interact
 directly.
 
-They however have indirect interactions, because Numpy's ``ndarray``
+They however have indirect interactions, because NumPy's ``ndarray``
 type implements its binary operations via Ufuncs. Effectively, we have::
 
     class ndarray(object):
@@ -208,14 +208,14 @@ undesirable behavior.
 
 The reason why this occurs is: because ``MyObject`` is not an ndarray
 subclass, Python resolves the expression ``b * a`` by calling first
-``b.__mul__``. Since Numpy implements this via an Ufunc, the call is
+``b.__mul__``. Since NumPy implements this via an Ufunc, the call is
 forwarded to ``__numpy_ufunc__`` and not to ``__rmul__``.  Note that if
 ``MyObject`` is a subclass of ``ndarray``, Python calls ``a.__rmul__``
 first. The issue is therefore that ``__numpy_ufunc__`` implements
 "virtual subclassing" of ndarray behavior, without actual subclassing.
 
 This issue can be resolved by a modification of the binary operation
-methods in Numpy::
+methods in NumPy::
 
     class ndarray(object):
         ...
diff --git a/doc/source/_templates/indexcontent.html b/doc/source/_templates/indexcontent.html
index e3fe3ac9b..3fbb616c6 100644
--- a/doc/source/_templates/indexcontent.html
+++ b/doc/source/_templates/indexcontent.html
@@ -3,13 +3,13 @@
   <p><strong>Parts of the documentation:</strong></p>
   <table class="contentstable" align="center"><tr>
     <td width="50%">
-      <p class="biglink"><a class="biglink" href="{{ pathto("user/index") }}">Numpy User Guide</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("user/index") }}">NumPy User Guide</a><br/>
          <span class="linkdescr">start here</span></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("reference/index") }}">Numpy Reference</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("reference/index") }}">NumPy Reference</a><br/>
          <span class="linkdescr">reference documentation</span></p>
       <p class="biglink"><a class="biglink" href="{{ pathto("f2py/index") }}">F2Py Guide</a><br/>
          <span class="linkdescr">f2py documentation</span></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("dev/index") }}">Numpy Developer Guide</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("dev/index") }}">NumPy Developer Guide</a><br/>
          <span class="linkdescr">contributing to NumPy</span></p>
     </td></tr>
   </table>
@@ -34,28 +34,28 @@
     <td width="50%">
       <p class="biglink"><a class="biglink" href="{{ pathto("bugs") }}">Reporting bugs</a></p>
       <p class="biglink"><a class="biglink" href="{{ pathto("about") }}">About NumPy</a></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("neps/index") }}">Numpy Enhancement Proposals</a><br/>
+      <p class="biglink"><a class="biglink" href="{{ pathto("neps/index") }}">NumPy Enhancement Proposals</a><br/>
     </td><td width="50%">
       <p class="biglink"><a class="biglink" href="{{ pathto("release") }}">Release Notes</a></p>
-      <p class="biglink"><a class="biglink" href="{{ pathto("license") }}">License of Numpy</a></p>
+      <p class="biglink"><a class="biglink" href="{{ pathto("license") }}">License of NumPy</a></p>
     </td></tr>
   </table>
 
   <h2>Acknowledgements</h2>
   <p>
     Large parts of this manual originate from Travis E. Oliphant's book
-    <a href="http://www.tramy.us/">"Guide to Numpy"</a> (which generously entered
+    <a href="http://www.tramy.us/">"Guide to NumPy"</a> (which generously entered
     Public Domain in August 2008). The reference documentation for many of
     the functions are written by numerous contributors and developers of
-    Numpy, both prior to and during the
-    <a href="http://docs.scipy.org/numpy/">Numpy Documentation Marathon</a>.
+    NumPy, both prior to and during the
+    <a href="http://docs.scipy.org/numpy/">NumPy Documentation Marathon</a>.
   </p>
   <p>
     The preferred way to update the documentation is by submitting a pull
     request on Github (see the 
     <a href="http://docs.scipy.org/doc/numpy-dev/dev/">Developer Guide</a>.
-    The <a href="http://docs.scipy.org/numpy/">Numpy Documentation Wiki</a>
+    The <a href="http://docs.scipy.org/numpy/">NumPy Documentation Wiki</a>
     can also still be used to submit documentation fixes.
-    Please help us to further improve the Numpy documentation!
+    Please help us to further improve the NumPy documentation!
   </p>
 {% endblock %}
diff --git a/doc/source/about.rst b/doc/source/about.rst
index 9485b5142..0f585950a 100644
--- a/doc/source/about.rst
+++ b/doc/source/about.rst
@@ -25,7 +25,7 @@ by *Numarray* and can also be used to replace *Numarray*.
 NumPy community
 ---------------
 
-Numpy is a distributed, volunteer, open-source project. *You* can help
+NumPy is a distributed, volunteer, open-source project. *You* can help
 us make it better; if you believe something should be improved either
 in functionality or in documentation, don't hesitate to contact us --- or
 even better, contact us and participate in fixing the problem.
@@ -36,11 +36,11 @@ Our main means of communication are:
 
 - `Mailing lists <http://scipy.org/Mailing_Lists>`__
 
-- `Numpy Issues <https://github.com/numpy/numpy/issues>`__ (bug reports go here)
+- `NumPy Issues <https://github.com/numpy/numpy/issues>`__ (bug reports go here)
 
-- `Old Numpy Trac <http://projects.scipy.org/numpy>`__ (no longer used)
+- `Old NumPy Trac <http://projects.scipy.org/numpy>`__ (no longer used)
 
-More information about the development of Numpy can be found at
+More information about the development of NumPy can be found at
 http://scipy.org/Developer_Zone
 
 If you want to fix issues in this documentation, the easiest way
diff --git a/doc/source/bugs.rst b/doc/source/bugs.rst
index b55be4329..950934b14 100644
--- a/doc/source/bugs.rst
+++ b/doc/source/bugs.rst
@@ -5,7 +5,7 @@ Reporting bugs
 File bug reports or feature requests, and make contributions
 (e.g. code patches), by opening a "new issue" on GitHub:
 
-- Numpy Issues: http://github.com/numpy/numpy/issues
+- NumPy Issues: http://github.com/numpy/numpy/issues
 
 Please give as much information as you can in the ticket. It is extremely
 useful if you can supply a small self-contained code snippet that reproduces
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 3324982c7..11841c1bb 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -189,7 +189,7 @@ latex_use_modindex = False
 # -----------------------------------------------------------------------------
 
 texinfo_documents = [
-  ("contents", 'numpy', 'Numpy Documentation', _stdauthor, 'Numpy',
+  ("contents", 'numpy', 'NumPy Documentation', _stdauthor, 'NumPy',
    "NumPy: array processing for numbers, strings, records, and objects.",
    'Programming',
    1),
@@ -203,7 +203,7 @@ intersphinx_mapping = {'http://docs.python.org/dev': None}
 
 
 # -----------------------------------------------------------------------------
-# Numpy extensions
+# NumPy extensions
 # -----------------------------------------------------------------------------
 
 # If we want to do a phantom import from an XML file for all autodocs
diff --git a/doc/source/contents.rst b/doc/source/contents.rst
index 1d46e8c7b..61c0037fc 100644
--- a/doc/source/contents.rst
+++ b/doc/source/contents.rst
@@ -1,5 +1,5 @@
 #####################
-Numpy manual contents
+NumPy manual contents
 #####################
 
 .. toctree::
diff --git a/doc/source/dev/development_environment.rst b/doc/source/dev/development_environment.rst
index 41e874362..e6df9803c 100644
--- a/doc/source/dev/development_environment.rst
+++ b/doc/source/dev/development_environment.rst
@@ -11,7 +11,7 @@ Since NumPy contains parts written in C and Cython that need to be
 compiled before use, make sure you have the necessary compilers and Python
 development headers installed - see :ref:`building-from-source`.
 
-Having compiled code also means that importing Numpy from the development
+Having compiled code also means that importing NumPy from the development
 sources needs some additional steps, which are explained below.  For the rest
 of this chapter we assume that you have set up your git repo as described in
 :ref:`using-git`.
@@ -28,7 +28,7 @@ do one of::
     $ python runtests.py --bench
     $ python runtests.py -g -m full
 
-This builds Numpy first, so the first time it may take a few minutes.  If
+This builds NumPy first, so the first time it may take a few minutes.  If
 you specify ``-n``, the tests are run against the version of NumPy (if
 any) found on current PYTHONPATH.
 
@@ -169,7 +169,7 @@ repo, use one of::
 Debugging
 ---------
 
-Another frequently asked question is "How do I debug C code inside Numpy?".
+Another frequently asked question is "How do I debug C code inside NumPy?".
 The easiest way to do this is to first write a Python script that invokes the C
 code whose execution you want to debug. For instance ``mytest.py``::
 
diff --git a/doc/source/dev/gitwash/development_workflow.rst b/doc/source/dev/gitwash/development_workflow.rst
index b6b544455..b788a042c 100644
--- a/doc/source/dev/gitwash/development_workflow.rst
+++ b/doc/source/dev/gitwash/development_workflow.rst
@@ -470,10 +470,10 @@ backport.
 Pushing changes to the main repo
 ================================
 
-*This is only relevant if you have commit rights to the main Numpy repo.*
+*This is only relevant if you have commit rights to the main NumPy repo.*
 
 When you have a set of "ready" changes in a feature branch ready for
-Numpy's ``master`` or ``maintenance`` branches, you can push
+NumPy's ``master`` or ``maintenance`` branches, you can push
 them to ``upstream`` as follows:
 
 1. First, merge or rebase on the target branch.
diff --git a/doc/source/dev/index.rst b/doc/source/dev/index.rst
index cb71a3e5c..543194119 100644
--- a/doc/source/dev/index.rst
+++ b/doc/source/dev/index.rst
@@ -1,5 +1,5 @@
 #####################
-Contributing to Numpy
+Contributing to NumPy
 #####################
 
 .. toctree::
diff --git a/doc/source/f2py/distutils.rst b/doc/source/f2py/distutils.rst
index 4a318452e..fdcd38468 100644
--- a/doc/source/f2py/distutils.rst
+++ b/doc/source/f2py/distutils.rst
@@ -2,7 +2,7 @@
 Using via `numpy.distutils`
 =============================
 
-:mod:`numpy.distutils` is part of Numpy extending standard Python ``distutils``
+:mod:`numpy.distutils` is part of NumPy extending standard Python ``distutils``
 to deal with Fortran sources and F2PY signature files, e.g. compile Fortran
 sources, call F2PY to construct extension modules, etc.
 
diff --git a/doc/source/f2py/getting-started.rst b/doc/source/f2py/getting-started.rst
index ae01d204e..b54d1aba8 100644
--- a/doc/source/f2py/getting-started.rst
+++ b/doc/source/f2py/getting-started.rst
@@ -95,7 +95,7 @@ Python the Fortran subroutine ``FIB`` is accessible via ``fib1.fib``::
     F2PY implements basic compatibility checks between related
     arguments in order to avoid any unexpected crashes.
 
-  * When a Numpy array, that is Fortran contiguous and has a dtype
+  * When a NumPy array, that is Fortran contiguous and has a dtype
     corresponding to presumed Fortran type, is used as an input array
     argument, then its C pointer is directly passed to Fortran.
 
@@ -209,7 +209,7 @@ In Python::
   * Clearly, the signature of ``fib2.fib`` now corresponds to the
     intention of Fortran subroutine ``FIB`` more closely: given the
     number ``n``, ``fib2.fib`` returns the first ``n`` Fibonacci numbers
-    as a Numpy array. Also, the new Python signature ``fib2.fib``
+    as a NumPy array. Also, the new Python signature ``fib2.fib``
     rules out any surprises that we experienced with ``fib1.fib``.
 
   * Note that by default using single ``intent(out)`` also implies
diff --git a/doc/source/f2py/python-usage.rst b/doc/source/f2py/python-usage.rst
index c7c7e3fd0..f5f1d2304 100644
--- a/doc/source/f2py/python-usage.rst
+++ b/doc/source/f2py/python-usage.rst
@@ -66,7 +66,7 @@ String arguments
 
 F2PY generated wrapper functions accept (almost) any Python object as
 a string argument, ``str`` is applied for non-string objects.
-Exceptions are Numpy arrays that must have type code ``'c'`` or
+Exceptions are NumPy arrays that must have type code ``'c'`` or
 ``'1'`` when used as string arguments.
 
 A string can have arbitrary length when using it as a string argument
@@ -95,7 +95,7 @@ Array arguments
 ================
 
 In general, array arguments of F2PY generated wrapper functions accept
-arbitrary sequences that can be transformed to Numpy array objects.
+arbitrary sequences that can be transformed to NumPy array objects.
 An exception is ``intent(inout)`` array arguments that always must be
 proper-contiguous and have proper type, otherwise an exception is
 raised. Another exception is ``intent(inplace)`` array arguments that
@@ -103,13 +103,13 @@ attributes will be changed in-situ if the argument has different type
 than expected (see ``intent(inplace)`` attribute for more
 information).
 
-In general, if a Numpy array is proper-contiguous and has a proper
+In general, if a NumPy array is proper-contiguous and has a proper
 type then it is directly passed to wrapped Fortran/C function.
 Otherwise, an element-wise copy of an input array is made and the
 copy, being proper-contiguous and with proper type, is used as an
 array argument.
 
-There are two types of proper-contiguous Numpy arrays:
+There are two types of proper-contiguous NumPy arrays:
 
 * Fortran-contiguous arrays when data is stored column-wise,
   i.e. indexing of data as stored in memory starts from the lowest
@@ -130,7 +130,7 @@ and C-contiguous if the order is as follows::
   A[0,0] A[0,1] A[1,0] A[1,1]
 
 To test whether an array is C-contiguous, use ``.iscontiguous()``
-method of Numpy arrays.  To test for Fortran contiguity, all
+method of NumPy arrays.  To test for Fortran contiguity, all
 F2PY generated extension modules provide a function
 ``has_column_major_storage(<array>)``. This function is equivalent to
 ``<array>.flags.f_contiguous`` but more efficient.
@@ -313,7 +313,7 @@ with the current extension module, but not to other extension modules
 (this restriction is due to how Python imports shared libraries).  In
 Python, the F2PY wrappers to ``common`` blocks are ``fortran`` type
 objects that have (dynamic) attributes related to data members of
-common blocks. When accessed, these attributes return as Numpy array
+common blocks. When accessed, these attributes return as NumPy array
 objects (multidimensional arrays are Fortran-contiguous) that
 directly link to data members in common blocks. Data members can be
 changed by direct assignment or by in-place changes to the
diff --git a/doc/source/f2py/signature-file.rst b/doc/source/f2py/signature-file.rst
index a8924712f..6afcdeb8c 100644
--- a/doc/source/f2py/signature-file.rst
+++ b/doc/source/f2py/signature-file.rst
@@ -348,9 +348,9 @@ The following attributes are used by F2PY:
   + ``inout``
       The argument is considered as an input/output or *in situ*
       output argument. ``intent(inout)`` arguments can be only
-      "contiguous" Numpy arrays with proper type and size.  Here
+      "contiguous" NumPy arrays with proper type and size.  Here
       "contiguous" can be either in Fortran or C sense. The latter one
-      coincides with the contiguous concept used in Numpy and is
+      coincides with the contiguous concept used in NumPy and is
       effective only if ``intent(c)`` is used. Fortran contiguity
       is assumed by default.
 
@@ -360,7 +360,7 @@ The following attributes are used by F2PY:
   + ``inplace``
       The argument is considered as an input/output or *in situ*
       output argument. ``intent(inplace)`` arguments must be
-      Numpy arrays with proper size. If the type of an array is
+      NumPy arrays with proper size. If the type of an array is
       not "proper" or the array is non-contiguous then the array
       will be changed in-place to fix the type and make it contiguous.
 
diff --git a/doc/source/license.rst b/doc/source/license.rst
index 2b3b7ebd3..8f360af88 100644
--- a/doc/source/license.rst
+++ b/doc/source/license.rst
@@ -1,5 +1,5 @@
 *************
-Numpy License
+NumPy License
 *************
 
 Copyright (c) 2005, NumPy Developers
diff --git a/doc/source/neps/index.rst b/doc/source/neps/index.rst
index 94cf563a4..de4cd64b6 100644
--- a/doc/source/neps/index.rst
+++ b/doc/source/neps/index.rst
@@ -1,10 +1,10 @@
 ===========================
-Numpy Enhancement Proposals
+NumPy Enhancement Proposals
 ===========================
 
-Numpy Enhancement Proposals (NEPs) describe proposed changes to Numpy.
+NumPy Enhancement Proposals (NEPs) describe proposed changes to NumPy.
 NEPs are modeled on Python Enhancement Proposals (PEPs), and are typically
-written up when large changes to Numpy are proposed.
+written up when large changes to NumPy are proposed.
 
 This page provides an overview of all NEPs, making only a distinction between
 the ones that have been implemented and those that have not been implemented.
diff --git a/doc/source/reference/arrays.classes.rst b/doc/source/reference/arrays.classes.rst
index b82f7d33c..298e81717 100644
--- a/doc/source/reference/arrays.classes.rst
+++ b/doc/source/reference/arrays.classes.rst
@@ -37,14 +37,14 @@ Special attributes and methods
 
 .. seealso:: :ref:`Subclassing ndarray <basics.subclassing>`
 
-Numpy provides several hooks that classes can customize:
+NumPy provides several hooks that classes can customize:
 
 .. method:: class.__numpy_ufunc__(ufunc, method, i, inputs, **kwargs)
 
    .. versionadded:: 1.11
 
    Any class (ndarray subclass or not) can define this method to
-   override behavior of Numpy's ufuncs. This works quite similarly to
+   override behavior of NumPy's ufuncs. This works quite similarly to
    Python's ``__mul__`` and other binary operation routines.
 
    - *ufunc* is the ufunc object that was called.
@@ -336,7 +336,7 @@ Record arrays (:mod:`numpy.rec`)
 .. seealso:: :ref:`routines.array-creation.rec`, :ref:`routines.dtype`,
              :ref:`arrays.dtypes`.
 
-Numpy provides the :class:`recarray` class which allows accessing the
+NumPy provides the :class:`recarray` class which allows accessing the
 fields of a structured array as attributes, and a corresponding
 scalar data type object :class:`record`.
 
diff --git a/doc/source/reference/arrays.dtypes.rst b/doc/source/reference/arrays.dtypes.rst
index 2db32e30d..01a969826 100644
--- a/doc/source/reference/arrays.dtypes.rst
+++ b/doc/source/reference/arrays.dtypes.rst
@@ -29,14 +29,14 @@ following aspects of the data:
    pair: dtype; scalar
 
 To describe the type of scalar data, there are several :ref:`built-in
-scalar types <arrays.scalars.built-in>` in Numpy for various precision
+scalar types <arrays.scalars.built-in>` in NumPy for various precision
 of integers, floating-point numbers, *etc*. An item extracted from an
 array, *e.g.*, by indexing, will be a Python object whose type is the
 scalar type associated with the data type of the array.
 
 Note that the scalar types are not :class:`dtype` objects, even though
 they can be used in place of one whenever a data type specification is
-needed in Numpy.
+needed in NumPy.
 
 .. index::
    pair: dtype; field
@@ -459,7 +459,7 @@ Type strings
 :class:`dtype`
 ==============
 
-Numpy data type descriptions are instances of the :class:`dtype` class.
+NumPy data type descriptions are instances of the :class:`dtype` class.
 
 Attributes
 ----------
diff --git a/doc/source/reference/arrays.indexing.rst b/doc/source/reference/arrays.indexing.rst
index 6e9bb9276..b7bc3a655 100644
--- a/doc/source/reference/arrays.indexing.rst
+++ b/doc/source/reference/arrays.indexing.rst
@@ -3,7 +3,7 @@
 Indexing
 ========
 
-.. sectionauthor:: adapted from "Guide to Numpy" by Travis E. Oliphant
+.. sectionauthor:: adapted from "Guide to NumPy" by Travis E. Oliphant
 
 .. currentmodule:: numpy
 
diff --git a/doc/source/reference/arrays.ndarray.rst b/doc/source/reference/arrays.ndarray.rst
index b68e40e3f..bd6821b62 100644
--- a/doc/source/reference/arrays.ndarray.rst
+++ b/doc/source/reference/arrays.ndarray.rst
@@ -103,7 +103,7 @@ the bytes are interpreted is defined by the :ref:`data-type object
 
 A segment of memory is inherently 1-dimensional, and there are many
 different schemes for arranging the items of an *N*-dimensional array
-in a 1-dimensional block. Numpy is flexible, and :class:`ndarray`
+in a 1-dimensional block. NumPy is flexible, and :class:`ndarray`
 objects can accommodate any *strided indexing scheme*. In a strided
 scheme, the N-dimensional index :math:`(n_0, n_1, ..., n_{N-1})`
 corresponds to the offset (in bytes):
@@ -155,7 +155,7 @@ base offset itself is a multiple of `self.itemsize`.
 .. note::
 
     Points (1) and (2) are not yet applied by default. Beginning with
-    Numpy 1.8.0, they are applied consistently only if the environment
+    NumPy 1.8.0, they are applied consistently only if the environment
     variable ``NPY_RELAXED_STRIDES_CHECKING=1`` was defined when NumPy
     was built. Eventually this will become the default.
 
@@ -440,7 +440,7 @@ Each of the arithmetic operations (``+``, ``-``, ``*``, ``/``, ``//``,
 ``%``, ``divmod()``, ``**`` or ``pow()``, ``<<``, ``>>``, ``&``,
 ``^``, ``|``, ``~``) and the comparisons (``==``, ``<``, ``>``,
 ``<=``, ``>=``, ``!=``) is equivalent to the corresponding
-:term:`universal function` (or :term:`ufunc` for short) in Numpy.  For
+:term:`universal function` (or :term:`ufunc` for short) in NumPy.  For
 more information, see the section on :ref:`Universal Functions
 <ufuncs>`.
 
@@ -560,7 +560,7 @@ Matrix Multiplication:
 .. note::
 
    Matrix operators ``@`` and ``@=`` were introduced in Python 3.5
-   following PEP465. Numpy 1.10 has a preliminary implementation of ``@``
+   following PEP465. NumPy 1.10 has a preliminary implementation of ``@``
    for testing purposes. Further documentation can be found in the
    :func:`matmul` documentation.
 
diff --git a/doc/source/reference/arrays.rst b/doc/source/reference/arrays.rst
index 40c9f755d..faa91a389 100644
--- a/doc/source/reference/arrays.rst
+++ b/doc/source/reference/arrays.rst
@@ -20,7 +20,7 @@ with every array. In addition to basic types (integers, floats,
 
 An item extracted from an array, *e.g.*, by indexing, is represented
 by a Python object whose type is one of the :ref:`array scalar types
-<arrays.scalars>` built in Numpy. The array scalars allow easy manipulation
+<arrays.scalars>` built in NumPy. The array scalars allow easy manipulation
 of also more complicated arrangements of data.
 
 .. figure:: figures/threefundamental.png
diff --git a/doc/source/reference/arrays.scalars.rst b/doc/source/reference/arrays.scalars.rst
index f8fad0095..4acaf1b3b 100644
--- a/doc/source/reference/arrays.scalars.rst
+++ b/doc/source/reference/arrays.scalars.rst
@@ -94,7 +94,7 @@ Python Boolean scalar.
    :class:`int` built-in under Python 3, because type :class:`int` is no
    longer a fixed-width integer type.
 
-.. tip:: The default data type in Numpy is :class:`float_`.
+.. tip:: The default data type in NumPy is :class:`float_`.
 
 In the tables below, ``platform?`` means that the type may not be
 available on all platforms. Compatibility with different C or Python
@@ -288,4 +288,4 @@ the built-in scalar types): One way is to simply subclass the
 a degree, but internally certain behaviors are fixed by the data type of 
 the array.  To fully customize the data type of an array you need to 
 define a new data-type, and register it with NumPy. Such new types can only 
-be defined in C, using the :ref:`Numpy C-API <c-api>`.
+be defined in C, using the :ref:`NumPy C-API <c-api>`.
diff --git a/doc/source/reference/c-api.array.rst b/doc/source/reference/c-api.array.rst
index 049c7b537..4ab276d9a 100644
--- a/doc/source/reference/c-api.array.rst
+++ b/doc/source/reference/c-api.array.rst
@@ -2291,7 +2291,7 @@ an element copier function as a primitive.::
 Array Iterators
 ---------------
 
-As of Numpy 1.6, these array iterators are superceded by
+As of NumPy 1.6, these array iterators are superceded by
 the new array iterator, :c:type:`NpyIter`.
 
 An array iterator is a simple way to access the elements of an
diff --git a/doc/source/reference/c-api.config.rst b/doc/source/reference/c-api.config.rst
index 17d7f557d..60bf61a32 100644
--- a/doc/source/reference/c-api.config.rst
+++ b/doc/source/reference/c-api.config.rst
@@ -4,14 +4,14 @@ System configuration
 .. sectionauthor:: Travis E. Oliphant
 
 When NumPy is built, information about system configuration is
-recorded, and is made available for extension modules using Numpy's C
+recorded, and is made available for extension modules using NumPy's C
 API.  These are mostly defined in ``numpyconfig.h`` (included in
 ``ndarrayobject.h``). The public symbols are prefixed by ``NPY_*``.
-Numpy also offers some functions for querying information about the
+NumPy also offers some functions for querying information about the
 platform in use.
 
-For private use, Numpy also constructs a ``config.h`` in the NumPy
-include directory, which is not exported by Numpy (that is a python
+For private use, NumPy also constructs a ``config.h`` in the NumPy
+include directory, which is not exported by NumPy (that is a python
 extension which use the numpy C API will not see those symbols), to
 avoid namespace pollution.
 
diff --git a/doc/source/reference/c-api.coremath.rst b/doc/source/reference/c-api.coremath.rst
index 08b1adb3a..9027a4e0d 100644
--- a/doc/source/reference/c-api.coremath.rst
+++ b/doc/source/reference/c-api.coremath.rst
@@ -1,4 +1,4 @@
-Numpy core libraries
+NumPy core libraries
 ====================
 
 .. sectionauthor:: David Cournapeau
@@ -10,7 +10,7 @@ Starting from numpy 1.3.0, we are working on separating the pure C,
 making the code cleaner, and enabling code reuse by other extensions outside
 numpy (scipy, etc...).
 
-Numpy core math library
+NumPy core math library
 -----------------------
 
 The numpy core math library ('npymath') is a first step in this direction. This
diff --git a/doc/source/reference/c-api.generalized-ufuncs.rst b/doc/source/reference/c-api.generalized-ufuncs.rst
index 92dc8aec0..d34a9d4d4 100644
--- a/doc/source/reference/c-api.generalized-ufuncs.rst
+++ b/doc/source/reference/c-api.generalized-ufuncs.rst
@@ -4,7 +4,7 @@ Generalized Universal Function API
 
 There is a general need for looping over not only functions on scalars
 but also over functions on vectors (or arrays).
-This concept is realized in Numpy by generalizing the universal functions
+This concept is realized in NumPy by generalizing the universal functions
 (ufuncs).  In regular ufuncs, the elementary function is limited to
 element-by-element operations, whereas the generalized version (gufuncs)
 supports "sub-array" by "sub-array" operations.  The Perl vector library PDL
@@ -60,7 +60,7 @@ output array of the right size. If the size of a core dimension of an output
 cannot be determined from a passed in input or output array, an error will be
 raised.
 
-Note: Prior to Numpy 1.10.0, less strict checks were in place: missing core
+Note: Prior to NumPy 1.10.0, less strict checks were in place: missing core
 dimensions were created by prepending 1's to the shape as necessary, core
 dimensions with the same label were broadcast together, and undetermined
 dimensions were created with size 1.
diff --git a/doc/source/reference/c-api.rst b/doc/source/reference/c-api.rst
index b1a5eb477..b8cbe97b2 100644
--- a/doc/source/reference/c-api.rst
+++ b/doc/source/reference/c-api.rst
@@ -1,7 +1,7 @@
 .. _c-api:
 
 ###########
-Numpy C-API
+NumPy C-API
 ###########
 
 .. sectionauthor:: Travis E. Oliphant
diff --git a/doc/source/reference/index.rst b/doc/source/reference/index.rst
index 9e0ef68db..f74816d6f 100644
--- a/doc/source/reference/index.rst
+++ b/doc/source/reference/index.rst
@@ -11,7 +11,7 @@ NumPy Reference
 .. module:: numpy
 
 This reference manual details functions, modules, and objects
-included in Numpy, describing what they are and what they do.
+included in NumPy, describing what they are and what they do.
 For learning how to use NumPy, see also :ref:`user`.
 
 
@@ -31,11 +31,11 @@ Acknowledgements
 ================
 
 Large parts of this manual originate from Travis E. Oliphant's book
-`Guide to Numpy <http://www.tramy.us/>`__ (which generously entered
+`Guide to NumPy <http://www.tramy.us/>`__ (which generously entered
 Public Domain in August 2008). The reference documentation for many of
 the functions are written by numerous contributors and developers of
-Numpy, both prior to and during the
-`Numpy Documentation Marathon
+NumPy, both prior to and during the
+`NumPy Documentation Marathon
 <http://scipy.org/Developer_Zone/DocMarathon2008>`__.
 
 Please help to improve NumPy's documentation! Instructions on how to
diff --git a/doc/source/reference/internals.code-explanations.rst b/doc/source/reference/internals.code-explanations.rst
index f946d0420..fca87f260 100644
--- a/doc/source/reference/internals.code-explanations.rst
+++ b/doc/source/reference/internals.code-explanations.rst
@@ -1,7 +1,7 @@
 .. currentmodule:: numpy
 
 *************************
-Numpy C Code Explanations
+NumPy C Code Explanations
 *************************
 
     Fanaticism consists of redoubling your efforts when you have forgotten
diff --git a/doc/source/reference/internals.rst b/doc/source/reference/internals.rst
index c9716813d..e1d6644a6 100644
--- a/doc/source/reference/internals.rst
+++ b/doc/source/reference/internals.rst
@@ -1,5 +1,5 @@
 ***************
-Numpy internals
+NumPy internals
 ***************
 
 .. toctree::
diff --git a/doc/source/reference/routines.help.rst b/doc/source/reference/routines.help.rst
index a41563cce..9b6eb4ad3 100644
--- a/doc/source/reference/routines.help.rst
+++ b/doc/source/reference/routines.help.rst
@@ -1,6 +1,6 @@
 .. _routines.help:
 
-Numpy-specific help functions
+NumPy-specific help functions
 =============================
 
 .. currentmodule:: numpy
diff --git a/doc/source/reference/routines.io.rst b/doc/source/reference/routines.io.rst
index ff8c05c16..6747f60bd 100644
--- a/doc/source/reference/routines.io.rst
+++ b/doc/source/reference/routines.io.rst
@@ -3,7 +3,7 @@ Input and output
 
 .. currentmodule:: numpy
 
-Numpy binary files (NPY, NPZ)
+NumPy binary files (NPY, NPZ)
 -----------------------------
 .. autosummary::
    :toctree: generated/
diff --git a/doc/source/reference/routines.numarray.rst b/doc/source/reference/routines.numarray.rst
index 713f99d30..3bbc413d7 100644
--- a/doc/source/reference/routines.numarray.rst
+++ b/doc/source/reference/routines.numarray.rst
@@ -2,4 +2,4 @@
 Numarray compatibility
 **********************
 
-The numarray module was removed in Numpy 1.9.
+The numarray module was removed in NumPy 1.9.
diff --git a/doc/source/reference/routines.oldnumeric.rst b/doc/source/reference/routines.oldnumeric.rst
index e83331d01..2120fc69e 100644
--- a/doc/source/reference/routines.oldnumeric.rst
+++ b/doc/source/reference/routines.oldnumeric.rst
@@ -4,4 +4,4 @@ Old Numeric compatibility
 
 .. currentmodule:: numpy
 
-The oldnumeric module was removed in Numpy 1.9.0.
+The oldnumeric module was removed in NumPy 1.9.0.
diff --git a/doc/source/reference/routines.other.rst b/doc/source/reference/routines.other.rst
index b7a924eba..4a027b5a1 100644
--- a/doc/source/reference/routines.other.rst
+++ b/doc/source/reference/routines.other.rst
@@ -32,7 +32,7 @@ Memory ranges
    shares_memory
    may_share_memory
 
-Numpy version comparison
+NumPy version comparison
 ------------------------
 .. autosummary::
    :toctree: generated/
diff --git a/doc/source/reference/routines.polynomials.classes.rst b/doc/source/reference/routines.polynomials.classes.rst
index c40795434..0db77eb7c 100644
--- a/doc/source/reference/routines.polynomials.classes.rst
+++ b/doc/source/reference/routines.polynomials.classes.rst
@@ -39,7 +39,7 @@ All of the classes have the same methods, and especially they implement the
 Python numeric operators +, -, \*, //, %, divmod, \*\*, ==,
 and !=. The last two can be a bit problematic due to floating point
 roundoff errors. We now give a quick demonstration of the various
-operations using Numpy version 1.7.0.
+operations using NumPy version 1.7.0.
 
 Basics
 ------
diff --git a/doc/source/reference/swig.interface-file.rst b/doc/source/reference/swig.interface-file.rst
index 1d6fbe04d..36b226b9b 100644
--- a/doc/source/reference/swig.interface-file.rst
+++ b/doc/source/reference/swig.interface-file.rst
@@ -1,4 +1,4 @@
-Numpy.i: a SWIG Interface File for NumPy
+NumPy.i: a SWIG Interface File for NumPy
 ========================================
 
 Introduction
@@ -555,7 +555,7 @@ If you get a Python error that looks like the following::
 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.
+NumPy array scalars in addition to the standard integer types.
 Fortunately, this capabilitiy has been provided for you.  Simply copy
 the file::
 
diff --git a/doc/source/reference/swig.rst b/doc/source/reference/swig.rst
index 3931b8e11..6865cc96a 100644
--- a/doc/source/reference/swig.rst
+++ b/doc/source/reference/swig.rst
@@ -1,5 +1,5 @@
 **************
-Numpy and SWIG
+NumPy and SWIG
 **************
 
 .. sectionauthor:: Bill Spotz
diff --git a/doc/source/reference/ufuncs.rst b/doc/source/reference/ufuncs.rst
index 7f38135e9..62e90b83c 100644
--- a/doc/source/reference/ufuncs.rst
+++ b/doc/source/reference/ufuncs.rst
@@ -1,4 +1,4 @@
-.. sectionauthor:: adapted from "Guide to Numpy" by Travis E. Oliphant
+.. sectionauthor:: adapted from "Guide to NumPy" by Travis E. Oliphant
 
 .. _ufuncs:
 
@@ -20,7 +20,7 @@ is, a ufunc is a ":term:`vectorized`" wrapper for a function that
 takes a fixed number of scalar inputs and produces a fixed number of
 scalar outputs.
 
-In Numpy, universal functions are instances of the
+In NumPy, universal functions are instances of the
 :class:`numpy.ufunc` class. Many of the built-in functions are
 implemented in compiled C code, but :class:`ufunc` instances can also
 be produced using the :func:`frompyfunc` factory function.
diff --git a/doc/source/user/basics.io.genfromtxt.rst b/doc/source/user/basics.io.genfromtxt.rst
index 1fd7e7b65..1fed3fe8e 100644
--- a/doc/source/user/basics.io.genfromtxt.rst
+++ b/doc/source/user/basics.io.genfromtxt.rst
@@ -4,7 +4,7 @@
 Importing data with :func:`~numpy.genfromtxt`
 *********************************************
 
-Numpy provides several functions to create arrays from tabular data.
+NumPy provides several functions to create arrays from tabular data.
 We focus here on the :func:`~numpy.genfromtxt` function.
 
 In a nutshell, :func:`~numpy.genfromtxt` runs two main loops.  The first
@@ -325,7 +325,7 @@ takes any format string::
 Validating names
 ----------------
 
-Numpy arrays with a structured dtype can also be viewed as
+NumPy arrays with a structured dtype can also be viewed as
 :class:`~numpy.recarray`, where a field can be accessed as if it were an
 attribute.  For that reason, we may need to make sure that the field name
 doesn't contain any space or invalid character, or that it does not
diff --git a/doc/source/user/basics.io.rst b/doc/source/user/basics.io.rst
index 54a65662b..c0c96dcec 100644
--- a/doc/source/user/basics.io.rst
+++ b/doc/source/user/basics.io.rst
@@ -1,5 +1,5 @@
 **************
-I/O with Numpy
+I/O with NumPy
 **************
 
 .. toctree::
diff --git a/doc/source/user/basics.rst b/doc/source/user/basics.rst
index 1d91cc55c..7875aff6e 100644
--- a/doc/source/user/basics.rst
+++ b/doc/source/user/basics.rst
@@ -1,5 +1,5 @@
 ************
-Numpy basics
+NumPy basics
 ************
 
 .. toctree::
diff --git a/doc/source/user/building.rst b/doc/source/user/building.rst
index 5cb143f38..2e7e1823c 100644
--- a/doc/source/user/building.rst
+++ b/doc/source/user/building.rst
@@ -47,8 +47,8 @@ Building NumPy requires the following software installed:
 
 4) Cython
 
-   To build development versions of Numpy, you'll need a recent version of
-   Cython.  Released Numpy sources on PyPi include the C files generated from
+   To build development versions of NumPy, you'll need a recent version of
+   Cython.  Released NumPy sources on PyPi include the C files generated from
    Cython code, so for released versions having Cython installed isn't needed.
 
 Basic Installation
@@ -121,7 +121,7 @@ is almost always a very bad idea.
 Disabling ATLAS and other accelerated libraries
 -----------------------------------------------
 
-Usage of ATLAS and other accelerated libraries in Numpy can be disabled
+Usage of ATLAS and other accelerated libraries in NumPy can be disabled
 via::
 
     BLAS=None LAPACK=None ATLAS=None python setup.py build
diff --git a/doc/source/user/c-info.rst b/doc/source/user/c-info.rst
index 2fb50c5ef..0ac0ed26d 100644
--- a/doc/source/user/c-info.rst
+++ b/doc/source/user/c-info.rst
@@ -1,5 +1,5 @@
 #################
-Using Numpy C-API
+Using NumPy C-API
 #################
 
 .. toctree::
diff --git a/doc/source/user/c-info.ufunc-tutorial.rst b/doc/source/user/c-info.ufunc-tutorial.rst
index f064fbcc9..ba481a544 100644
--- a/doc/source/user/c-info.ufunc-tutorial.rst
+++ b/doc/source/user/c-info.ufunc-tutorial.rst
@@ -18,7 +18,7 @@ Before reading this, it may help to familiarize yourself with the basics
 of C extensions for Python by reading/skimming the tutorials in Section 1
 of `Extending and Embedding the Python Interpreter
 <http://docs.python.org/extending/index.html>`_ and in `How to extend
-Numpy <http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html>`_
+NumPy <http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html>`_
 
 The umath module is a computer-generated C-module that creates many
 ufuncs. It provides a great many examples of how to create a universal
@@ -245,9 +245,9 @@ logit ufuncs constructed below, the logit ufuncs were almost exactly
 depending on the nature of the function.
 
 
-.. _`sec:Numpy-one-loop`:
+.. _`sec:NumPy-one-loop`:
 
-Example Numpy ufunc for one dtype
+Example NumPy ufunc for one dtype
 =================================
 
 .. index::
@@ -273,7 +273,7 @@ the primary thing that must be changed to create your own ufunc.
         /*
          * single_type_logit.c
          * This is the C code for creating your own
-         * Numpy ufunc for a logit function.
+         * NumPy ufunc for a logit function.
          *
          * In this code we only define the ufunc for
          * a single dtype. The computations that must
@@ -443,9 +443,9 @@ array([       -inf, -1.09861229,  0.        ,  1.09861229,         inf])
 
 
 
-.. _`sec:Numpy-many-loop`:
+.. _`sec:NumPy-many-loop`:
 
-Example Numpy ufunc with multiple dtypes
+Example NumPy ufunc with multiple dtypes
 ========================================
 
 .. index::
@@ -473,7 +473,7 @@ the primary thing that must be changed to create your own ufunc.
         /*
          * multi_type_logit.c
          * This is the C code for creating your own
-         * Numpy ufunc for a logit function.
+         * NumPy ufunc for a logit function.
          *
          * Each function of the form type_logit defines the
          * logit function for a different numpy dtype. Each
@@ -728,9 +728,9 @@ array([       -inf, -1.09861229,  0.        ,  1.09861229,         inf])
 
 
 
-.. _`sec:Numpy-many-arg`:
+.. _`sec:NumPy-many-arg`:
 
-Example Numpy ufunc with multiple arguments/return values
+Example NumPy ufunc with multiple arguments/return values
 =========================================================
 
 Our final example is a ufunc with multiple arguments. It is a modification
@@ -738,7 +738,7 @@ of the code for a logit ufunc for data with a single dtype. We
 compute (A*B, logit(A*B)).
 
 We only give the C code as the setup.py file is exactly the same as
-the setup.py file in `Example Numpy ufunc for one dtype`_, except that
+the setup.py file in `Example NumPy ufunc for one dtype`_, except that
 the line
 
     .. code-block:: python
@@ -767,7 +767,7 @@ as well as all other properties of a ufunc.
         /*
          * multi_arg_logit.c
          * This is the C code for creating your own
-         * Numpy ufunc for a multiple argument, multiple
+         * NumPy ufunc for a multiple argument, multiple
          * return value ufunc. The places where the
          * ufunc computation is carried out are marked
          * with comments.
@@ -885,9 +885,9 @@ as well as all other properties of a ufunc.
         #endif
 
 
-.. _`sec:Numpy-struct-dtype`:
+.. _`sec:NumPy-struct-dtype`:
 
-Example Numpy ufunc with structured array dtype arguments
+Example NumPy ufunc with structured array dtype arguments
 =========================================================
 
 This example shows how to create a ufunc for a structured array dtype.
@@ -898,7 +898,7 @@ custom dtypes and structured array dtypes. We need to also call
 PyUFunc_RegisterLoopForDescr to finish setting up the ufunc.
 
 We only give the C code as the setup.py file is exactly the same as
-the setup.py file in `Example Numpy ufunc for one dtype`_, except that
+the setup.py file in `Example NumPy ufunc for one dtype`_, except that
 the line
 
     .. code-block:: python
@@ -925,7 +925,7 @@ The C file is given below.
         /*
          * add_triplet.c
          * This is the C code for creating your own
-         * Numpy ufunc for a structured array dtype.
+         * NumPy ufunc for a structured array dtype.
          *
          * Details explaining the Python-C API can be found under
          * 'Extending and Embedding' and 'Python/C API' at
diff --git a/doc/source/user/numpy-for-matlab-users.rst b/doc/source/user/numpy-for-matlab-users.rst
index c3179b182..cf019f630 100644
--- a/doc/source/user/numpy-for-matlab-users.rst
+++ b/doc/source/user/numpy-for-matlab-users.rst
@@ -1,7 +1,7 @@
 .. _numpy-for-matlab-users:
 
 ======================
-Numpy for Matlab users
+NumPy for Matlab users
 ======================
 
 Introduction
@@ -63,7 +63,7 @@ Some Key Differences
 'array' or 'matrix'? Which should I use?
 ========================================
 
-Numpy provides, in addition to ``np.ndarray``, an additional matrix type
+NumPy provides, in addition to ``np.ndarray``, an additional matrix type
 that you may see used in some existing code. Which one to use?
 
 Short answer
@@ -84,7 +84,7 @@ product, matrix vector multiplication etc.).
 Long answer
 -----------
 
-Numpy contains both an ``array`` class and a ``matrix`` class. The
+NumPy contains both an ``array`` class and a ``matrix`` class. The
 ``array`` class is intended to be a general-purpose n-dimensional array
 for many kinds of numerical computing, while ``matrix`` is intended to
 facilitate linear algebra computations specifically. In practice there
@@ -171,7 +171,7 @@ The ``array`` is thus much more advisable to use.
 Facilities for Matrix Users
 ===========================
 
-Numpy has some features that facilitate the use of the ``matrix`` type,
+NumPy has some features that facilitate the use of the ``matrix`` type,
 which hopefully make things easier for Matlab converts.
 
 -  A ``matlib`` module has been added that contains matrix versions of
@@ -521,21 +521,21 @@ Linear Algebra Equivalents
 
    * - ``a & b``
      - ``logical_and(a,b)``
-     - element-by-element AND operator (Numpy ufunc) :ref:`See note
+     - element-by-element AND operator (NumPy ufunc) :ref:`See note
        LOGICOPS <numpy-for-matlab-users.notes>`
 
    * - ``a | b``
      - ``logical_or(a,b)``
-     - element-by-element OR operator (Numpy ufunc) :ref:`See note LOGICOPS
+     - element-by-element OR operator (NumPy ufunc) :ref:`See note LOGICOPS
        <numpy-for-matlab-users.notes>`
 
    * - ``bitand(a,b)``
      - ``a & b``
-     - bitwise AND operator (Python native and Numpy ufunc)
+     - bitwise AND operator (Python native and NumPy ufunc)
 
    * - ``bitor(a,b)``
      - ``a | b``
-     - bitwise OR operator (Python native and Numpy ufunc)
+     - bitwise OR operator (Python native and NumPy ufunc)
 
    * - ``inv(a)``
      - ``linalg.inv(a)``
@@ -657,41 +657,41 @@ numpy to have a similarly terse range construction mechanism. Note that
 *indexed* using square brackets, which allows the use of Python's slice
 syntax in the arguments.
 
-\ **LOGICOPS**: & or \| in Numpy is bitwise AND/OR, while in Matlab &
+\ **LOGICOPS**: & or \| in NumPy is bitwise AND/OR, while in Matlab &
 and \| are logical AND/OR. The difference should be clear to anyone with
 significant programming experience. The two can appear to work the same,
 but there are important differences. If you would have used Matlab's &
-or \| operators, you should use the Numpy ufuncs
+or \| operators, you should use the NumPy ufuncs
 logical\_and/logical\_or. The notable differences between Matlab's and
-Numpy's & and \| operators are:
+NumPy's & and \| operators are:
 
--  Non-logical {0,1} inputs: Numpy's output is the bitwise AND of the
+-  Non-logical {0,1} inputs: NumPy's output is the bitwise AND of the
    inputs. Matlab treats any non-zero value as 1 and returns the logical
-   AND. For example (3 & 4) in Numpy is 0, while in Matlab both 3 and 4
+   AND. For example (3 & 4) in NumPy is 0, while in Matlab both 3 and 4
    are considered logical true and (3 & 4) returns 1.
 
--  Precedence: Numpy's & operator is higher precedence than logical
+-  Precedence: NumPy's & operator is higher precedence than logical
    operators like < and >; Matlab's is the reverse.
 
 If you know you have boolean arguments, you can get away with using
-Numpy's bitwise operators, but be careful with parentheses, like this: z
-= (x > 1) & (x < 2). The absence of Numpy operator forms of logical\_and
+NumPy's bitwise operators, but be careful with parentheses, like this: z
+= (x > 1) & (x < 2). The absence of NumPy operator forms of logical\_and
 and logical\_or is an unfortunate consequence of Python's design.
 
 **RESHAPE and LINEAR INDEXING**: Matlab always allows multi-dimensional
-arrays to be accessed using scalar or linear indices, Numpy does not.
+arrays to be accessed using scalar or linear indices, NumPy does not.
 Linear indices are common in Matlab programs, e.g. find() on a matrix
-returns them, whereas Numpy's find behaves differently. When converting
+returns them, whereas NumPy's find behaves differently. When converting
 Matlab code it might be necessary to first reshape a matrix to a linear
 sequence, perform some indexing operations and then reshape back. As
 reshape (usually) produces views onto the same storage, it should be
 possible to do this fairly efficiently. Note that the scan order used by
-reshape in Numpy defaults to the 'C' order, whereas Matlab uses the
+reshape in NumPy defaults to the 'C' order, whereas Matlab uses the
 Fortran order. If you are simply converting to a linear sequence and
 back this doesn't matter. But if you are converting reshapes from Matlab
 code which relies on the scan order, then this Matlab code: z =
 reshape(x,3,4); should become z = x.reshape(3,4,order='F').copy() in
-Numpy.
+NumPy.
 
 Customizing Your Environment
 ============================
diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst
index 034ac223a..5ab8cdad7 100644
--- a/doc/source/user/quickstart.rst
+++ b/doc/source/user/quickstart.rst
@@ -25,7 +25,7 @@ The Basics
 
 NumPy's main object is the homogeneous multidimensional array. It is a
 table of elements (usually numbers), all of the same type, indexed by a
-tuple of positive integers. In Numpy dimensions are called *axes*. The
+tuple of positive integers. In NumPy dimensions are called *axes*. The
 number of axes is *rank*.
 
 For example, the coordinates of a point in 3D space ``[1, 2, 1]`` is an
@@ -39,7 +39,7 @@ length of 3.
     [[ 1., 0., 0.],
      [ 0., 1., 2.]]
 
-Numpy's array class is called ``ndarray``. It is also known by the alias
+NumPy's array class is called ``ndarray``. It is also known by the alias
 ``array``. Note that ``numpy.array`` is not the same as the Standard
 Python Library class ``array.array``, which only handles one-dimensional
 arrays and offers less functionality. The more important attributes of
@@ -612,7 +612,7 @@ The shape of an array can be changed with various commands:
 The order of the elements in the array resulting from ravel() is
 normally "C-style", that is, the rightmost index "changes the fastest",
 so the element after a[0,0] is a[0,1]. If the array is reshaped to some
-other shape, again the array is treated as "C-style". Numpy normally
+other shape, again the array is treated as "C-style". NumPy normally
 creates arrays stored in this order, so ravel() will usually not need to
 copy its argument, but if the array was made by taking slices of another
 array or created with unusual options, it may need to be copied. The
diff --git a/doc/summarize.py b/doc/summarize.py
index 833436cee..dbadb30b3 100755
--- a/doc/summarize.py
+++ b/doc/summarize.py
@@ -2,7 +2,7 @@
 """
 summarize.py
 
-Show a summary about which Numpy functions are documented and which are not.
+Show a summary about which NumPy functions are documented and which are not.
 
 """
 from __future__ import division, absolute_import, print_function
@@ -114,7 +114,7 @@ def check_numpy():
 
 def get_undocumented(documented, module, module_name=None, skip=[]):
     """
-    Find out which items in Numpy are not documented.
+    Find out which items in NumPy are not documented.
 
     Returns
     -------