summaryrefslogtreecommitdiff
path: root/numpy/random/src
Commit message (Collapse)AuthorAgeFilesLines
* BUG: random: Don't return negative values from Generator.geometric.warren2023-04-301-1/+9
| | | | | | | | | | In C, when the integer part of a double exceeds the maximum int64, casting the double to int64_t is undefined behavior. On some platforms, the result is 2**64-1 and on others it is -2**64. That results in rng.geometric() returning -2**64 when p was sufficiently small on some platforms. The fix is to never invoke undefined behavior by ensuring we don't attempt to cast very large double values to int64_t.
* MAINT: replace `NPY_INLINE` with `inline`Ralf Gommers2022-11-256-52/+53
| | | | Closes gh-22100
* BLD: add back stdlib.h include in pcg64.hChristoph Reiter2022-09-111-1/+4
| | | | | | | | | This seems to have been removed by accident in #21887 stdlib.h is required for _rotr64() further down. Fixes: error: call to undeclared function '_rotr64'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
* DEP: drop support for msvc<=1900 and Interix (#22139)Matti Picus2022-08-191-4/+4
| | | | | [ci skip] Co-authored-by: h-vetinari <h.vetinari@gmx.com>
* Allow GCC compile on mingw-w64-based systemsMatthew Brett2022-06-293-3/+3
| | | | | | | Macro `__MINGW32__` always defined for Mingw-w64 compilers (32- or 64-bit): https://sourceforge.net/p/predef/wiki/Compilers/
* BUG: Get full precision for 32 bit floating point random values.warren2021-11-061-1/+1
| | | | | | | | | | | | | | | | The formula to convert a 32 bit random integer to a random float32, (next_uint32(bitgen_state) >> 9) * (1.0f / 8388608.0f) shifts by one bit too many, resulting in uniform float32 samples always having a 0 in the least significant bit. The formula is corrected to (next_uint32(bitgen_state) >> 8) * (1.0f / 16777216.0f) Occurrences of the incorrect formula in numpy/random/tests/test_direct.py were also corrected. Closes gh-17478.
* BUG: Correct incorrect advance in PCG with emulated int128Kevin Sheppard2021-10-061-2/+1
| | | | | | | Correct incorrect implemetation of carry in PCG64 and PCG64DXSM when advancing more than 2**64 steps closes #20048
* DOC: Fix typos in the random and f2py documentation. (#20004)MalikIdreesHasanKhan2021-10-011-1/+1
| | | * Fix typos
* MAINT: random: Use expm1 where appropriate.warren2021-09-231-3/+3
|
* ENH: Add support for windows on arm targets (#19513)Niyas Sait2021-07-271-1/+7
| | | | | | | | | | | | | | | | | | | | * add support for windows on arm targets * Philox: Use _umulh intrinsic for ARM64 target * CPU Detection: Refactor to avoid separate pre-processor definition for WoA * adapt test_dragon4 to avoid using pow (**) to workaround issue in windows C RT for arm64 * Update numpy/core/include/numpy/npy_cpu.h Co-authored-by: Matti Picus <matti.picus@gmail.com> * add release note for numpy windows/arm64 support * Update 19513.new_feature.rst Co-authored-by: Matti Picus <matti.picus@gmail.com> Co-authored-by: Charles Harris <charlesr.harris@gmail.com>
* ENH: manually inline code for performance.Robert Kern2021-05-071-14/+29
|
* BUG: Wrong logic for WindowsRobert Kern2021-05-041-1/+0
|
* ENH: add the emulated 128-bit math for PCG64DXSMRobert Kern2021-05-041-1/+59
|
* ENH: Add PCG64DXSM implementation.Robert Kern2021-05-042-0/+74
|
* PERF: Use exponentials in place of inversionKevin Sheppard2021-03-222-2/+6
| | | | Use exponentials rather than generating exponentials via inversion
* BUG: Use lop1p to improve numerical precisionKevin Sheppard2021-03-172-21/+56
| | | | | | | Use log1p(-x) instead of log(1 - x) Seperate legacy version from current closes #17020
* BUG: np.random: Use log1p to improve precisionEric Wieser2021-03-171-11/+11
| | | | This reduces the number of cases when floating point precision makes the argument to `log` become `0`
* CLN: Move to legacy functionKevin Sheppard2021-02-262-18/+79
| | | | | | Avoid conditional compilation and move old version to legacy_vonmises Small clean up Additional comments
* BUG: Prevent RandomState from changingKevin Sheppard2021-02-261-7/+13
| | | | | | | | Apply vonmises fix only to Generator Add tests for correctness closes #17378 closes #17275
* Fixed style and added check for bounds in [-pi,pi] interval.Raúl Montón Pinillos2021-02-261-6/+17
|
* Fixed Von Mises distribution for big values of kappa by falling back to a ↵Raúl Montón Pinillos2021-02-261-3/+8
| | | | normal distribution (which the von mises distribution converges to).
* MAINT: Correct code producing warningsKevin Sheppard2021-02-181-1/+1
| | | | | Cast to avoid warnings Correct function
* BLD: Enable Werror=undef in travisSayed Adel2020-11-171-3/+3
|
* MAINT: precompute log(2.0 * M_PI) in `random_loggam' (gh-16237)Elia Franzella2020-05-191-10/+12
| | | | Most compilers should optimize it, but it doesn't hurt to inline and has a better name now.
* MAINT: Remove unused fileKevin Sheppard2020-05-121-215/+0
| | | | Remove unused file containing the old polynomial representation.
* REF: Refactor jump codeKevin Sheppard2020-05-123-116/+143
| | | | | | Refactor polynomial to be unsigned long array Remove unused code Fix md5 calculation on BE
* BUG: Correct loop order in MT19937 jumpKevin Sheppard2020-05-122-3/+9
| | | | | | Use the original loop order instead of an inverted order closes #15394
* MAINT: random: Add assert() statements.Warren Weckesser2020-04-261-0/+11
| | | | | Assert that an invalid value (2**n-1 for n = 8, 16, 32, 64) has not been passed to the Lemire function.
* BUG: random: Generator.integers(2**32) always returned 0.Warren Weckesser2020-04-261-11/+31
| | | | | | | | | | | | 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.
* BLD: use 0.3.7 release version, add dependency on libgfortran5mattip2020-01-172-2/+2
|
* Fix typos, via a Levenshtein-style correctorBrian Wignall2019-12-191-1/+1
|
* API, DOC: change names to multivariate_hypergeometric, improve docsmattip2019-12-042-4/+4
|
* API: revert changes to standard_t, cauchymattip2019-11-301-2/+2
|
* API: rename functions in distributions.c,hmattip2019-11-291-46/+39
|
* API: restructure and document numpy.random C-API (#14604)Matti Picus2019-11-194-4/+4
| | | | | | | | | | | | | | | | * 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
* BUG: random: biased samples from integers() with 8 or 16 bit dtype.Warren Weckesser2019-10-241-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ENH: random: Add the multivariate hypergeometric distributionWarren Weckesser2019-10-182-0/+269
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* API: remove unused functions from distributions.hmattip2019-10-112-7/+19
|
* API: refactor function names in distribution.{h,c}, refactor float_fillmattip2019-10-112-211/+72
|
* API: rearrange the cython files in numpy.randommattip2019-10-118-349/+3
|
* BLD: remove unused functions, rearrange headers (from CC=clang) (#14534)Matti Picus2019-09-264-6/+5
| | | | | * BUILD: remove unused functions, rearrange headers (from CC=clang) * MAINT: check enum at API call, not in provate function
* MAINT: don't install partial numpy.random C/Cython API.Ralf Gommers2019-09-212-1/+21
| | | | | | | | | 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.Warren Weckesser2019-09-164-6/+49
| | | | | | | | | 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: random: Remove a few duplicated C function prototypes.Warren Weckesser2019-09-151-5/+0
|
* Merge pull request #14498 from mattip/random-namespaceRalf Gommers2019-09-152-128/+0
|\ | | | | MAINT: remove the entropy c-extension module
| * MAINT: remove the entropy c-extension modulemattip2019-09-132-128/+0
| |
* | BUG: Fix randint when range is 2**32Kevin Sheppard2019-09-141-2/+2
|/ | | | | | Fix randint to use 32-bit path when range is exactly 2**32 closes #14189
* BUG: do not force emulation of 128-bit arithmetic.Robert Kern2019-06-272-9/+20
|
* MAINT: move location of bitgen.hmattip2019-06-272-19/+1
|
* Merge pull request #13837 from mattip/seedsequence2Charles Harris2019-06-261-1/+1
|\ | | | | MAINT, BUG: fixes from seedsequence
View Lorry Controller Status