Skip to content

DOC, API: add random.__init__.pxd and document random.* functions #14948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Nov 27, 2019

Conversation

mattip
Copy link
Member

@mattip mattip commented Nov 21, 2019

rework parts of gh-14604:

  • Add a numpy.random.__init__.pxd so from numpy.random cimport ... works in cython
  • Refactor examples and internal cython code to use __init__.pxd
  • Add methods of RandomState that are exposes as functions in numpy.random to top-level documentation, which should allow them to be referenced via the intersphinx index.
  • Add a note and "see also" fragment to each of the top-level functions/ RandomState.methods to guide users to prefer the new Generator API

instance's methods are imported into the numpy.random namespace, see
:ref:`legacy` for the complete list.

.. _random-quick-start:

Quick Start
-----------

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rework the documentation in lines 36-52 to better guide users how to modify existing code to call default_rng

@@ -121,3 +121,63 @@ Distributions
~RandomState.wald
~RandomState.weibull
~RandomState.zipf

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add the legacy functions below so they are linked into the intersphinx index

.. note::
New code should use ``default_rng().random`` (see
`random-quick-start`) instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add this note and the See Also fragment to each of the exposed functions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, short and to the point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per my comment in the random-quick-start, I really don't like the default_rng().whatever() construction. People should not be making a new Generator every line. If it's really important that people have a replacement for the np.random.whatever() calls that fits on one line, make those module-level aliases against a global Generator.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Instantiating a new Generator each time means more reading of /dev/urandom. While we don't pull a lot of data from it, it's still a system call, which is slow, and is going to block other processes trying to read it at the same time. If someone is mechanically replacing np.random.whatever() with np.random.default_rng().whatever(), that could be a lot of calls in tight loops.

  2. I fear that this usage, especially when presented in this context, is going to engrain the idea that default_rng() returns the default Generator instance rather than creating a new one each time since that was the mental model of np.random.whatever().

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on these comments. Perhaps just note the new name of the function when using the default_rng rather than suggesting a specific function call?

Perhaps something along the lines of

New code should use the random method of a default_rng() instance (see random-quick-start for more detail).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is going to engrain the idea that default_rng() returns the default Generator

Perhaps we got the name wrong, and should call this make_default_rng?

At the very least, this sounds like something that needs to be drawn attention to in the docstring of default_rng.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the "Use the *** method of a default_rng() instance ..." text. Any other alternatives?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't there more bit generators in randomgen? If so, that seems worth mentioning. Otherwise, this subsection is probably best moved to THANKS.txt, it doesn't help the user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many more there still.

@@ -121,3 +121,63 @@ Distributions
~RandomState.wald
~RandomState.weibull
~RandomState.zipf

Toplevel `numpy.random` functions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toplevel is kind of an odd word. How about just Functions in numpy.random?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adopting


Toplevel `numpy.random` functions
=================================
Many of the RandomState methods above are exported as top-level `numpy.random`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also remove top-level here. And add a mention that using a Generator instance, as can be obtained from default_rng, should be preferred.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixing

@rgommers rgommers added this to the 1.18.0 release milestone Nov 21, 2019
@rgommers
Copy link
Member

Looks good, just some minor comments.

@eric-wieser eric-wieser changed the title DOC, API: add random.__index__.pxd and document random.* functions DOC, API: add random.__init__.pxd and document random.* functions Nov 21, 2019
# Uses the old numpy.random.RandomState
#Do this
from numpy.random import default_rng
val = default_rng().standard_normal()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not encourage the default_rng().whatever() construction.

Suggested change
val = default_rng().standard_normal()
rng = default_rng()
val = rng.standard_normal()

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adopting

@mattip
Copy link
Member Author

mattip commented Nov 22, 2019

Build failure on PyPy is a unrelated heisenbug

@mattip mattip requested a review from rkern November 25, 2019 17:58
@charris charris merged commit d379088 into numpy:master Nov 27, 2019
@charris
Copy link
Member

charris commented Nov 27, 2019

Thanks Matti. If anyone has further changes they would like to see, make a new PR.

@mattip mattip deleted the document-random branch November 2, 2020 08:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants