Skip to content

Document MKLRandomState in the API reference and align docstrings with NumPy - #165

Open
vlad-perevezentsev wants to merge 12 commits into
masterfrom
align-docstrings-with-numpy
Open

vlad-perevezentsev wants to merge 12 commits into
masterfrom
align-docstrings-with-numpy

Conversation

@vlad-perevezentsev

Copy link
Copy Markdown
Collaborator

This PR documents MKLRandomState together with its methods, and renders it with numpydoc for consistency with NumPy's docs.
Previously the API reference only showed the deprecated RandomState alias, without its methods.

  • Document MKLRandomState and its methods via per-method autosummary pages.
  • Align distribution docstrings with NumPy: document array_like parameters, fix wrong parameter types/names, add missing Returns sections and constraint/default notes.
  • Fix rendering issues under numpydoc/Furo; add minimal custom CSS.

@github-actions

Copy link
Copy Markdown

@ndgrigorian

Copy link
Copy Markdown
Collaborator

seed : {None, int, array_like}, optional

Should we also change here to

int or array_like, optional

@jharlow-intel jharlow-intel left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks, this is a big step up for the API docs! Grouping the methods into autosummary tables and switching to numpydoc makes the reference much easier to navigate, and the docstrings now say clearly which arguments broadcast. A couple of things to sort out before merge; details inline.

  • Heads-up that this now conflicts with master in mklrand.pyx (from #189's multinormal_cholesky validation), and #192, which is approved, also touches the bytes and tomaxint docstrings. A rebase after #192 lands should sort both out. #107 overlaps api.rst and conf.py too, so it's probably easiest if this goes in before it.

with:
name: ${{ env.PACKAGE_NAME }} rendered documentation
path: ~/rendered_docs
# TEMPORARY: publish this PR's docs to gh-pages and comment the link.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think the temporary preview steps need to come out before this merges, as the comment here says. Besides pushing each PR's docs to the public gh-pages with a write token, the mshick/add-pr-comment pin is what fails the zizmor check: its # v2 comment doesn't match the pinned SHA (v2 currently points at b8f338c).

Comment thread mkl_random/mklrand.pyx Outdated
scale : float
scale : float or array_like of floats
Standard deviation (spread or "width") of the distribution.
Must be non-negative.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Small accuracy thing from aligning with NumPy: mkl_random rejects zero here (raise ValueError("scale <= 0")), while NumPy allows it, so "Must be non-negative" isn't quite right. The same goes for exponential, gamma, laplace, gumbel, logistic, and lognormal's sigma. Could we say "Must be positive" in those?

Comment thread mkl_random/mklrand.pyx Outdated
method : {'ICDF', 'BoxMuller', 'BoxMuller2'}, optional
Sampling method used by Intel MKL. Can also be specified using
tokens mkl_random.ICDF, mkl_random.BOXMULLER, mkl_random.BOXMULLER2
the tokens ``mkl_random.mklrand.ICDF``,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Nit: the public names are mkl_random.ICDF, mkl_random.BOXMULLER, and mkl_random.BOXMULLER2 (they're exported at the top level), so it might be friendlier to point at those than at mkl_random.mklrand.

vlad-perevezentsev added a commit that referenced this pull request Oct 16, 2026
Per review, older than this PR but in the lines being touched: the
Parameters block described loc and scale, which the function does not take,
and never mentioned p, while Returns claimed the values lie in [0, n]. The
support is the positive integers.

gh-165 rewrites this block as well, so that PR keeps the final wording; the
range there needs to read [0, 1) after this one.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants