Numpy: default_rng.integers(2**32) always return 0

Created on 24 Apr 2020  ·  7Comments  ·  Source: numpy/numpy

Reproducing code example:

I don't understand why default_rng.integers(2**32) always return 0, whereas 2**32-1, 2**32+1, 2**40, etc. return random numbers as expected. The result is a numpy.int64, so I expected to be able to generate numbers of up 2**64-1.

$ python3.7 -c 'from numpy.random import default_rng; rng=default_rng(); print([rng.integers(2**32) for _ in range(5)])'
[0, 0, 0, 0, 0]

It's fine with 2**40:

$ python3.7 -c 'from numpy.random import default_rng; rng=default_rng(); print([rng.integers(2**40) for _ in range(5)])'
[386296210341, 896689857600, 958588149890, 364800985883, 643738305251]

Numpy/Python version information:

I'm running Fedora 31 with python3-3.7.6-2.fc31.x86_64 and python3-numpy-1.17.4-2.fc31.x86_64:

vstinner@apu$ python3.7
Python 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, numpy; print(numpy.__version__, sys.version)
1.17.4 3.7.6 (default, Jan 30 2020, 09:44:41) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)]
00 - Bug 06 - Regression numpy.random high

Most helpful comment

The problem is in master, too:

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '1.19.0.dev0+6d6df47'

In [3]: rng = np.random.default_rng()

In [4]: rng.integers(2**32, size=8)
Out[4]: array([0, 0, 0, 0, 0, 0, 0, 0])

This was probably introduced in https://github.com/numpy/numpy/pull/14777. I'll take a look.

All 7 comments

Probably it uses a 32bit generator in the background for higher speeds, but then casts 2**32 + 1 to 32bit by accident! Its definitely a pretty serious bug.

The problem is in master, too:

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '1.19.0.dev0+6d6df47'

In [3]: rng = np.random.default_rng()

In [4]: rng.integers(2**32, size=8)
Out[4]: array([0, 0, 0, 0, 0, 0, 0, 0])

This was probably introduced in https://github.com/numpy/numpy/pull/14777. I'll take a look.

Thanks @WarrenWeckesser, the problem is also in 1.17, so it may be older than your commit. But I do think by now it goes this deep into the code and you seem to know that part. So great, was just considering to ping Kevin :).

If we manage, we should try to include the fix in 1.18.4 I think.

@seberg, gh-14777 was backported to 1.17.

It turns out the cause is https://github.com/numpy/numpy/pull/14501, which was backported to 1.17.3. I'm working on a fix.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

qualiaa picture qualiaa  ·  3Comments

marcocaccin picture marcocaccin  ·  4Comments

Levstyle picture Levstyle  ·  3Comments

perezpaya picture perezpaya  ·  4Comments

toddrjen picture toddrjen  ·  4Comments