DOC: standardize capitalization of NEP headings (numpy#25060)

More toward numpygh-16261.

numpygh-16261 reported that documentation headings currently have inconsistent capitalization schemes and should be standardized. numpygh-25016 fixed this for rst files except release notes and NEPS. This PR adjusts the NEPs.

The case of 'numpy', 'blas', 'scipy', 'python', 'lapack', 'fortran', 'api', 'pypi', 'cpu', 'abi', 'pr', 'github', 'ssh', 'git', 'f77', 'numba', 'f2py', 'cffi', 'bitgenerator', 'simd', 'swig', 'csv', 'ascii', 'json', 'dataframe', 'ieee', 'matlab', 'pyfort', ' c ', and 'nep' are unchanged. (Perhaps it would be a good idea to check the capitalization of some of these words throughout the documentation, but that is a different issue.)

doc/neps/nep-0000.rst

@@ -54,7 +54,7 @@ There are three kinds of NEPs:
    Any meta-NEP is also considered a Process NEP.
 
 
-NEP Workflow
+NEP workflow
 ------------
 
 The NEP process begins with a new idea for NumPy.  It is highly
@@ -97,7 +97,7 @@ to be made available as PR to the NumPy repo (making sure to appropriately
 mark the PR as a WIP).
 
 
-Review and Resolution
+Review and resolution
 ^^^^^^^^^^^^^^^^^^^^^
 
 NEPs are discussed on the mailing list.  The possible paths of the
@@ -152,7 +152,7 @@ Process NEPs may also have a status of ``Active`` if they are never
 meant to be completed, e.g. NEP 0 (this NEP).
 
 
-How a NEP becomes Accepted
+How a NEP becomes accepted
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A NEP is ``Accepted`` by consensus of all interested contributors. We
@@ -220,7 +220,7 @@ to development practices and other details. The precise process followed in
 these cases will depend on the nature and purpose of the NEP being updated.
 
 
-Format and Template
+Format and template
 -------------------
 
 NEPs are UTF-8 encoded text files using the reStructuredText_ format.  Please
@@ -273,7 +273,7 @@ Discussion
 - https://mail.python.org/pipermail/numpy-discussion/2017-December/077481.html
 
 
-References and Footnotes
+References and footnotes
 ------------------------
 
 .. [1] This historical record is available by the normal git commands

doc/neps/nep-0001-npy-format.rst

@@ -53,7 +53,7 @@ more complicated problems for which more complicated formats like
 HDF5 [2] are a better solution.
 
 
-Use Cases
+Use cases
 ---------
 
 - Neville Newbie has just started to pick up Python and NumPy.  He
@@ -152,7 +152,7 @@ The format explicitly *does not* need to:
   general NPY format.
 
 
-Format Specification: Version 1.0
+Format specification: version 1.0
 ---------------------------------
 
 The first 6 bytes are a magic string: exactly "\x93NUMPY".
@@ -200,7 +200,7 @@ bytes of the array.  Consumers can figure out the number of bytes
 by multiplying the number of elements given by the shape (noting
 that shape=() means there is 1 element) by dtype.itemsize.
 
-Format Specification: Version 2.0
+Format specification: version 2.0
 ---------------------------------
 
 The version 1.0 format only allowed the array header to have a

doc/neps/nep-0002-warnfix.rst

@@ -44,7 +44,7 @@ the compilers do not generate warnings in those cases; the tag process has to
 be clean, readable, and be robust. In particular, it should not make the code
 more obscure or worse, break working code.
 
-unused parameter
+Unused parameter
 ----------------
 
 This one appears often: any python-callable C function takes two arguments,
@@ -78,12 +78,12 @@ expanded to::
 Thus avoiding any accidental use of the variable. The mangling is pure C, and
 thus portable. The per-variable warning disabling is compiler specific.
 
-signed/unsigned comparison
+Signed/unsigned comparison
 --------------------------
 
 More tricky: not always clear what to do
 
-half-initialized structures
+Half-initialized structures
 ---------------------------
 
 Just put the elements with NULL in it.

doc/neps/nep-0005-generalized-ufuncs.rst

@@ -1,7 +1,7 @@
 .. _NEP05:
 
 =======================================
-NEP 5 — Generalized Universal Functions
+NEP 5 — Generalized universal functions
 =======================================
 
 :Status: Final
@@ -86,7 +86,7 @@ Dimension Index
     occurrence of each name in the signature.
 
 
-Details of Signature
+Details of signature
 --------------------
 
 The signature defines "core" dimensionality of input and output
@@ -141,7 +141,7 @@ Here are some examples of signatures:
 |             |                        | and loop/broadcast over the rest. |
 +-------------+------------------------+-----------------------------------+
 
-C-API for implementing Elementary Functions
+C-API for implementing elementary functions
 -------------------------------------------
 
 The current interface remains unchanged, and ``PyUFunc_FromFuncAndData``

doc/neps/nep-0006-newbugtracker.rst

@@ -15,7 +15,7 @@ current trac limitations, and what can be done about it.
 Scenario
 ========
 
-new release
+New release
 -----------
 
 The workflow for a release is roughly as follows:
@@ -47,7 +47,7 @@ better than the actually deployed version on scipy website. Finding issues with
 patches, old patches, etc... and making reports has to be much more streamlined
 that it is now.
 
-subcomponent maintainer
+Subcomponent maintainer
 -----------------------
 
 Say you are the maintainer of scipy.foo, then you are mostly interested in

doc/neps/nep-0007-datetime-proposal.rst

@@ -600,7 +600,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 Interface Extensions
+Array interface extensions
 --------------------------
 
 The array interface is extended to both handle datetime and timedelta

doc/neps/nep-0008-groupby_additions.rst

@@ -1,8 +1,8 @@
 .. _NEP08:
 
-=============================================================
-NEP 8 —  A proposal for adding groupby functionality to NumPy
-=============================================================
+============================================================
+NEP 8 — A proposal for adding groupby functionality to NumPy
+============================================================
 
 :Author: Travis Oliphant
 :Contact: [email protected]
@@ -21,7 +21,7 @@ describes two additional methods for ufuncs (reduceby and reducein) and
 two additional functions (segment and edges) which can help add this
 functionality.
 
-Example Use Case
+Example use case
 ================
 Suppose you have a NumPy structured array containing information about
 the number of purchases at several stores over multiple days.  To be clear, the

doc/neps/nep-0010-new-iterator-ufunc.rst

@@ -1,7 +1,7 @@
 .. _NEP10:
 
 ==============================================
-NEP 10 — Optimizing Iterator/UFunc performance
+NEP 10 — Optimizing iterator/UFunc performance
 ==============================================
 
 :Author: Mark Wiebe <[email protected]>
@@ -75,7 +75,7 @@ a view of the memory, adding, then reshaping back.  To further examine
 the problem and see how it isn’t always as trivial to work around,
 let’s consider simple code for working with image buffers in NumPy.
 
-Image Compositing Example
+Image compositing example
 =========================
 
 For a more realistic example, consider an image buffer.  Images are
@@ -164,7 +164,7 @@ proposed can produce, go to the example continued after the
 proposed API, near the bottom of the document.
 
 *************************
-Improving Cache-Coherency
+Improving cache-coherency
 *************************
 
 In order to get the best performance from UFunc calls, the pattern of
@@ -241,7 +241,7 @@ by adding an additional constraint.  I think the appropriate choice
 is to resolve it by picking the memory layout closest to C-contiguous,
 but still compatible with the input strides.
 
-Output Layout Selection Algorithm
+Output layout selection algorithm
 =================================
 
 The output ndarray memory layout we would like to produce is as follows:
@@ -296,7 +296,7 @@ output layout.::
     return perm
 
 *********************
-Coalescing Dimensions
+Coalescing dimensions
 *********************
 
 In many cases, the memory layout allows for the use of a one-dimensional
@@ -334,7 +334,7 @@ Here is pseudo-code for coalescing.::
                 j += 1
 
 *************************
-Inner Loop Specialization
+Inner loop specialization
 *************************
 
 Specialization is handled purely by the inner loop function, so this
@@ -371,7 +371,7 @@ constant argument may be combined with SSE when the strides match the
 data type size, and reductions can be optimized with SSE as well.
 
 **********************
-Implementation Details
+Implementation details
 **********************
 
 Except for inner loop specialization, the discussed
@@ -436,7 +436,7 @@ could adopt this enum as its preferred way of dealing with casting.
             NPY_UNSAFE_CASTING=4
     } NPY_CASTING;
 
-Iterator Rewrite
+Iterator rewrite
 ================
 
 Based on an analysis of the code, it appears that refactoring the existing
@@ -495,7 +495,7 @@ Notes for implementation:
   a wrapper around the C iterator.  This is analogous to the
   PEP 3118 design separation of Py_buffer and memoryview.
 
-Proposed Iterator Memory Layout
+Proposed iterator memory layout
 ===============================
 
 The following struct describes the iterator memory.  All items
@@ -596,7 +596,7 @@ common properties are, resulting in increased cache coherency.
 It also simplifies the iternext call, while making getcoord and
 related functions slightly more complicated.
 
-Proposed Iterator API
+Proposed iterator API
 =====================
 
 The existing iterator API includes functions like PyArrayIter_Check,
@@ -631,7 +631,7 @@ to emulate UFunc behavior in cases which don't quite fit the
 UFunc paradigm.  In particular, emulating the UFunc buffering behavior
 is not a trivial enterprise.
 
-Old -> New Iterator API Conversion
+Old -> new iterator API conversion
 ----------------------------------
 
 For the regular iterator:
@@ -672,7 +672,7 @@ For other API calls:
 ===============================  =============================================
 
 
-Iterator Pointer Type
+Iterator pointer type
 ---------------------
 
 The iterator structure is internally generated, but a type is still needed
@@ -682,7 +682,7 @@ the API.  We do this with a typedef of an incomplete struct
 ``typedef struct NpyIter_InternalOnly NpyIter;``
 
 
-Construction and Destruction
+Construction and destruction
 ----------------------------
 
 ``NpyIter* NpyIter_New(PyArrayObject* op, npy_uint32 flags, NPY_ORDER order, NPY_CASTING casting, PyArray_Descr* dtype, npy_intp a_ndim, npy_intp *axes, npy_intp buffersize)``
@@ -1415,7 +1415,7 @@ Construction and Destruction
     Fills ``niter`` flags. Sets ``outwriteflags[i]`` to 1 if
     ``op[i]`` can be written to, and to 0 if not.
 
-Functions For Iteration
+Functions for iteration
 -----------------------
 
 ``NpyIter_IterNext_Fn NpyIter_GetIterNext(NpyIter *iter, char **errmsg)``
@@ -1680,7 +1680,7 @@ references, and add ``NPY_ITER_WRITEABLE_REFERENCES`` to the flags:
         return ret;
     }
 
-Python Lambda UFunc Example
+Python lambda UFunc example
 ---------------------------
 
 To show how the new iterator allows the definition of efficient UFunc-like
@@ -1733,7 +1733,7 @@ can gain some performance from better cache behavior.::
     Out[7]: True
 
 
-Python Addition Example
+Python addition example
 -----------------------
 
 The iterator has been mostly written and exposed to Python.  To
@@ -1897,7 +1897,7 @@ Also, just to check that it's doing the same thing,::
 
     Out[22]: True
 
-Image Compositing Example Revisited
+Image compositing example revisited
 -----------------------------------
 
 For motivation, we had an example that did an 'over' composite operation
@@ -1983,7 +1983,7 @@ functions.::
         ...:        composite_over_it(image1, image2))
     Out[18]: True
 
-Image Compositing With NumExpr
+Image compositing with NumExpr
 ------------------------------
 
 As a test of the iterator, numexpr has been enhanced to allow use of

doc/neps/nep-0011-deferred-ufunc-evaluation.rst

@@ -73,7 +73,7 @@ UFunc to evaluate on the fly.
 
 
 *******************
-Example Python Code
+Example Python code
 *******************
 
 Here's how it might be used in NumPy.::
@@ -138,7 +138,7 @@ divide by zero error?" can hopefully be avoided by recommending
 this approach.
 
 ********************************
-Proposed Deferred Evaluation API
+Proposed deferred evaluation API
 ********************************
 
 For deferred evaluation to work, the C API needs to be aware of its
@@ -216,7 +216,7 @@ The Python API would be expanded as follows.
     ``numpy.errstate``.
 
 
-Error Handling
+Error handling
 ==============
 
 Error handling is a thorny issue for deferred evaluation.  If the
@@ -232,7 +232,7 @@ only when the error state is set to ignore all, but allow user control with
 use deferred evaluation, False would mean never use it, and None would
 mean use it only when safe (i.e. the error state is set to ignore all).
 
-Interaction With UPDATEIFCOPY
+Interaction with UPDATEIFCOPY
 =============================
 
 The ``NPY_UPDATEIFCOPY`` documentation states:
@@ -272,7 +272,7 @@ To deal with this issue, we make these two states mutually exclusive.
   future.  If the deferred evaluation mechanism sees this flag in
   any operand, it triggers immediate evaluation.
 
-Other Implementation Details
+Other implementation details
 ============================
 
 When a deferred array is created, it gets references to all the
@@ -288,7 +288,7 @@ This may release references to other deferred arrays contained
 in the deferred expression tree, which then
 never have to be calculated.
 
-Further Optimization
+Further optimization
 ====================
 
 Instead of conservatively disabling deferred evaluation when any