Numpy: default_rng.integers (2 ** 32) renvoie toujours 0
Exemple de code de reproduction:
Je ne comprends pas pourquoi default_rng.integers(2**32) renvoie toujours 0, alors que 2**32-1 , 2**32+1 , 2**40 , etc. renvoient des nombres aléatoires comme prévu. Le résultat est un numpy.int64 , donc je m'attendais à pouvoir générer des nombres allant jusqu'à 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]
C'est bien avec 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]
Informations sur la version Numpy / Python:
J'exécute Fedora 31 avec python3-3.7.6-2.fc31.x86_64 et 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)]
vstinner
Tous les 7 commentaires
Il utilise probablement un générateur 32 bits en arrière-plan pour des vitesses plus élevées, mais jette ensuite 2**32 + 1 en 32 bits par accident! C'est définitivement un bug assez sérieux.
seberg
le 24 avr. 2020
Le problème est également en master:
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])
Cela a probablement été introduit dans https://github.com/numpy/numpy/pull/14777. Je regarderai.
WarrenWeckesser
le 24 avr. 2020
Merci @WarrenWeckesser , le problème est également dans la version 1.17, il est donc peut-être plus ancien que votre commit. Mais je pense que maintenant, cela va aussi loin dans le code et vous semblez connaître cette partie. Tellement génial, envisageait juste de cingler Kevin :).
seberg
le 24 avr. 2020
Si nous y parvenons, nous devrions essayer d'inclure le correctif dans 1.18.4 je pense.
seberg
le 24 avr. 2020
@seberg , gh-14777 a été rétroporté à 1.17.
WarrenWeckesser
le 24 avr. 2020
Il s'avère que la cause est https://github.com/numpy/numpy/pull/14501 , qui a été rétroportée à 1.17.3. Je travaille sur un correctif.
WarrenWeckesser
le 25 avr. 2020
Le correctif proposé est sur https://github.com/numpy/numpy/pull/16076
WarrenWeckesser
le 25 avr. 2020
Questions connexes
MorBilly
·
4Commentaires
MareinK
·
3Commentaires
qualiaa
·
3Commentaires
thouis
·
4Commentaires
manuels
·
3Commentaires
Commentaire le plus utile
Le problème est également en master:
Cela a probablement été introduit dans https://github.com/numpy/numpy/pull/14777. Je regarderai.