Pourquoi np.add.at () renvoie-t-il la mauvaise réponse pour les grands tableaux?

Je suppose que je ne pouvais pas l'exécuter, mais cela pourrait-il être un problème que vous dépassiez la valeur entière maximale en python pour la dernière option? Ie dépasse 2147483647. Utilisez plutôt le type longinteger comme indiqué ci-dessous.

En référence à: [entrez la description du lien ici] [1] https://docs.python.org/2.0/ref/integers.html

J'espère que cela t'aides. S'il vous plaît laissez-moi savoir si cela fonctionne.

Cela est probablement dû à une précision entière. Si vous jouez avec le type de données numpy (par exemple, vous le contraignez à une valeur (non signée) entre 0 et 255) en définissant uint8 , vous verrez que les ratios commencent déjà à diminuer pour le deuxième tableau. Je n'ai pas assez de mémoire pour le tester, mais définir tous les dtypes sur uint64 comme ci-dessous devrait aider:

def check_add(N):
    N = int(N)
    out = np.zeros(N,dtype='uint8')
    np.add.at(out, np.arange(N,dtype='uint8'), 1)
    return np.sum(out)/N

n_arr = [1E1, 1E3, 1E5,65536, 1E7]
for n in n_arr:
    print('N = {} (log(N) = {}); output ratio is {}'.format(n, np.log10(n), check_add(n)))

Pour comprendre le comportement, je recommande de définir dtype='uint8' et de vérifier le comportement pour les petits N. Donc, ce qui se passe, c'est que la fonction np.arange crée des entiers ascendants pour les éléments vectoriels jusqu'à ce qu'il atteigne la limite entière. Il recommence alors à 0 et compte à nouveau, donc au début (Ns plus petits) vous obtenez la somme correcte (bien que votre vecteur out contienne beaucoup d'éléments> 1 dans les positions 0: limite et beaucoup d'éléments = 0 au-delà du limite). Si toutefois vous choisissez N assez grand, les éléments de votre vecteur de out commencent à dépasser la limite entière et recommencent à partir de 0. Dès que cela se produit, votre somme est largement désactivée. Pour revérifier, sachez que la limite uint8 est de 255 (256 entiers) et 256 ^ 2 = 65536. Définissez N = 65536 avec dtype='uint8' et check_add(65536) renverra 0.

importer numpy comme np

def check_add(N):
    N = int(N)
    out = np.zeros(N,dtype='uint64')
    np.add.at(out, np.arange(N,dtype='uint64'), 1)
    return np.sum(out)/N

Notez également que vous n'avez pas besoin du vecteur np.ones mais que vous pouvez simplement le remplacer par 1, si tout ce qui vous intéresse est d'incrémenter uniformément tout de 1.

Vous int32 :

1E10 % (np.iinfo(np.int32).max - np.iinfo(np.int32).min + 1)  # + 1 for 0
Out[]: 1410065408

Il y a votre numéro étrange (googler ce numéro m'a en fait amené ici, c'est ainsi que j'ai compris cela.)

Maintenant, ce qui se passe dans votre fonction est un peu plus étrange. D'après la documentation de ufunc.at vous devriez simplement accumuler en ajoutant les 1 valeurs des indices inférieurs à np.iinfo(np.int32).max et les indices négatifs au-dessus de np.iinfo(np.int32).min - mais il semble que 1) travaille à l'envers et 2) s'arrête quand il arrive au dernier débordement. Sans creuser dans le code c , je ne pourrais pas vous dire pourquoi, mais c'est probablement une bonne chose que cela fasse - votre fonction échouerait silencieusement et avec le "correct" moyen si elle avait fait les choses de cette façon, tout en corrompant vos résultats (avoir 2 ou 3 dans ces indices et 0 au milieu).

Il s'agit d'un vieux bogue, numéro 13286 de NumPy . ufunc.at utilisait une variable trop petite pour le compteur de boucles. Il a été corrigé il y a quelque temps, alors mettez à jour votre NumPy. (Le correctif est présent dans la version 1.16.3 et les versions ultérieures.)