| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Avoid conditional compilation and move old version to legacy_vonmises
Small clean up
Additional comments
|
| |
|
|
|
|
|
|
| |
Apply vonmises fix only to Generator
Add tests for correctness
closes #17378
closes #17275
|
| | |
|
| |
|
|
| |
normal distribution (which the von mises distribution converges to).
|
| |
|
|
|
| |
Cast to avoid warnings
Correct function
|
| | |
|
| |
|
|
| |
Most compilers should optimize it, but it doesn't hurt to inline and has a better name
now.
|
| |
|
|
| |
Remove unused file containing the old polynomial representation.
|
| |
|
|
|
|
| |
Refactor polynomial to be unsigned long array
Remove unused code
Fix md5 calculation on BE
|
| |
|
|
|
|
| |
Use the original loop order instead of an inverted order
closes #15394
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* BUILD: remove unused functions, rearrange headers (from CC=clang)
* MAINT: check enum at API call, not in provate function
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| | |
MAINT: remove the entropy c-extension module
|
| | | |
|
| |/
|
|
|
|
| |
Fix randint to use 32-bit path when range is exactly 2**32
closes #14189
|
| | |
|
| | |
|
| |\
| |
| | |
MAINT, BUG: fixes from seedsequence
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Add pragme and include for Windows PCG64
|
| |\
| |
| | |
MAINT: remove dSFMT
|
| | | |
|
| |\ \
| |/
|/| |
MAINT: random: Fix a few compiler warnings.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes:
gcc: numpy/random/src/xoshiro256/xoshiro256.c
numpy/random/src/xoshiro256/xoshiro256.c:39:16: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
for (i = 0; i < sizeof JUMP / sizeof *JUMP; i++)
~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc: numpy/random/src/xoshiro512/xoshiro512.c
numpy/random/src/xoshiro512/xoshiro512.c:43:17: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
for (i = 0; i < sizeof JUMP / sizeof *JUMP; i++)
~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
numpy/random/src/xoshiro512/xoshiro512.c:46:23: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
for (w = 0; w < sizeof s_placeholder / sizeof *s_placeholder; w++)
~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc: numpy/random/src/distributions/distributions.c
numpy/random/src/distributions/distributions.c:185:14: warning: comparison of integers of different signs: 'int64_t' (aka 'long long') and 'const uint64_t' (aka 'const unsigned long long') [-Wsign-compare]
if (rabs < ki_double[idx])
~~~~ ^ ~~~~~~~~~~~~~~
numpy/random/src/distributions/distributions.c:230:14: warning: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const uint32_t' (aka 'const unsigned int') [-Wsign-compare]
if (rabs < ki_float[idx])
~~~~ ^ ~~~~~~~~~~~~~
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary of the changes:
* Move the functions random_hypergeometric_hyp, random_hypergeometric_hrua
and random_hypergeometric from distributions.c to legacy-distributions.c.
These are now the legacy implementation of hypergeometric.
* Add the files logfactorial.c and logfactorial.h,
containing the function logfactorial(int64_t k).
* Add the files random_hypergeometric.c and random_hypergeometric.h,
containing the function random_hypergeometric (the new implementation
of the hypergeometric distribution). See more details below.
* Fix two tests in numpy/random/tests/test_generator_mt19937.py that
used values returned by the hypergeometric distribution. The
new implementation changes the stream, so those tests needed to
be updated.
* Remove another test obviated by an added constraint on the arguments
of hypergeometric.
Details of the rewrite:
If you carefully step through the old function rk_hypergeometric_hyp(),
you'll see that the end result is basically the same as the new function
hypergeometric_sample(), but the new function accomplishes the result with
just integers. The floating point calculations in the old code caused
problems when the arguments were extremely large (explained in more detail
in the unmerged pull request https://github.com/numpy/numpy/pull/9834).
The new version of hypergeometric_hrua() is a new translation of
Stadlober's ratio-of-uniforms algorithm for the hypergeometric
distribution. It fixes a mistake in the old implementation that made the
method less efficient than it could be (see the details in the unmerged
pull request https://github.com/numpy/numpy/pull/11138), and uses a faster
function for computing log(k!).
The HRUA algorithm suffers from loss of floating point precision when
the arguments are *extremely* large (see the comments in github issue
11443). To avoid these problems, the arguments `ngood` and `nbad` of
hypergeometric must be less than 10**9. This constraint obviates an
existing regression test that was run on systems with 64 bit long
integers, so that test was removed.
|
| |
|
|
| |
... and remove the unused arrays that were in ziggurat.h.
|
| |
|
|
|
|
| |
In numpy/random/src/legacy/, rename distributions-boxmuller.c to
legacy-distributions.c. This file holds all the legacy distributions,
so the new name is more accurate.
|
| |
|
|
| |
The file numpy/random/src/distributions/binomial.h was empty and unused.
|
| |\
| |
| | |
MAINT: Use intrinsics in Win64-PCG64
|
| | |
| |
| |
| | |
Use intrinsics to speed up PCG64 on Windows 64
|