Issue 1:
The PCG generator used by Numpy has a significant amount self-correlation. That is, for each sequence generated from a seed there is a large number of correlated, nonoverlapping sequences starting from other seeds. By "correlated" I mean that interleaving two such sequences and testing the result you obtain failures that did not appear in each sequence individually.

The probability that two generators out of large set of terminals get two of those sequences is nonnegligible. Why this happens from a mathematical viewpoint is well known but it is explained here in detail: http://prng.di.unimi.it/pcg.pgp (see "Subsequences within the same generator").

To show this problem directly, I wrote this simple C program reusing the Numpy code: http://prng.di.unimi.it/intpcgnumpy.c . The program takes two 128-bit states of two generators (with the same LCG constant or "stream") in the form of high and low bits, interleaves their output and writes it in binary form. Once we send it through PractRand, we should see no statistical failure, as the two streams should be independent. But if try to start from two states with the same 64 lower bits, you get:

./intpcgnumpy 0x596d84dfefec2fc7 0x6b79f81ab9f3e37b 0x8d7deae980a64ab0 0x6b79f81ab9f3e37b | stdbuf -oL ~/svn/c/xorshift/practrand/RNG_test stdin -tf 2 -te 1 -tlmaxonly -multithreaded

RNG_test using PractRand version 0.94

RNG = RNG_stdin, seed = unknown

test set = expanded, folding = extra

rng=RNG_stdin, seed=unknown
length= 128 megabytes (2^27 bytes), time= 2.2 seconds
Test Name Raw Processed Evaluation
BCFN(0+0,13-2,T) R= +27.6 p = 1.0e-13 FAIL
BCFN(0+1,13-2,T) R= +68.0 p = 2.3e-34 FAIL !!!
BCFN(0+2,13-3,T) R= +90.8 p = 8.8e-43 FAIL !!!
BCFN(0+3,13-3,T) R=+120.6 p = 6.9e-57 FAIL !!!!
DC6-6x2Bytes-1 R= +8.9 p = 4.0e-5 mildly suspicious
DC6-5x4Bytes-1 R= +15.7 p = 4.3e-9 very suspicious
[Low1/8]BCFN(0+0,13-4,T) R= +11.6 p = 4.9e-5 unusual
...and 1074 test result(s) without anomalies

You can even go lower—you just need the same 58 lower bits:

./intpcgnumpy 0x596d84dfefec2fc7 0x0579f81ab9f3e37b 0x8d7deae980a64ab0 0x6b79f81ab9f3e37b | stdbuf -oL ~/svn/c/xorshift/practrand/RNG_test stdin -tf 2 -te 1 -tlmaxonly -multithreaded

[...]
rng=RNG_stdin, seed=unknown
length= 32 gigabytes (2^35 bytes), time= 453 seconds
Test Name Raw Processed Evaluation
[Low1/16]FPF-14+6/32:cross R= +11.6 p = 4.0e-10 VERY SUSPICIOUS
[Low1/32]FPF-14+6/32:cross R= +16.5 p = 3.2e-14 FAIL
[Low1/32]FPF-14+6/16:cross R= +12.8 p = 3.8e-11 VERY SUSPICIOUS
[Low1/64]FPF-14+6/64:cross R= +6.8 p = 4.8e-6 mildly suspicious
[Low1/64]FPF-14+6/32:cross R= +6.0 p = 1.9e-5 unusual
[Low1/64]FPF-14+6/16:cross R= +5.5 p = 5.8e-5 unusual
[Low4/32]FPF-14+6/64:all R= +5.8 p = 5.9e-5 unusual
[Low4/32]FPF-14+6/32:(0,14-0) R= +7.7 p = 1.0e-6 unusual
[Low4/32]FPF-14+6/32:(1,14-0) R= +7.7 p = 9.1e-7 unusual
[Low4/32]FPF-14+6/32:all R= +6.5 p = 1.3e-5 unusual
[Low4/64]FPF-14+6/64:all R= +5.9 p = 5.1e-5 unusual
[Low4/64]FPF-14+6/64:cross R= +8.2 p = 3.0e-7 suspicious
[Low4/64]FPF-14+6/32:(0,14-0) R= +7.6 p = 1.0e-6 unusual
[Low8/64]FPF-14+6/64:(0,14-0) R= +17.0 p = 2.2e-15 FAIL
[Low8/64]FPF-14+6/64:(1,14-0) R= +9.1 p = 5.1e-8 mildly suspicious
[Low8/64]FPF-14+6/64:all R= +12.7 p = 2.1e-11 VERY SUSPICIOUS
[Low8/64]FPF-14+6/32:(0,14-0) R= +12.8 p = 1.7e-11 VERY SUSPICIOUS
[Low8/64]FPF-14+6/32:all R= +11.0 p = 9.3e-10 VERY SUSPICIOUS
...and 1696 test result(s) without anomalies

Note that to get more the 50% probability that two generators start from two correlated seed (chosen at random) you need just about half a million generators starting at random (birthday paradox). And if you consider the probability that they do not exactly start from the same state, but have significant overlapping correlating sequences, you need much less.

Any sensible generator from the literature will not behave like that. You can choose adversarially any two starting states of MRG32k3a, SFC64, CMWC, xoshiro256++, etc., and as long as you generate nonoverlapping sequences you will not see the failures above. This is a major drawback that can pop up when a number of devices uses the generator and one assumes (as it should be) that pairwise those sequences should not show correlation. The correlation can induce unwanted behavior that is hard to detect.

Please at least document somewhere that the generator should not be used on multiple terminals or in a highly parallel environment.

The same can happen with different "streams", as the sequences generated by an LCG by changing the additive constant are all the same modulo a change of sign and an additive constant. You can see some discussion here: rust-random/rand#907 and a full mathematical discussion of the problem here: https://arxiv.org/abs/2001.05304 .

Issue 2:
I wanted to build the PDF documentation (using Sphinx 2.2.1 and current versions of scipy, matplotlib, etc from pip install and using numpy from git at b83f10e) and was disconcerted that it actually succeeded 😉

Turns out after checking that https://github.com/numpy/numpy/blob/master/doc/source/conf.py uses removed latex_preamble variable (it was removed at Sphinx 1.6.1). Correct syntax is now with latex_elements['preamble']. I did that, and obtained the failure on building numpy-ref.pdf that I was expecting:

! Extra }, or forgotten \endgroup.
\@endpbox ...\@arstrutbox \color@endgroup \egroup
\the \LT@p@ftn \global \LT...
l.131934 \item[{Parameters}]
\leavevmode

This is caused by these lines

numpy/doc/source/conf.py

Lines 187 to 189
in
b83f10e

\usepackage{expdlist}

\let\latexdescription=\description

\def\description{\latexdescription{}{} \breaklabel}

I know two fixes:

add \usepackage{enumitem}. I don't recommend that because the fact that it fixes the expdlist breakage appears unintentional, it is sheer luck (and I tested it on only one small example, not the full numpy-ref.tex). In the past Sphinx users used enumitem to avoid Too deeply nested error, but since Sphinx 1.5, there is latex_elements['maxlistdepth'] to fix that LaTeX limitation:

latex_elements['maxlistdepth'] = '10' # should be enough, increase at will (don't use '2048' as this would create needlessly thousands of TeX macros)

the second fix is to be found in a scipy/scipy@c881fde and I copy it here. It would thus be like this:

% In the parameters section, place a newline after the Parameters
% header
\usepackage{expdlist}
\let\latexdescription=\description
\def\description{\latexdescription{}{} \breaklabel}

% Remove extra space
\usepackage{etoolbox}
\makeatletter
\patchcmd\@item{{\@breaklabel} }{{\@breaklabel}}{}{}
\makeatother

% Fix bug in expdlist's way of breaking the line after long item label
\makeatletter
\def\breaklabel{%
\def\@breaklabel{%
\leavevmode\par
% now a hack because Sphinx inserts \leavevmode after term node
\def\leavevmode{\def\leavevmode{\unhbox\voidb@x}}%
}%
}
\makeatother

Side remark about

numpy/doc/source/conf.py

Lines 182 to 183
in
b83f10e

\usepackage{amsmath}

\DeclareUnicodeCharacter{00A0}{\nobreakspace}

It is unneeded because already done by Sphinx

As for the remainder of the LaTeX code in this former latex_preamble it may need some check that it still gives a desired effect in the PDF.

By the way I would recommend using --halt-on-error for pdflatex builds. In case of an error, the make exits with error code but the LaTeX console output is gigantic and the log file too and one loses time searching for first TeX error, whereas with --halt-on-error this is more efficient.

The

numpy/doc/Makefile

Line 220
in
b83f10e

perl -pi -e 's/\t(latex.*|pdflatex) (.*)/\t-$$1 -interaction batchmode $$2/' build/latex/Makefile

does nothing actually with current Sphinx produced Makefile in latex build directory. You can use the method from https://www.sphinx-doc.org/en/master/usage/builders/index.html#sphinx.builders.latex.LaTeXBuilder

To pass options directly to the (pdf|xe|lua)latex binary, use variable LATEXOPTS, for example:

make latexpdf LATEXOPTS="--halt-on-error"

and

Since 1.6, make latexpdf uses latexmk (not on Windows). This makes sure the needed number of runs is automatically executed to get the cross-references, bookmarks, indices, and tables of contents right.

One can pass to latexmk options via the LATEXMKOPTS Makefile variable. For example:

make latexpdf LATEXMKOPTS="-silent"

(this is with standard Sphinx distributed Makefile, in your case replace latexpdf by -C build/latex all-pdf) and the two can be combined but then (with patches of expdlist above commented out) the LaTeX error does not make it to the console output only to the end of the log file:

$ make numpy-ref.pdf LATEXOPTS="--halt-on-error" LATEXMKOPTS="--silent"
latexmk -pdf -dvi- -ps- --silent 'numpy-ref.tex'
Latexmk: Run number 1 of rule 'makeindex numpy-ref.idx'
Latexmk: Run number 1 of rule 'pdflatex'
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
Latexmk: Summary of warnings from last run of (pdf)latex:
Latex found 4 multiply defined reference(s)
Latex failed to resolve 388 citation(s)
Collected error summary (may duplicate other messages):
pdflatex: Command for 'pdflatex' gave return code 1
Refer to 'numpy-ref.log' for details
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
make: *** [Makefile:33: numpy-ref.pdf] Error 12

One has to go in numpy-ref.log find the LaTeX error causing abort:

! Extra }, or forgotten \endgroup.
\@endpbox ...\@arstrutbox \color@endgroup \egroup
\the \LT@p@ftn \global \LT...
l.131952 \item[{Parameters}]
\leavevmode
Here is how much of TeX's memory you used:
26928 strings out of 493377
686470 string characters out of 6157389
755139 words of memory out of 5000000
26189 multiletter control sequences out of 15000+600000
84239 words of font info for 133 fonts, out of 8000000 for 9000
500 hyphenation exceptions out of 8191
51i,26n,49p,1225b,732s stack positions out of 5000i,500n,10000p,200000b,80000s

! ==> Fatal error occurred, no output PDF file produced!

To recap, numpy-ref.pdf builds currently because latex_preamble from doc/source/conf.py is ignored! If this LaTeX configuration was not ignored, the build would fail due to usage of very old (1999) LaTeX package expdlist which causes usage of description lists in table cells break LaTeX (and there is one such usage subsection distutils.misc from section Modules in numpy.distuils part of numpy-ref). A fix is known from an April 2018 scipy commit scipy/scipy@c881fde.