summaryrefslogtreecommitdiff
path: root/doc/source
diff options
context:
space:
mode:
Diffstat (limited to 'doc/source')
-rw-r--r--doc/source/dev/development_environment.rst4
-rw-r--r--doc/source/reference/alignment.rst2
-rw-r--r--doc/source/reference/arrays.datetime.rst6
-rw-r--r--doc/source/reference/random/index.rst84
-rw-r--r--doc/source/reference/random/legacy.rst68
-rw-r--r--doc/source/reference/ufuncs.rst6
-rw-r--r--doc/source/release/1.11.0-notes.rst4
-rw-r--r--doc/source/release/1.16.0-notes.rst2
-rw-r--r--doc/source/release/1.16.1-notes.rst2
-rw-r--r--doc/source/release/1.18.0-notes.rst2
-rw-r--r--doc/source/user/basics.io.genfromtxt.rst20
11 files changed, 134 insertions, 66 deletions
diff --git a/doc/source/dev/development_environment.rst b/doc/source/dev/development_environment.rst
index 297502b31..874d277d8 100644
--- a/doc/source/dev/development_environment.rst
+++ b/doc/source/dev/development_environment.rst
@@ -53,7 +53,7 @@ When using pytest as a target (the default), you can
.. note::
- Remember that all tests of NumPy should pass before commiting your changes.
+ Remember that all tests of NumPy should pass before committing your changes.
Using ``runtests.py`` is the recommended approach to running tests.
There are also a number of alternatives to it, for example in-place
@@ -145,7 +145,7 @@ Running tests
Besides using ``runtests.py``, there are various ways to run the tests. Inside
the interpreter, tests can be run like this::
- >>> np.test()
+ >>> np.test() # doctest: +SKIPBLOCK
>>> np.test('full') # Also run tests marked as slow
>>> np.test('full', verbose=2) # Additionally print test name/file
diff --git a/doc/source/reference/alignment.rst b/doc/source/reference/alignment.rst
index ebc8f353c..5e4315b38 100644
--- a/doc/source/reference/alignment.rst
+++ b/doc/source/reference/alignment.rst
@@ -67,7 +67,7 @@ There are 4 relevant uses of the word ``align`` used in numpy:
field alignment. In either case ``dtype.isalignedstruct`` is also set to
True.
* ``IsUintAligned`` is used to determine if an ndarray is "uint aligned" in
- an analagous way to how ``IsAligned`` checks for true-alignment.
+ an analogous way to how ``IsAligned`` checks for true-alignment.
Consequences of alignment
-------------------------
diff --git a/doc/source/reference/arrays.datetime.rst b/doc/source/reference/arrays.datetime.rst
index 2225eedb3..9c45e04c7 100644
--- a/doc/source/reference/arrays.datetime.rst
+++ b/doc/source/reference/arrays.datetime.rst
@@ -368,7 +368,7 @@ times in UTC. By default, creating a datetime64 object from a string or
printing it would convert from or to local time::
# old behavior
- >>>> np.datetime64('2000-01-01T00:00:00')
+ >>> np.datetime64('2000-01-01T00:00:00')
numpy.datetime64('2000-01-01T00:00:00-0800') # note the timezone offset -08:00
A consensus of datetime64 users agreed that this behavior is undesirable
@@ -378,7 +378,7 @@ most use cases, a timezone naive datetime type is preferred, similar to the
datetime64 no longer assumes that input is in local time, nor does it print
local times::
- >>>> np.datetime64('2000-01-01T00:00:00')
+ >>> np.datetime64('2000-01-01T00:00:00')
numpy.datetime64('2000-01-01T00:00:00')
For backwards compatibility, datetime64 still parses timezone offsets, which
@@ -393,4 +393,4 @@ As a corollary to this change, we no longer prohibit casting between datetimes
with date units and datetimes with timeunits. With timezone naive datetimes,
the rule for casting from dates to times is no longer ambiguous.
-.. _pandas: http://pandas.pydata.org \ No newline at end of file
+.. _pandas: http://pandas.pydata.org
diff --git a/doc/source/reference/random/index.rst b/doc/source/reference/random/index.rst
index d28646df9..bda9c4d96 100644
--- a/doc/source/reference/random/index.rst
+++ b/doc/source/reference/random/index.rst
@@ -22,34 +22,44 @@ Since Numpy version 1.17.0 the Generator can be initialized with a
number of different BitGenerators. It exposes many different probability
distributions. See `NEP 19 <https://www.numpy.org/neps/
nep-0019-rng-policy.html>`_ for context on the updated random Numpy number
-routines. The legacy `.RandomState` random number routines are still
+routines. The legacy `RandomState` random number routines are still
available, but limited to a single BitGenerator.
-For convenience and backward compatibility, a single `~.RandomState`
+For convenience and backward compatibility, a single `RandomState`
instance's methods are imported into the numpy.random namespace, see
:ref:`legacy` for the complete list.
+.. _random-quick-start:
+
Quick Start
-----------
-By default, `~Generator` uses bits provided by `PCG64` which
-has better statistical properties than the legacy mt19937 random
-number generator in `~.RandomState`.
+Call `default_rng` to get a new instance of a `Generator`, then call its
+methods to obtain samples from different distributions. By default,
+`Generator` uses bits provided by `PCG64` which has better statistical
+properties than the legacy `MT19937` used in `RandomState`.
.. code-block:: python
- # Uses the old numpy.random.RandomState
+ # Do this
+ from numpy.random import default_rng
+ rng = default_rng()
+ vals = rng.standard_normal(10)
+ more_vals = rng.standard_normal(10)
+
+ # instead of this
from numpy import random
- random.standard_normal()
+ vals = random.standard_normal(10)
+ more_vals = random.standard_normal(10)
-`~Generator` can be used as a replacement for `~.RandomState`. Both class
-instances now hold a internal `BitGenerator` instance to provide the bit
+`Generator` can be used as a replacement for `RandomState`. Both class
+instances hold a internal `BitGenerator` instance to provide the bit
stream, it is accessible as ``gen.bit_generator``. Some long-overdue API
cleanup means that legacy and compatibility methods have been removed from
-`~.Generator`
+`Generator`
=================== ============== ============
-`~.RandomState` `~.Generator` Notes
+`RandomState` `Generator` Notes
------------------- -------------- ------------
``random_sample``, ``random`` Compatible with `random.random`
``rand``
@@ -58,21 +68,12 @@ cleanup means that legacy and compatibility methods have been removed from
``random_integers``
------------------- -------------- ------------
``tomaxint`` removed Use ``integers(0, np.iinfo(np.int_).max,``
- ``endpoint=False)``
+ ``endpoint=False)``
------------------- -------------- ------------
-``seed`` removed Use `~.SeedSequence.spawn`
+``seed`` removed Use `SeedSequence.spawn`
=================== ============== ============
-See `new-or-different` for more information
-
-.. code-block:: python
-
- # As replacement for RandomState(); default_rng() instantiates Generator with
- # the default PCG64 BitGenerator.
- from numpy.random import default_rng
- rg = default_rng()
- rg.standard_normal()
- rg.bit_generator
+See :ref:`new-or-different` for more information
Something like the following code can be used to support both ``RandomState``
and ``Generator``, with the understanding that the interfaces are slightly
@@ -87,9 +88,9 @@ different
a = rg_integers(1000)
Seeds can be passed to any of the BitGenerators. The provided value is mixed
-via `~.SeedSequence` to spread a possible sequence of seeds across a wider
-range of initialization states for the BitGenerator. Here `~.PCG64` is used and
-is wrapped with a `~.Generator`.
+via `SeedSequence` to spread a possible sequence of seeds across a wider
+range of initialization states for the BitGenerator. Here `PCG64` is used and
+is wrapped with a `Generator`.
.. code-block:: python
@@ -100,7 +101,7 @@ is wrapped with a `~.Generator`.
Introduction
------------
The new infrastructure takes a different approach to producing random numbers
-from the `~.RandomState` object. Random number generation is separated into
+from the `RandomState` object. Random number generation is separated into
two components, a bit generator and a random generator.
The `BitGenerator` has a limited set of responsibilities. It manages state
@@ -113,8 +114,8 @@ distributions, e.g., simulated normal random values. This structure allows
alternative bit generators to be used with little code duplication.
The `Generator` is the user-facing object that is nearly identical to
-`.RandomState`. The canonical method to initialize a generator passes a
-`~.PCG64` bit generator as the sole argument.
+`RandomState`. The canonical method to initialize a generator passes a
+`PCG64` bit generator as the sole argument.
.. code-block:: python
@@ -139,9 +140,9 @@ What's New or Different
The Box-Muller method used to produce NumPy's normals is no longer available
in `Generator`. It is not possible to reproduce the exact random
values using Generator for the normal distribution or any other
- distribution that relies on the normal such as the `.RandomState.gamma` or
- `.RandomState.standard_t`. If you require bitwise backward compatible
- streams, use `.RandomState`.
+ distribution that relies on the normal such as the `RandomState.gamma` or
+ `RandomState.standard_t`. If you require bitwise backward compatible
+ streams, use `RandomState`.
* The Generator's normal, exponential and gamma functions use 256-step Ziggurat
methods which are 2-10 times faster than NumPy's Box-Muller or inverse CDF
@@ -152,20 +153,20 @@ What's New or Different
* Optional ``out`` argument that allows existing arrays to be filled for
select distributions
* All BitGenerators can produce doubles, uint64s and uint32s via CTypes
- (`~.PCG64.ctypes`) and CFFI (`~.PCG64.cffi`). This allows the bit generators
+ (`PCG64.ctypes`) and CFFI (`PCG64.cffi`). This allows the bit generators
to be used in numba.
* The bit generators can be used in downstream projects via
:ref:`Cython <random_cython>`.
-* `~.Generator.integers` is now the canonical way to generate integer
+* `Generator.integers` is now the canonical way to generate integer
random numbers from a discrete uniform distribution. The ``rand`` and
- ``randn`` methods are only available through the legacy `~.RandomState`.
+ ``randn`` methods are only available through the legacy `RandomState`.
The ``endpoint`` keyword can be used to specify open or closed intervals.
This replaces both ``randint`` and the deprecated ``random_integers``.
-* `~.Generator.random` is now the canonical way to generate floating-point
- random numbers, which replaces `.RandomState.random_sample`,
- `.RandomState.sample`, and `.RandomState.ranf`. This is consistent with
+* `Generator.random` is now the canonical way to generate floating-point
+ random numbers, which replaces `RandomState.random_sample`,
+ `RandomState.sample`, and `RandomState.ranf`. This is consistent with
Python's `random.random`.
-* All BitGenerators in numpy use `~SeedSequence` to convert seeds into
+* All BitGenerators in numpy use `SeedSequence` to convert seeds into
initialized states.
See :ref:`new-or-different` for a complete list of improvements and
@@ -202,8 +203,9 @@ Features
c-api
Examples of using Numba, Cython, CFFI <extending>
-Original Source
-~~~~~~~~~~~~~~~
+Original Source of the Generator and BitGenerators
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This package was developed independently of NumPy and was integrated in version
1.17.0. The original repo is at https://github.com/bashtage/randomgen.
+
diff --git a/doc/source/reference/random/legacy.rst b/doc/source/reference/random/legacy.rst
index 413a42727..922d76a9a 100644
--- a/doc/source/reference/random/legacy.rst
+++ b/doc/source/reference/random/legacy.rst
@@ -121,3 +121,71 @@ Distributions
~RandomState.wald
~RandomState.weibull
~RandomState.zipf
+
+Functions in `numpy.random`
+===========================
+Many of the RandomState methods above are exported as functions in
+`numpy.random` This usage is discouraged, as it is implemented via a gloabl
+`RandomState` instance which is not advised on two counts:
+
+- It uses global state, which means results will change as the code changes
+
+- It uses a `RandomState` rather than the more modern `Generator`.
+
+For backward compatible legacy reasons, we cannot change this. See
+`random-quick-start`.
+
+.. autosummary::
+ :toctree: generated/
+
+ beta
+ binomial
+ bytes
+ chisquare
+ choice
+ dirichlet
+ exponential
+ f
+ gamma
+ geometric
+ get_state
+ gumbel
+ hypergeometric
+ laplace
+ logistic
+ lognormal
+ logseries
+ multinomial
+ multivariate_normal
+ negative_binomial
+ noncentral_chisquare
+ noncentral_f
+ normal
+ pareto
+ permutation
+ poisson
+ power
+ rand
+ randint
+ randn
+ random
+ random_integers
+ random_sample
+ ranf
+ rayleigh
+ sample
+ seed
+ set_state
+ shuffle
+ standard_cauchy
+ standard_exponential
+ standard_gamma
+ standard_normal
+ standard_t
+ triangular
+ uniform
+ vonmises
+ wald
+ weibull
+ zipf
+
diff --git a/doc/source/reference/ufuncs.rst b/doc/source/reference/ufuncs.rst
index 0416d6efc..361cf11b9 100644
--- a/doc/source/reference/ufuncs.rst
+++ b/doc/source/reference/ufuncs.rst
@@ -253,9 +253,9 @@ can generate this table for your system with the code given in the Figure.
B - - Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y - Y
H - - - Y Y Y Y - Y Y Y Y Y - Y Y Y Y Y Y Y Y Y Y - Y
I - - - - Y Y Y - - Y Y Y Y - - Y Y - Y Y Y Y Y Y - Y
- L - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - Y
- Q - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - Y
- P - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - Y
+ L - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - -
+ Q - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - -
+ P - - - - - - - - - - Y Y Y - - Y Y - Y Y Y Y Y Y - -
e - - - - - - - - - - - - - Y Y Y Y Y Y Y Y Y Y Y - -
f - - - - - - - - - - - - - - Y Y Y Y Y Y Y Y Y Y - -
d - - - - - - - - - - - - - - - Y Y - Y Y Y Y Y Y - -
diff --git a/doc/source/release/1.11.0-notes.rst b/doc/source/release/1.11.0-notes.rst
index 1a179657b..36cd1d65a 100644
--- a/doc/source/release/1.11.0-notes.rst
+++ b/doc/source/release/1.11.0-notes.rst
@@ -85,7 +85,7 @@ times in UTC. By default, creating a datetime64 object from a string or
printing it would convert from or to local time::
# old behavior
- >>>> np.datetime64('2000-01-01T00:00:00')
+ >>> np.datetime64('2000-01-01T00:00:00')
numpy.datetime64('2000-01-01T00:00:00-0800') # note the timezone offset -08:00
@@ -96,7 +96,7 @@ type is preferred, similar to the ``datetime.datetime`` type in the Python
standard library. Accordingly, datetime64 no longer assumes that input is in
local time, nor does it print local times::
- >>>> np.datetime64('2000-01-01T00:00:00')
+ >>> np.datetime64('2000-01-01T00:00:00')
numpy.datetime64('2000-01-01T00:00:00')
For backwards compatibility, datetime64 still parses timezone offsets, which
diff --git a/doc/source/release/1.16.0-notes.rst b/doc/source/release/1.16.0-notes.rst
index 1034d6e6c..e78e270f4 100644
--- a/doc/source/release/1.16.0-notes.rst
+++ b/doc/source/release/1.16.0-notes.rst
@@ -506,7 +506,7 @@ become more conspicuous. Now no warnings will be emitted.
Umath and multiarray c-extension modules merged into a single module
--------------------------------------------------------------------
The two modules were merged, according to `NEP 15`_. Previously `np.core.umath`
-and `np.core.multiarray` were seperate c-extension modules. They are now python
+and `np.core.multiarray` were separate c-extension modules. They are now python
wrappers to the single `np.core/_multiarray_math` c-extension module.
.. _`NEP 15` : http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html
diff --git a/doc/source/release/1.16.1-notes.rst b/doc/source/release/1.16.1-notes.rst
index 2a190ef91..d6fc25b44 100644
--- a/doc/source/release/1.16.1-notes.rst
+++ b/doc/source/release/1.16.1-notes.rst
@@ -58,7 +58,7 @@ Enhancements
Compatibility notes
===================
-* The changed error message emited by array comparison testing functions may
+* The changed error message emitted by array comparison testing functions may
affect doctests. See below for detail.
* Casting from double and single denormals to float16 has been corrected. In
diff --git a/doc/source/release/1.18.0-notes.rst b/doc/source/release/1.18.0-notes.rst
index e66540410..60e11da4a 100644
--- a/doc/source/release/1.18.0-notes.rst
+++ b/doc/source/release/1.18.0-notes.rst
@@ -1,4 +1,4 @@
-The NumPy 1.18 release is currently in developement. Please check
+The NumPy 1.18 release is currently in development. Please check
the ``numpy/doc/release/upcoming_changes/`` folder for upcoming
release notes.
The ``numpy/doc/release/upcoming_changes/README.txt`` details how
diff --git a/doc/source/user/basics.io.genfromtxt.rst b/doc/source/user/basics.io.genfromtxt.rst
index 19e37eabc..3fce6a8aa 100644
--- a/doc/source/user/basics.io.genfromtxt.rst
+++ b/doc/source/user/basics.io.genfromtxt.rst
@@ -98,13 +98,11 @@ This behavior can be overwritten by setting the optional argument
>>> # Without autostrip
>>> np.genfromtxt(StringIO(data), delimiter=",", dtype="|U5")
array([['1', ' abc ', ' 2'],
- ['3', ' xxx', ' 4']],
- dtype='|U5')
+ ['3', ' xxx', ' 4']], dtype='<U5')
>>> # With autostrip
>>> np.genfromtxt(StringIO(data), delimiter=",", dtype="|U5", autostrip=True)
array([['1', 'abc', '2'],
- ['3', 'xxx', '4']],
- dtype='|U5')
+ ['3', 'xxx', '4']], dtype='<U5')
The ``comments`` argument
@@ -127,11 +125,11 @@ marker(s) is simply ignored::
... 9, 0
... """
>>> np.genfromtxt(StringIO(data), comments="#", delimiter=",")
- [[ 1. 2.]
- [ 3. 4.]
- [ 5. 6.]
- [ 7. 8.]
- [ 9. 0.]]
+ array([[1., 2.],
+ [3., 4.],
+ [5., 6.],
+ [7., 8.],
+ [9., 0.]])
.. versionadded:: 1.7.0
@@ -376,12 +374,12 @@ single element of the wanted type.
In the following example, the second column is converted from as string
representing a percentage to a float between 0 and 1::
- >>> convertfunc = lambda x: float(x.strip("%"))/100.
+ >>> convertfunc = lambda x: float(x.strip(b"%"))/100.
>>> data = u"1, 2.3%, 45.\n6, 78.9%, 0"
>>> names = ("i", "p", "n")
>>> # General case .....
>>> np.genfromtxt(StringIO(data), delimiter=",", names=names)
- array([(1.0, nan, 45.0), (6.0, nan, 0.0)],
+ array([(1., nan, 45.), (6., nan, 0.)],
dtype=[('i', '<f8'), ('p', '<f8'), ('n', '<f8')])
We need to keep in mind that by default, ``dtype=float``. A float is