Numpy: default_rng.integers (2 ** 32) geben immer 0 zurück
Beispiel für die Wiedergabe von Code:
Ich verstehe nicht, warum default_rng.integers(2**32) immer 0 zurückgibt, während 2**32-1 , 2**32+1 , 2**40 usw. wie erwartet Zufallszahlen zurückgeben. Das Ergebnis ist ein numpy.int64 , daher habe ich erwartet, dass ich Zahlen von bis zu 2**64-1 generieren kann.
$ 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]
Es ist in Ordnung mit 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]
Informationen zur Numpy / Python-Version:
Ich verwende Fedora 31 mit python3-3.7.6-2.fc31.x86_64 und 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
Alle 7 Kommentare
Wahrscheinlich verwendet es einen 32-Bit-Generator im Hintergrund für höhere Geschwindigkeiten, wirft dann aber versehentlich 2**32 + 1 auf 32-Bit! Es ist definitiv ein ziemlich schwerwiegender Fehler.
seberg
am 24. Apr. 2020
Das Problem liegt auch im 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])
Dies wurde wahrscheinlich in https://github.com/numpy/numpy/pull/14777 eingeführt. Ich werde einen Blick darauf werfen.
WarrenWeckesser
am 24. Apr. 2020
Vielen Dank an @WarrenWeckesser , das Problem liegt auch in 1.17, daher ist es möglicherweise älter als Ihr Commit. Aber ich denke jetzt geht es so tief in den Code und Sie scheinen diesen Teil zu kennen. So toll, habe gerade darüber nachgedacht, Kevin anzupingen :).
seberg
am 24. Apr. 2020
Wenn wir es schaffen, sollten wir versuchen, das Update in 1.18.4 aufzunehmen, denke ich.
seberg
am 24. Apr. 2020
@seberg , gh-14777 wurde auf 1.17 zurückportiert.
WarrenWeckesser
am 24. Apr. 2020
Es stellt sich heraus, dass die Ursache https://github.com/numpy/numpy/pull/14501 ist , die auf 1.17.3 zurückportiert wurde. Ich arbeite an einem Fix.
WarrenWeckesser
am 25. Apr. 2020
Der vorgeschlagene Fix befindet sich unter https://github.com/numpy/numpy/pull/16076
WarrenWeckesser
am 25. Apr. 2020
Verwandte Themen
toddrjen
·
4Kommentare
manuels
·
3Kommentare
dmvianna
·
4Kommentare
thouis
·
4Kommentare
Foadsf
·
3Kommentare
Hilfreichster Kommentar
Das Problem liegt auch im Master:
Dies wurde wahrscheinlich in https://github.com/numpy/numpy/pull/14777 eingeführt. Ich werde einen Blick darauf werfen.