J'essaie de générer des valeurs entières aléatoires de 64 bits pour des entiers et des flotteurs à l'aide de NUMPY, mais si j'essaie d'utiliser ceci pour des nombres 64 bits, je reçois p> De même, pour les entiers, je peux générer avec succès des entiers de 32 bits aléatoires: p> mais je suis infructueux pour les entiers 64 bits: P> In [5]: np.random.random_integers(np.iinfo(np.int64).min,high=np.iinfo(np.int64).max,size=10)
---------------------------------------------------------------------------
OverflowError Traceback (most recent call last)
/Users/tom/tmp/<ipython console> in <module>()
/Library/Python/2.6/site-packages/numpy/random/mtrand.so in mtrand.RandomState.random_integers (numpy/random/mtrand/mtrand.c:6640)()
/Library/Python/2.6/site-packages/numpy/random/mtrand.so in mtrand.RandomState.randint (numpy/random/mtrand/mtrand.c:5813)()
OverflowError: long int too large to convert to int
5 Réponses :
Le problème semble être que le Selon Ticket # 555 Les graines aléatoires peuvent maintenant être 64 bits à partir de Version 1.1.0 Je vous suggère de télécharger et d'installer la dernière version de Numpy de ici . aléatoire_numbers ne prévoit que des entiers 32 bits.
Quelle version dit-il que c'est?
np .__ version__ donne 1.4.0.Dev7539
Peut-être devriez-vous essayer d'utiliser une libération plus stable? Le ticket a simplement parlé d'ensemencement au nombre aléatoire avec 64 bits, peut-être que sa référence à un générateur de nombres aléatoires différent.
Pour les entiers, vous pouvez générer 2 numéros aléatoires 32 bits et les combiner:
a + (b << 32)
Le générateur peut être biaisé. avec des générateurs cycliques, a => b.
@ B.m. Pourquoi voyez-vous que cela peut être biaisé? Y a-t-il un moyen de surmonter le biais?
Il semblerait que le code pour Les entiers distribués uniformément sont faciles à générer comme indiqué. Les nombres de points flottants uniformément distribués nécessiteraient une pensée plutôt plus prudente.
Quant à signaler ces bizarreries sous forme de bogues, je pense que vous devriez faire ou poster un message à la liste de diffusion de projet. De cette façon, vous découvrirez au moins ce que les développeurs pensent être un comportement raisonnable. numpy.random.uniforme () est un calcul élevé à un moment donné, et l'INF découle de là.
Je ne crois pas que cela fait référence à l'appel de semences aléatoires. Le code le plus simple que j'ai obtenu cela tombe dans "Python int trop grand pour convertir en C long" est le suivant:
x = numpy.random.random_integers(2**64,size=(SIZE,)).astype(numpy.uint64)
np.random.random_integers est obsolète, utilisez np.random.randint (2 ** 64, DTYPE = np.uint64)
Je me rends compte que c'est une très ancienne question, mais il existe une nouvelle réponse dans Python 3.6.3 :
Avez-vous pu résoudre ça à la fin?