| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
| |
Add repeatability tests for when the range of the integers is `2**32`
(and `2**32 +/- 1` for good measure) with broadcasting. The underlying
functions called by Generator.integers and random.randint when the
inputs are broadcast are different than when the inputs are scalars.
|
| |
|
|
|
| |
Assert that an invalid value (2**n-1 for n = 8, 16, 32, 64) has not
been passed to the Lemire function.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the input to Generator.integers was 2**32, the value 2**32-1
was being passed as the `rng` argument to the 32-bit Lemire method,
but that method requires `rng` be strictly less then 2**32-1.
The fix was to handle 2**32-1 by calling next_uint32 directly.
This also works for the legacy code without changing the stream
of random integers from `randint`.
Closes gh-16066.
|
| |\
| |
| | |
BUG: Alpha parameter must be 1D in `generator.dirichlet`
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Only one dimensional alpha paramter is currently supported, but higher
dimensions were silently allowed and gave an incorrect results. This
fixes the regression. In the future, the API could be extended to allow
higher dimensional arrays for alpha.
Fixes gh-15915
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
Fixes #15871
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
slow calls to np.dtype.name replaced with np.dtype,
mtrand.pyx and _generator.pyx updated,
test test_warns_byteorder updated
before:
%timeit rs.random(): 520 ns ± 33.1 ns per loop
%timeit rg.random(): 6.36 µs ± 222 ns per loop
after:
%timeit rs.random(): 453 ns ± 6.95 ns per loop
%timeit rg.random(): 594 ns ± 9.66 ns per loop
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* BUG: use tmp dir and check version for cython test
* TST, MAINT: skip on win32, fix formatting
* TST: fixes from review
* TST: fixes from review
* TST: fixes from review
|
| | |
|
| |
|
|
|
|
|
|
| |
This reverts commit 3a9a63f81aa37b48bc3eb4efdc2e695210805aa5, reversing
changes made to 7999f7c038a50d79b06edf2d45eb5ff2c25a5a42.
A lot of problems have been exposed by this change, so best to leave it
out of the 1.18.x series and work on it in master.
|
| |\
| |
| | |
DOC, API: improve the C-API/Cython documentation and interfaces for random
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/
|/| |
DEP: issue deprecation warning when creating ragged array (NEP 34)
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
TST. API: test using distributions.h via cffi
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
DOC, API: add random.__init__.pxd and document random.* functions
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| |/ /
| |
| |
| |
| |
| | |
Test examples on Linux and Windows
Correct bug in Cython example
Improve building instructions for numba examples
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Ensure that default_rng has a return type to improve code completion
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* API: restructure and document numpy.random C-API
* DOC: fix bad reference
* API: ship, document, and start to test numpy.random C-API examples
* API, DOC, TST: fix tests, refactor documentation to include snippets
* BUILD: move public headers to numpy/core/include/numpy/random
* TST: ignore DeprecationWarnings in setuptools and numba
* DOC: document the C-API as used from Cython
|
| |\ \
| | |
| | | |
BUILD: remove SSE2 flag from numpy.random builds
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Relates to gh-6103
|
| |/ / |
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an 8 or 16 bit dtype was given to the integers() method of the
Generator class, the resulting sample was biased. The problem was
the lines of the form
const uint8_t threshold = -rng_excl % rng_excl;
in the implementations of Lemire's method, in the C file
distributions.c. The intent was to compute
(UINT8_MAX+1 - rng_excl) % rng_excl
However, when the type of rng_excl has integer conversion rank lower
than a C int (which is almost certainly the case for the 8 and 16
bit types), the terms in the expression -rng_excl % rng_excl are
promoted to int, and the result of the calculation is always 0.
The fix is to make the expression explicit, and write it as
const uint8_t threshold = (UINT8_MAX - rng) % rng_excl;
rng is used, because rng_excl is simply rng + 1; by using rng, we
we only need the constant UINT#_MAX, without the extra +1.
For consistency, I made the same change for all the data types
(8, 16, 32 and 64 bit).
Closes gh-14774.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new method
multivariate_hypergeometric(self, object colors, object nsample,
size=None, method='marginals')
of the class numpy.random.Generator implements the multivariate
hypergeometric distribution; see
https://en.wikipedia.org/wiki/Hypergeometric_distribution,
specifically the section "Multivariate hypergeometric distribution".
Two algorithms are implemented. The user selects which algorithm
to use with the `method` parameter. The default, `method='marginals'`,
is based on repeated calls of the univariate hypergeometric
distribution function. The other algorithm, selected with
`method='count'`, is a brute-force method that allocates an
internal array of length ``sum(colors)``. It should only be used
when that value is small, but it can be much faster than the
"marginals" algorithm in that case.
The C implementations of the two methods are in the files
random_mvhg_count.c and random_mvhg_marginals.c in
numpy/random/src/distributions.
|
| | | |
|
| | | |
|