numpy · jaimefrio · Sep 7, 2016 · Sep 5, 2016 · Sep 6, 2016 · Sep 6, 2016
diff --git a/INSTALL.rst.txt b/INSTALL.rst.txt
@@ -1,8 +1,8 @@
 Building and installing NumPy
 +++++++++++++++++++++++++++++
 
-**IMPORTANT**: the below notes are about building Numpy, which for most users
-is *not* the recommended way to install Numpy.  Instead, use either a complete
+**IMPORTANT**: the below notes are about building NumPy, which for most users
+is *not* the recommended way to install NumPy.  Instead, use either a complete
 scientific Python distribution (recommended) or a binary installer - see
 http://scipy.org/install.html.
 
@@ -39,13 +39,13 @@ nose__ http://somethingaboutorange.com/mrl/projects/nose/
 
 .. note:: 
 
-   If you want to build Numpy in order to work on Numpy itself, use
+   If you want to build NumPy in order to work on NumPy itself, use
    ``runtests.py``.  For more details, see
    http://docs.scipy.org/doc/numpy-dev/dev/development_environment.html
 
 .. note::
 
-   More extensive information on building Numpy (and Scipy) is maintained at
+   More extensive information on building NumPy (and Scipy) is maintained at
    http://scipy.org/scipylib/building/index.html
 
 
@@ -68,8 +68,8 @@ NPY_NUM_BUILD_JOBS.
 Choosing compilers
 ==================
 
-Numpy needs a C compiler, and for development versions also Cython.  A Fortran
-compiler isn't needed to build Numpy itself; the ``numpy.f2py`` tests will be
+NumPy needs a C compiler, and for development versions also Cython.  A Fortran
+compiler isn't needed to build NumPy itself; the ``numpy.f2py`` tests will be
 skipped when running the test suite if no Fortran compiler is available.  For
 building Scipy a Fortran compiler is needed though, so we include some details
 on Fortran compilers in the rest of this section.
@@ -91,7 +91,7 @@ good `application note <https://software.intel.com/en-us/articles/numpyscipy-wit
 on this.
 
 If you want to use a free compiler toolchain, the recommended compiler is MingwPy__.
-The older MinGW32 compiler set used to produce older .exe installers for Numpy
+The older MinGW32 compiler set used to produce older .exe installers for NumPy
 itself is still available at https://github.com/numpy/numpy-vendor, but not
 recommended for use anymore.
 
@@ -103,7 +103,7 @@ Building with optimized BLAS support
 
 Configuring which BLAS/LAPACK is used if you have multiple libraries installed,
 or you have only one installed but in a non-standard location, is done via a
-``site.cfg`` file.  See the ``site.cfg.example`` shipped with Numpy for more
+``site.cfg`` file.  See the ``site.cfg.example`` shipped with NumPy for more
 details.
 
 Windows
@@ -117,7 +117,7 @@ For an overview of the state of BLAS/LAPACK libraries on Windows, see
 OS X
 ----
 
-OS X ships the Accelerate framework, which Numpy can build against without any
+OS X ships the Accelerate framework, which NumPy can build against without any
 manual configuration.  Other BLAS/LAPACK implementations (OpenBLAS, Intel MKL,
 ATLAS) will also work.
 
@@ -149,7 +149,7 @@ Or by preloading a specific BLAS library with::
 Build issues
 ============
 
-If you run into build issues and need help, the Numpy
+If you run into build issues and need help, the NumPy
 `mailing list <http://scipy.org/scipylib/mailing-lists.html>`_ is the best
-place to ask.  If the issue is clearly a bug in Numpy, please file an issue (or
+place to ask.  If the issue is clearly a bug in NumPy, please file an issue (or
 even better, a pull request) at https://github.com/numpy/numpy.
diff --git a/benchmarks/README.rst b/benchmarks/README.rst
@@ -4,19 +4,19 @@
 NumPy benchmarks
 ================
 
-Benchmarking Numpy with Airspeed Velocity.
+Benchmarking NumPy with Airspeed Velocity.
 
 
 Usage
 -----
 
 Airspeed Velocity manages building and Python virtualenvs by itself,
 unless told otherwise. Some of the benchmarking features in
-``runtests.py`` also tell ASV to use the Numpy compiled by
+``runtests.py`` also tell ASV to use the NumPy compiled by
 ``runtests.py``. To run the benchmarks, you do not need to install a
-development version of Numpy to your current Python environment.
+development version of NumPy to your current Python environment.
 
-Run a benchmark against currently checked out Numpy version (don't
+Run a benchmark against currently checked out NumPy version (don't
 record the result)::
 
     python runtests.py --bench bench_core
@@ -46,9 +46,9 @@ See `ASV documentation`_ for basics on how to write benchmarks.
 
 Some things to consider:
 
-- The benchmark suite should be importable with any Numpy version.
+- The benchmark suite should be importable with any NumPy version.
 
-- The benchmark parameters etc. should not depend on which Numpy version
+- The benchmark parameters etc. should not depend on which NumPy version
   is installed.
 
 - Try to keep the runtime of the benchmark reasonable.

diff --git 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
@@ -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
@@ -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.0
+               `ndobj_old` will be removed in NumPy 2.0.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
@@ -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.0 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
@@ -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,25 +627,25 @@ 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.
 
 .. 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
@@ -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
@@ -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
@@ -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
@@ -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