Articles : Numpy, extension C-Python pour le calcul scientifique
Posté par Nicolas (). Modéré le 14 novembre 2006.
Numpy est la nouvelle extension C-Python pour faire du calcul scientifique et de l'analyse de données. Cette extension a été développée par un grand nombre de personnes de la communauté Python mais il faut remercier Travis Oliphant qui a eu le courage d'être le principal acteur et le maître d'oeuvre de ce travail qui a rassemblé la communauté scientifique utilisant Python.
La suite dans l'article...
![[en]](../images/en.png)
numpy (682 hits)-
scipy (169 hits)
-
numarray (104 hits)
-
matplotlib (151 hits)
> Lire la dépêche (61 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #775007.
Run by 
Cette page a été générée par Templeet en 0.1146s (dont 0.0082 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Il faut informer la communauté scientifique
Tout est dans le titre : en pratique, dans la communauté scientifique, peu de monde connaît Python. On connaît surtout Matlab, le C, le fortran... Pourtant Python associé à numpy pourrait largement être utilisé dans les labos !
Et ça coûterait moins cher en licences Matlab :)
Je rappelle qu'il va y avoir un numéro spécial dans IEEE Education Magasine sur les logiciels Open Source : http://linuxfr.org/~jhillairet/23099.html
Une bonne occasion de communiquer !
[^]Re: Il faut informer la communauté scientifique
En opensource (certe avec une licence non reconnue par l'OSI à cause d'une clause peu dommageable pour les scientifiques), il existe aussi Scilab ( http://www.scilab.org/ ) qui remplace Matlab pour bon nombre d'utilisation ...
(disclosure : je participe à Scilab)
[^]Re: Il faut informer la communauté scientifique
tu pourrais aussi citer les autres projets quitte a faire du HS...
octave: http://www.gnu.org/software/octave/
yorick: http://yorick.sourceforge.net/index.php
pdl: http://pdl.sourceforge.net/WWW/
GDL: http://gnudatalanguage.sourceforge.net/
et il y en a probablement plein d'autre encore dans votre langage prefere...
En attendant pour ceux qui aime bien utiliser python dans le cadre scientifique, la sortie de numpy est importante.
[^]Re: Il faut informer la communauté scientifique
Une liste non exhaustive de logiciel de calcul scientifique sous diverses licences libres...
http://norma.mas.ecp.fr/wikimas/ScientificComputingSoftware
[^]Re: Il faut informer la communauté scientifique
une liste de liste ;-) :
http://cookerspot.tuxfamily.org/wikka.php?wakka=ProgramsScie(...)
vous pouvez en rajouter, c'est un wiki (suffit de s'inscrire).
Après ya un peu de rangement à faire pour sélectionner les programmes intéressants par domaine... (si seulement déjà une partie de ce qui est dispo en libre était déjà packagé pour les principales distribs).
[^]Re: Il faut informer la communauté scientifique
J'ai utilisé pas mal Matlab à l'école, puis dans les stages, boulots. Il y a quelques mois j'avais des données à traiter et pas de license Matlab. Je connaissais l'existence de Scilab et j'avais même fait 2-3 trucs avec, donc j'ai installé Scilab sous MS Windows avec cygwin (machine du boulot).
Rapidement j'ai reussi à faire à peu près ce que je voulais mais après un mois d'utilisation certains points restent négatifs :
*l'ouverture de gros fichiers de donnée (500000 entrées et plus dans un fichier tabulé) est vraiment beaucoup plus lente que sous Matlab
*le chargement de fichier wav est très limité et plus lent que Matlab
*la gestion des graphiques à partir des commandes est plus complexe et mal documentée
*impossible d'exporter les graphique en png. Dans un autre format (ps ou bmp?) les caractères mathématiques n'apparaissait pas correctement. J'ai fini par faire des capture d'écran.
*la doc. des fonction souvent un peu légère
*il n'y a pas de fonction equivalente à spectrum (Signal Processing Toolbox). Son intérêt est de balayer rapidement différentes méthodes d'estimation spectrale sur des signaux sans écrire de code.
Scilab est un logiciel intéressant (je l'ai installé sur mon PC perso) mais clairement pas aussi abouti que Matlab.
[^]Re: Il faut informer la communauté scientifique
Oui, il y a des choses perfectibles... C'est clair !
Ceci dit, pour tes questions de perfs, tu aurais du essayer avec la version Native Windows de Scilab. Tu aurais certainement obtenu de bien meilleures performances.
[^]Re: Il faut informer la communauté scientifique
Si les centres de recherche et les sociétés qui paient (cher) matlab mettaient une fois les mêmes moyens à payer des développeurs pour faire aboutir les fonctionnalités qui leurs manquent dans scilab... ça profiterais à tout le monde et il n'y aurais à payer qu'une seule fois pour autant de postes que l'on veut.
En attendant, MathWorks fait du bon boulot avec matlab et le vend (bien). Surtout qu'au produit de base, il faut ajouter les modules spécifiques dont on a besoin... ça ajoute rapidement au prix.
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: Il faut informer la communauté scientifique
On est en effet preneur d'aide ... :)
Mais pour défendre les sociétés et centres de recherche, il y a un consortium derrière Scilab qui mettent les moyens pour faire bouger ça...
[^]Re: Il faut informer la communauté scientifique
En effet, il existe aussi des produits d'autres éditeurs qui s'appuient sur Matlab. Par exemple Xilinx System Generator ( http://www.xilinx.com/ise/optional_prod/system_generator.htm ) qui permet de programmer un FPGA (génération, simulation, simulation sur cible...) à partir de l'environnement Simulink de Matlab. En gros sans connaissance en VHDL tu programmes ta carte FPGA. Je ne connais pas l'efficacité (optimisation) de cette méthode par rapport à du VHDL mais j'ai utilisé cet environnement en stage chez EADS et c'était plutôt satifaisant. C'est cher mais ça peu séduire.
Bref Matlab reste une référence dans l'industrie.
[^]Re: Il faut informer la communauté scientifique
> Si les centres de recherche et les sociétés qui paient (cher) matlab mettaient une fois les mêmes moyens à payer des développeurs pour faire aboutir les fonctionnalités qui leurs manquent dans scilab...
Peut-être (et ce n'est pas sûr) que ça avancerait plus vite si le logiciel étant sous une licence libre. Ça pourrait donner confiance aux entreprises et universités, les inciter plus à contribuer.
[^]Re: Il faut informer la communauté scientifique
J'espère que tu as raison mais je me pose la question quand même ...
La licence Scilab n'est certe pas reconnue par l'OSI, le point qui fait qu'elle ne l'est pas est quand même pas crutial ni bloquant pour beaucoup de gens même adeptes du logiciel libre (Interdiction de commercialiser une version modifiée de Scilab).
[^]Re: Il faut informer la communauté scientifique
Je crois qu'il faudrait bien que l'INRIA (dont je suis chercheur pour encore au moins un an ;-) se décide à arrêter le pipo sur Scilab. Un logiciel est libre ou ne l'est pas, point final. Plus les années passent et plus on se rend compte combien Stallman a été un génie visionnaire : les libertés du logiciel libre sont toutes utiles, chaque restriction à ces libertés est un problème. Par exemple, Scilab ne peut pas être "inclus" dans un logiciel commercial, point dont l'interprétation est extrêmement délicate.
Scilab a largement de quoi concurrencer Matlab, mais il a déjà perdu la bataille dans la communauté des statisticiens qui passe massivement à R qui lui est un vrai logiciel libre. Et pourtant, Scilab est plus vieux qu'R et plus complet dans certains domaines. Si l'INRIA s'obstine a ne pas comprendre les dégats que causent la présentation comme logiciel libre d'un logiciel qui ne l'est pas, Scilab risque de ne jamais avoir le succès qu'il mérite.
[^]Re: Il faut informer la communauté scientifique
Si c'était si simple que tu le laisse entendre [changer de licence d'un claquement de doigt] ... Ca serait bien ! :)
[^]Re: Il faut informer la communauté scientifique
Je ne doute pas de ta bonne foi, mais celle des responsables de la valorisation ne me semble pas si évidente. Cela fait quand même des années que cette licence pose problème. Quand on voit que Sun est capable de changer la licence de son OS et de Java en quelques mois, au pire un ou deux ans, on est en droit de se demander depuis combien de temps la valo de l'inria songe sérieusement à faire de scilab un logiciel libre.
[^]Re: Il faut informer la communauté scientifique
Un logiciel est libre ou ne l'est pas, point final.
comme s'il n'y avait qu'une définition de logiciel libre.
Windows has no users. It has hostages.
[+] [^]Recherche publique bridé
Je crois qu'il faut surtout arrêter le pipo de dire qu'un logiciel se développe sans moyen, sans structure politique et sans politique de communication. Regarde les moyens financiers, le nombre de développeurs et de commerciaux dans les boîtes comme Microscoft, Matlab. C'est une liberté d'action!
C'est la raison pour laquelle Root est passé de GPL en LGPL. Pourtant L'INRIA est proche de l'industrie. C'est un comble. As tu des explications sur ce point?L'INRIA reçoit ses budgets et dépend de l'état, il est donc évident qu'ils n'auront jamais les moyens et les statuts pour développer un logiciel "professionnel". Combien de temps et de démarches administratives pour ouvrir un poste, recevoir des budgets ... Le monde de la recherche est désespérant! Une réforme en vue?
Dans mon domaine, on utilise pas Scilab mais Root, un logiciel développé au CERN en LGPL par une poignée de pseudo ingénieurs en informatique (physiciens de formation). Il suffit de jeter un coup d'oeil dans les sources pour voir le désastre. Tu peux lire le code, mais tu n'en feras jamais rien. À la finale on se retrouve dans la même situation que Windows: ils s'auto-proclament les meilleurs, détiennent le monopole, et la qualité et le support est aussi mauvaise que Win 95. Je trouve aberrant qu'il n'y est même pas un fond de financement international sur ce projet. Au moins on aurait pu embaucher des ingénieurs compétents et en nombre suffisant dés le début.
Après 5 ans, je conclus que c'est un problème politique.
As tu déjà utilisé Matlab? L'interface, les modules externes et la documentation ne se compare pas. Les logiciels comme Matlab sont des logiciels "clé en main" destinés à des ingénieurs ou des techniciens. Il faut que les choses soit immédiate. Il y a beaucoup de travail pour y arriver.
Comme Ocaml? Lui est pourtant libre?
[^]Re: Recherche publique bridé
Pour une raison simple : historique ... mais ça va changer.
Juste pour l'anecdote, matlab et scilab ont les memes sources de bases (je parle meme pas des libs)... Les deux équipes bossaient ensemble au debut !
[^]Re: Recherche publique bridé
C'est la raison pour laquelle Root est passé de GPL en LGPL.
Mouhahahah ! ROOT en GPL !
Si tu pouvais me donner le lien vers la version de ROOT qui etait en GPL...
Pour info, ce n'est que lorsque ROOT est passe en LGPL (ROOT 5, et parce qu'il integrait du code sous LGPL et utilisait gccxml pour generer des dictionaires des classes C++ - pour l'introspection) qu'il a pu etre accepte pour etre distribue par Debian.
Un extrait de la license originale:
[^]Re: Il faut informer la communauté scientifique
Scilab n'est pas (actuellement) un logiciel libre ou un logiciel « open source » au sens OSI. Et les responsables du projet Scilab le savent très bien même s'ils continuent à communiquer en prétendant le contraire (conférences diverses, salons, etc.)...
Le passage sous une licence libre serait en cours (dixit le responsable du projet).
[^]Re: Il faut informer la communauté scientifique
Python associé à numpy pourrait largement être utilisé dans les labos
Avant que ça arrive il faudra arreter de reecrire Numeric/numarray/numpy tous les deux ans.. (et se pencher serieusement sur son integration comme module officiel de python)
Je regrette aussi qu'ils aient fait le choix très contestable de stocker les données suivant naturel des tableau "C" (lignes puis colonnes) par rapport aux tableaux fortran (colonnes puis lignes)
[^]Re: Il faut informer la communauté scientifique
A priori, cette fois-ci c'est la bonne, puisque Numeric et numarray semblent condamnés à disparaitre. Ceci dit c'est vrai que les modules scientifiques de python ont tendances à s'éparpiller. :
Le vrai manque pour atteindre l'objectif de domination mondiale, a mon avis, c'est une bonne intégration numpy/bibliothèque de fonctions/bibliothèque de tracé/interface de développement ainsi qu'une bonne documentation avec pleins d'exemples commentés.
Pour la bibliothèque de fonctions, il y a scipy (qui semble se détacher du lot), pygsl l'interface à la gnu scientific library, peut être scientific python (que je ne connait pas)
Pour la bibliothèque de tracé, matplotlib est pas mal et facile d'utilisation mais peut être un peu limité (la 3D est encore très basique). Il y a plusieurs autres bibliothèques mais de j'ai ce que j'ai pu voir rien de super top (mais j'ai pas forcément eu le temps de bien tester).
Pour l'interface, Ipython est un must, mais il faudrait peut être quelque chose de plus graphique aussi.
Il y a aussi les performances par rapport à des outils comme IDL ou Matlab a analyser (je n'ai jamais vu de benchmark).
[^]Re: Il faut informer la communauté scientifique
En fait, je crois qu'ils ne réécrive pas Numeric, numarray, numpy tous les deux ans. Par contre, ils n'arrètent pas de changer de nom et ça c'est assez génant je trouve.
En récapitulant doucement, c'est assez simple:
* Numeric : première implémentation performante d'un objet de type array.
* numarray: une autre implémentation d'un array, apparue peu après Numeric.
* NumPy: l'implémentation actuelle d'un array, qui remplace les deux précédentes. Au début, NumPy s'appellait "Scipy core".
* SciPy: un ensemble d'outils pour faire du calcul numérique. Utilise NumPy pour représenter les array.
Je pense qu'ils auraient au moins du garder le nom scipy core, je trouve ça plus explicite.
Pour le stockage en ligne ou colonne, je n'ai pas d'avis, mais il y a peut-être un spécialiste dans la salle?
[^]Re: Il faut informer la communauté scientifique
>Pour le stockage en ligne ou colonne, je n'ai pas d'avis, mais il y a peut-être un spécialiste dans la salle?
Pas moi, mais j'ai lu que c'était pour des question de performances. Numpy étant écrit en C, ils ont gardés l'ordre d'indexation du C.
[^]Re: Il faut informer la communauté scientifique
j'ai du mal à comprendre le problème ligne-colonne... Il ne s'agit que d'un formalisme purement intellectuel et nullement imposé par les langages. Les C/C++/autre n'ont tout au plus qu'une vision dimensionnelle des tableaux :
float tableau[ dim0 ][ dim1 ]...[ dimN ];
Après, que la représentation anglosaxonne des matrices dise dim0 est pour les colonnes et dim1 pour les lignes et que la représentation internationale dise le contraire... c'est bonnet blanc et blanc bonnet :)
Bref, c'est le(s) développeur(s) qui impose(nt) le mode de représentation des données.
mes 2¢
[^]Re: Il faut informer la communauté scientifique
disons que pour les informaticiens cela ne gene pas beaucoup mais lorsque tu fais des maths et que tu dois coder un truc en faisant systematiquement une gymnastique pour inverse les lignes et colonnes car la representation mathematique est a l'inverse de celle classique du C, c'est chiant. C'est pas infaisable c'est juste chiant et force a faire 42 000 verifications entre le papier et le soft.
En math m(i,j), en fortran m(i,j), en C/python m(j,i)
[^]Re: Il faut informer la communauté scientifique
Houla!!
Je t'arrêtes tout de suite, ce n'est pas de cela qu'il s'agit. En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
Par contre en mémoire, la matrice
[[1, 2, 3]
[4, 5, 6]]
sera stockée ainsi en Fortran/Matlab (stockage colonne):
1-4-2-5-3-6
mais en C/Python, elle sera stockée ainsi (stockage ligne):
1-2-3-4-5-6
Cela a une incidence pour savoir quel indice (de ligne ou colonne) va le plus vite. Je ne sais pas si les performances globales changent.
[^]Re: Il faut informer la communauté scientifique
Ben essaye tu vas bien voir:
http://www.stsci.edu/resources/software_hardware/numarray/id(...)
Puis pour les coup des indices va donc voir cette page, le truc en gras en plein mileu... (IDL et Fortran ont le meme style de notation)
Je suis desole mais si tu as une matrice:
a = numpy.array(range(1,10)).reshape(3,3)
ca donne:
array([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]])
et:
a[:,0]
Out[4]: array([1, 4, 7])
pour la matrice,
en fortran declare ta matrice:
a = reshape((/(i, i=1,9)/),(/3,3/))
print*, a(:,1)
./a.out
1. 2. 3.
Pas exactement le meme resultat non?
comme tu peux le voir les colonnes et les matrices sont inverses. La notation classique mathematique n'est pas la meme et si tu veux avoir un truc classique math tu transposes en python. Certes cela a avoir avec un truc d'indice qui varie plus vite mais il n'empeche que dans la pratique c'est inverse.
[^]Re: Il faut informer la communauté scientifique
autant pour moi, je pensais qu'en fortran c'était comme en matlab.
Pour ce qui est de matlab/octave/scilab, là je suis sur de moi, c'est pareil qu'en python.
Pour les mathématiques, ben je suppose que ça dépend des écoles, mais pendant toute ma scolarité, c'était comme ça aussi.
Il semble donc que le fortran est à contre courant, ce qui confirme sa réputation de langage à la syntaxe pourrie...
[^]Re: Il faut informer la communauté scientifique
euh la je t'arrete tout de suite le fortran 90 n'a absolument pas une syntaxe toute pourrie et cela m'etonnerait bien que tu ecrives un matrice a la facon C dans un cours de math pour mathematiciens...
Sans vouloir polemiquer la syntaxe pour les tableaux en fortran est la plus naturelle pour les mathematiciens et physiciens pour la simple est bonne raison que ce langage a ete ecrit pour eux (Fortran == formula translator)
et par exemple regarde sur cette page:
http://www.les-mathematiques.net/b/c/j/node8.php3
tu verras que les indices matricielles sont numerotes comme en fortran... avec le premier indice representant les lignes et le deuxieme les colonnes et j'ai comme un doute que cette convention est change en math.
[^]Re: Il faut informer la communauté scientifique
Ok, je ne connais pas bien fortran, et je ne sais pas pourquoi tu tiens tellement à ce que je dise des choses pas vraies, mais comme je te l'ai déjà dis plus haut:
En math, en Matlab, et en Python, on écrit toujours
a(i,j) pour désigner l'indice situé sur la (i)ième ligne et la (j)ième colonne.
C'est exactement ce que tu viens d'affirmer en disant que j'avais tord.
Alors relis tout, et calme toi.
En attendant, je le dis et je le répete, quand en math tu as une matrice qui s'écrit:
a=[[1 2 3]
[4 5 6]
[7 8 9]]
Alors, en python comme en matlab comme en math (et apparement fortran d'après ce que tu viens de dire), tu as:
a[:,j] : colonne j de la matrice a
a[i,:] : ligne i de la matrice a
Maintenant si tu t'y perd, je ne peut rien pour toi...
[^]Re: Il faut informer la communauté scientifique
En fonction du formalisme utilisé, le langage stocke les données d'une certaine façon. Et ceci peut avoir un impact très important sur les accès mémoires (est-ce qu'on traite une série de données continues en mémoire, ou bien est-ce qu'on va tapper à gauche ou à droite avec tout plein de défauts de page).
(pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)
[^]Re: Il faut informer la communauté scientifique
Si tu avais lu un peu la news et les liens tu aurais constate que justement Numeric et numarray sont tous 2 quasi abandonne. Le premier totalement, le second tant que le STSCI n'as pas passe tous ses softs sur numpy, ce qui est en cours. Sachant que STSCI est le concepteur de numarray, une fois que la transition aura etait faite numarray ne sera plus maintenu. De plus si tu regardes dans scipy tu verras qu'il existe maintenant un module officiel STSCI pour le traitement d'image s'appyant sur numpy. Ils attendaient le passage de numpy en 1.0 pour passer les gros soft dessus (pour info il y a eu pas mal de cassage d'API pendant la mise au point).
Je regrette aussi qu'ils aient fait le choix très contestable de stocker les données suivant naturel des tableau "C" (lignes puis colonnes) par rapport aux tableaux fortran (colonnes puis lignes)
Je suis d'accord c'est un truc qui m'a toujours gene mais c'est plus pour garder la compatibilite avec les liste python qu'autre chose. Avec numpy tu peux tout a fait traiter tes tableaux comme etant Fortran contigu (cf la doc)
[^]Re: Il faut informer la communauté scientifique
« Python associé à numpy pourrait largement être utilisé dans les labos »
Je dirais même plus, Python associé à :
- ipython : la console interactive avec auto-completion, affichage rapide des variables et de la doc
- Matplot : permet de générer facilement de beau graphique. Et intégré dans désigner, on peut facilement généer de bennes GUI comme avec matlab : http://www.scipy.org/Wiki/Cookbook/Matplotlib/Qt_with_IPytho(...)
- une communauté libre qui permet de communiquer autour des applis et bibliothèques : http://www.scipy.org/Topical_Software
Tout me semble réunit pour que ça mérite d'être évalué, mais ça prend pas facilement ...