| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
When an axis argument was given, shuffle was using the original length of
the array instead of the length of the given axis. This meant that, for
example, if an array with shape (2, 10) was shuffled with axis=1, only the
first two columns were shuffled.
|
| | |
| |
| |
| |
| | |
* BUILD: remove unused functions, rearrange headers (from CC=clang)
* MAINT: check enum at API call, not in provate function
|
| | |\
| | |
| | | |
DOC: update submodule docstrings, remove info.py files
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
See https://mail.python.org/pipermail/numpy-discussion/2019-September/080088.html
for discussion. We need to do this right, and add tests and docs.
All this PR does is not install bitgen.h, common.pxd and bit_generator.pxd
(they're still shipped in the sdist, that is needed).
Should be backported to 1.17.x
|
| | |\
| | |
| | | |
BUG: random: Create a legacy implementation of random.binomial.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Create a legacy implementation of the random_binomial method of
RandomState that does not include the "short-circuit" check for
n == 0 or p == 0. This ensures that the stream of variates
is consistent with the behavior in 1.16.
Closes gh-14522.
|
| | |/
| |
| |
| |
| |
| | |
Avoid unnecessary use of ctypes in Generators
closes #14131
|
| | |\
| | |
| | | |
MAINT: random: Remove a few duplicated C function prototypes.
|
| | | | |
|
| | |\ \
| | |/
| |/| |
ENH: Add axis argument to random.permutation and random.shuffle
|
| | | | |
|
| | |\ \
| | | |
| | | | |
MAINT: remove the entropy c-extension module
|
| | | |/ |
|
| | |/
| |
| |
| |
| |
| | |
Fix randint to use 32-bit path when range is exactly 2**32
closes #14189
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Fixes #14457
|
| | |
| |
| |
| | |
Closes gh-14359
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* fixing segfault error in np.random.permutation(x) where x is str
* removed whitespace
* changing error type to ValueError
* changing error type to ValueError
* changing error type to ValueError
* tests
* changed error to IndexError for backward compatibility with numpy 1.16
* fixes numpy.randomstate.permutation segfault too
* Rolled back to ValueError for Generator.permutation() for all 0-dimensional
* fixes refuige erro and rolls backs to AxisError
|
| | |\
| | |
| | | |
BUG: Fix numpy.random bug in platform detection
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes this compiler warning:
gcc: numpy/random/bit_generator.c
numpy/random/bit_generator.c:4889:41: warning: comparison of integers of different signs: 'int' and 'uint32_t' (aka 'unsigned int') [-Wsign-compare]
__pyx_t_6 = ((__pyx_v_self->pool_size != __pyx_v_5numpy_6random_13bit_generator_DEFAULT_POOL_SIZE) != 0);
~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This changes the string conversion of an expected
dtype in an error message from e.g.
"<class 'numpy.float64'>" to "float64".
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
This commit fixes a simple formatting error in the
generation of an exception message. The message
is supposed to contain the expected vs. the actual
dtype, but instead contained two times the expected
dtype.
|
| | |\
| | |
| | | |
ENH: add c-imported modules for freeze analysis in np.random
|
| | | | |
|
| | |/ |
|
| | | |
|
| | |
| |
| | |
Co-Authored-By: Eric Wieser <wieser.eric@gmail.com>
|
| | |
| |
| |
| | |
separately for each method
|
