Discussion :

[sir_nebuchadnezzar]

Bonjour à toutes et à tous,

Numpy et sa fonction vstack me pose décidément beaucoup de problèmes... En voilà encore un qui s'ajoute...

J'explique :

J'ai écrit un script python qui lit des fichiers Excel avec la génialissime bibliothèque xlrd. J'ajoute chaque ligne à un tableau virtuel (en réorganisant ces données), ce tableau ayant les dimensions suivantes à la fin de la lecture: 13 844 lignes et 313 colonnes.

J'effectue ensuite des opérations dans ce tableau et je duplique certaines valeurs. J'écris alors un nouveau tableau de dimentions : 13 844 lignes et 3 744 colonnes. Et c'est dans cette étape que je me retrouve avec une erreur qui est la suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    execfile("A_HYBRIDE_3.4.py")
  File "A_HYBRIDE_3.4.py", line 1551, in <module>
    K1 = np.vstack((K1, duplication))
  File "C:\Python26\lib\site-packages\numpy\core\shape_base.py", line 226, in vstack
    return _nx.concatenate(map(atleast_2d,tup),0)
MemoryError

Pourtant ma ram est à 1.32 Go et je dispose de 2 Go sur mon poste...
Il y a-t-il une limitation de taille dans les tableaux numpy au format array ?

Cela ne vient pas du code car j'ai déjà essayé avec des données moins volumineuse et cela a fonctionné...

Je vous remercie beaucoup de vos réponses.

Je n'ai pas posté le script car je n'en vois pas l'utilité directe mais je peux le faire si ça peut aider certains à m'aider

[wiztricks]

Salut,

La capacité RAM de votre poste de travail a des effets sur les performances: il y aura un stock plus ou moins important pour satisfaire le besoins des applications.

Pour les applications, ce qui compte est la capacité maximale de l'espace virtuel adressable (VM): un environnement 32 bit offrira 1 à 2Go, les environnements 64 bits seront plus généreux (mais pas forcément linéaires).

A côté de la capacité totale, il faut aussi considérer la fragmentation de la VM. 13444 * 3744 ~50MB multiplié par la taille des cellules un int ~4 donne 200MB. Trouver un trou de 200MB pour créer un grand tableau lorsque l'espace utilisable est 1Go sera plus difficile que s'il est 1TB.

Allez vers un Python 64 bits sur un OS 64 bits... ou revoir l'algorithme pour qu'il s'accommode d'une VM 32 bits? Voilà peut être la bonne question à se poser.

- W

[sir_nebuchadnezzar]

Merci de ta réponse wiztricks,

Donc si je comprends bien, le fait d'ajouter de la mémoire RAM sur mon poste ne réglera pas mon problème...

Puisque tu as l'air de t'y connaitre en capacité de données et de mémoire, je voulais savoir si le fait de stocker les données en format str() prend plus de mémoire que l'int() ?

Est-ce que le fait d'utiliser Numpy en mode array, en mode matrix, ou même utiliser des listes de listes me ferait revenir au même problème ?

Est ce que la limitation provient des objets en eux mêmes (limite VM = taille limite d'un objet) ou plutôt de la taille limite total de la VM (limite VM = somme des tailles des objets) ?

Merci de ta réponse encore...

Faut que je trouve une solution !

[wiztricks]

Donc si je comprends bien, le fait d'ajouter de la mémoire RAM sur mon poste ne réglera pas mon problème...

Ca pourra améliorer les performances. Mais passer en 64 bits change la donne côté espace d'adressage pour les applications.

Puisque tu as l'air de t'y connaitre en capacité de données et de mémoire, je voulais savoir si le fait de stocker les données en format str() prend plus de mémoire que l'int() ?

Je ne sais pas comment sont stockées ces données côté Python. Mais en dessous de Python, il y a du C et en C un "int" occupe 4 bytes.
Pour les str(), en 2.6 un caractère occupe un byte => ça dépendra de la longueur de la chaine de caractères
En 3.x, un str est unicode et un caractère occupera 2 ou 4 bytes.

Est ce que la limitation provient des objets en eux mêmes (limite VM = taille limite d'un objet) ou plutôt de la taille limite total de la VM (limite VM = somme des tailles des objets) ?

Les 3.
1 - taille brûte: 13444 * 3744 ~50MB * 4 bytes => 200 MB
2 - ajoutez y les informations pour gérer la chose => 300-500 MB
3 - est-ce que Numpy voudra un espace contigu (un gros trou) ou sera capable de répartir un tableau dans un espace non contigu? Comme la création d'un tableau contigu est explicite .ascontiguous array, on peut supposer qu'il est capable de créer la chose dans des trous.
- W

[sir_nebuchadnezzar]

Bonjour, merci pour ta réponse.

Je fais tourner mon script sur une machine 64 bits en ce moment. J'espère en tirer toute satisfaction ! Sinon, je vais devoir revoir mon code .

Arg, c'est navrant de devoir le faire. C'est quand même étonnant d'arriver aux limites de la machines avec des données assez "maigres" finalement.

Ah, cela vient de se terminer avec la machine 64 bits. Même constat, 1/3 des données réalisées et ca plante à cause d'une infortune MemoryError...

Est ce qu'utiliser des listes de liste, et pas Numpy serait plus judicieux ? Je ne sais pas, peut être que l'architecture qu'utilise Numpy est très demandeuse de VM ?

Merci de votre préciseuse aide !

[wiztricks]

Salut,

Je fais tourner mon script sur une machine 64 bits en ce moment. J'espère en tirer toute satisfaction ! Sinon, je vais devoir revoir mon code

Vous avez aussi installé un Python 64 bits?
- W

[sir_nebuchadnezzar]

Bon après avoir récupéré une machine 64 bits et avoir retouché mon code pour que le tableau stocke la donnée sous forme de int() quand il peut au lieu de str(), j'arrive à mes fins.

Mon script tourne jusqu'au bout et cela sans MemoryError. Merci wiztricks !
Je monte à plus de 1.9 Go de VM sur pythonw et ca fait des gros triangles !

En conclusion : Si MemoryError

Machine plus puissante + réduction de la taille des éléments stockés =