Repository navigation
BUG: np.random.zipf hangs the interpreter on pathological input #9829
Description
>>> np.random.zipf(np.nan)
# hangs forever, doesn't respond to ctrl C
>>> np.random.zipf(1.0000000000001)
# hangs for a possibly finite but very long time, also not responding to Ctrl+C
The former should probably just throw an exception. The latter is sort of inevitable with a rejection algorithm, but if we called PyErr_CheckSignals() then at least it could be cancelled.
Activity
eric-wieser commentedon Nov 20, 2017
It was fixed for Nan, but the problem remains for numbers close to 1
toslunar commentedon Sep 12, 2018
While the
nancase has been fixed, the problem remains for largea.This is probably because the following code overflows.
bashtage commentedon Apr 10, 2019
This doesn't hand forever since there is a positive probability of drawing a value of 0.0, so that
1.0-drawis 1 and the rejection sampler will always exit. It may take an extraordinarily long time (1 in 2**53), but not a bug.charris commentedon Apr 11, 2019
I think it is a bug. I think we decided that it reasonable to raise an error for parameters excessively close to 1. Note that this problem can be fixed by using a truncated part of the distribution and rewriting the majorizing distribution so that it succeeds more often, easy speedups of 1000x or more follow. See discussion at #9824. @bashtage The new randomgen should be fixed to handle this better.
mattip commentedon Apr 11, 2019
xref #13164 and #13163
vks commentedon Aug 2, 2021
I think the biggest problem is that small
aare very likely to result in an infiniteX, which is always rejected. ReturningRAND_INT_MAXinstead would fix this issue at the cost of introducing a bias.charris commentedon Aug 2, 2021
Yes. I note that other versions allow setting the maximum via an argument, which is probably the best way to do it.
BUG: random: Fix long delays/hangs with zipf(a) when a near 1.
BUG: random: Fix long delays/hangs with zipf(a) when a near 1.