| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes bug in np.random methods that would return scalars
when passed one-element array inputs. This is because
one-element ndarrays can be cast to integers / floats, which
is what functions like PyFloat_AsDouble do before converting
to the intended data type.
This commit changes the check used to determine whether the
inputs are purely scalar by converting all inputs to arrays
and checking if the resulting shape is an empty tuple (scalar)
or not (array).
Closes gh-4263.
|
|
|
|
|
|
| |
Added a whole new suite of tests to ensure that
functions in mtrand.pyx which are broadcastable
actually broadcast their arguments properly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only for 1d-ndarrays exactly, as subtypes (e.g. masked arrays) may not
allow direct shuffle of the underlying buffer (in fact, the old
implementation destroyed the underlying values of masked arrays while
shuffling).
Also handles struct-containing-object 1d ndarrays properly.
See #6776 for an earlier, less general (but even faster: ~6x)
improvement attempt, #5514 for the original issue.
|
| |
|
|\
| |
| | |
ENH: Add dtype argument to random.randint.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* check exceptions
* check extreme bounds are reachable
* check that all values are in the specified bounds
* check repeatability of sequences
More exact statistical tests would be nice, but that is another
project.
|
|/ |
|
|
|
|
|
|
|
| |
Redistributes the code between the randint and random_integers
methods so that we can generate integers up to and including
np.iinfo('l').max with random_integers, which previously
would have caused an OverflowError.
|
| |
|
|
|
|
|
| |
Noncentral chi-square reduces to a central chi-square, so
just defer to that.
|
|
|
|
| |
Closes #5766.
|
|
|
|
|
|
|
|
| |
This fixes issue #2138 by checking that the range (i.e. high - low) is finite
before invoking `rk_uniform`.
A test case was added to ensure valid ranges do not throw, but invalid ranges
do.
|
|
|
|
| |
http://lists.alioth.debian.org/pipermail/glibc-bsd-commits/2014-September/004163.html
|
|\
| |
| | |
TST: accept small error in threaded random test
|
| |
| |
| |
| |
| |
| |
| | |
freebsd and windows change x87 precision mode (fctrl bit 8 and 9) from
extended to double in child threads so the random numbers cannot be
exactly the same from master and child threads.
see gh-4909
|
|/ |
|
|
|
|
|
|
|
| |
rho results in 0. for kappa < 1.4e-8 whch leads to nans appearing and an
infinite loop.
the second order taylor expansion is more precise up to at least 1e-5.
Closes gh-4720
|
|
|
|
|
|
| |
mtrand accepts seeds larger than 32 bit but silently truncates them back
to 32 bit. This can lead to accidentally getting the same random stream
for two different seeds, e.g. 1 and 1 + 2**40.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The random module currently relies on the GIL for the state
synchronization which hampers threading performance.
Instead add a lock to the RandomState object and take it for all
operations calling into randomkit while releasing the GIL.
This allows parallizing random number generation using multiple states
or asynchronous generation in a worker thread.
Note that with a large number of threads the standard mersenne twister
used may exhibit overlap if the number of parallel streams is large
compared to the size of the state space, though due to the limited
scalability of Python in regards to threads this is likely not a big
issue.
|
|
|
|
| |
Adds check with np.isnan(p) and raises ValueError if check is positive.
|
|
|
|
|
|
|
|
| |
Explicitly Test that the default shape does not raise a
DeprecationWarning.
Check that a covariance matrix that is not positive-semidefinite
raises a RuntimeWarning.
|
|
|
|
| |
Closes gh-3173
|
|
|
|
|
| |
closes gh-4270 and gh-3263
also regenerate with cython 0.20.1
|
|
|
|
|
|
|
| |
Run the 2to3 ws_comma fixer on *.py files. Some lines are now too long
and will need to be broken at some point. OTOH, some lines were already
too long and need to be broken at some point. Now seems as good a time
as any to do this with open PRs at a minimum.
|
|
|
|
|
|
| |
Range test for n was incorrect.
Closes #3480
|
|
|
|
|
| |
Also edited the 'Parameters' section of the docstring to comply
with the numpy docstring standard.
|
|
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
|\
| |
| | |
BUG: fix random.choice scalar object result and disallow 0-d arrays
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Object arrays failed due to bad check for finding out if the result should
be a scalar type and not an array when size=None. Also in this case the
creation of the new array was wrong. This should be fixed with this.
The second fix is to forbid 0-d arrays. Allowing 0-d arrays does not
make much sense. But it is dangerous because for example floats will
be interpreted as 1-d arrays, while one may expect that they are interpreted
as integers. This also saves the trouble of reliably detecting all integers...
|
|/
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that in 32bit Ubuntu 12.04, one gets the following:
>
/home/njs/numpy/.tox/py27/local/lib/python2.7/site-packages/numpy/random/tests/test_random.py(363)test_pareto()
-> np.testing.assert_array_almost_equal(actual, desired, decimal=15)
(Pdb) actual[1, 0]
52828779.702948704
(Pdb) desired[1, 0]
52828779.702948518
and the test was comparing the numbers to 1e-14, which obviously
failed.
Fixes #424.
|
|
|
|
|
|
|
|
|
| |
The logic in np.random.shuffle was... not very sensible. Fixes trac
ticket #2074.
This patch also exposes a completely unrelated issue in
numpy.testing. Filed as Github issue #347 and marked as knownfail for
now.
|
|
|
|
|
| |
sampling with replacement, change searchsorted to use side='right',
and regenerate mtrand.c.
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks to Mark Sienkiewicz for testing.
|
|
|
|
|
|
|
|
|
| |
precision.
It is not yet confirmed this is the right precision, since I don't have an
RHEL4 test machine. Changing this anyway for 1.6.0 beta 1.
See ticket 1768.
|
| |
|
| |
|
|
|
|
|
|
|
| |
These tests ensure that returned values stay the same, which is necessary
because other tests rely on this when setting a fixed seed.
Thanks to Vincent Davis.
|
|
|
|
| |
functions from np.testing.
|
| |
|
|
|
|
| |
original by committer.
|
| |
|
| |
|
| |
|