Numpy, extension C-Python pour le calcul scientifique

Posté par . Modéré par Nÿco.
Tags : aucun
1
14
nov.
2006
Python
Après 18 mois de gestation, je suis heureux de vous annoncer la naissance du petit numpy qui bientôt deviendra grand.

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... Jusqu'à il y a quelques jours, l'utilisation de python par les scientifiques était limitée par le fait que deux extensions existaient, Numeric écrit par Paul Dubois, très rapide pour les petits calculs et numarray développé par le centre d'étude du télescope spatial et optimisé pour le traitement d'image.

Numpy est une réécriture totale de Numeric qui englobe les avantages de numarray et plus. Un effort tout particulier a été porté pour le calcul à multi-dimensions et a abouti à un objet N-dimension (ndarray) pour permettre de faire des calculs rapides et simplement. D'autre objets tels que les matrices, les ensembles de caractères et un objet pour ranger les données. Tout autour, des fonctions mathématiques très rapides ont été rajoutées ainsi que la possibilité d'appeler des fonctions en Fortran et donc de profiter de toutes la bibliothèque scientifique existante dans ce langage.

Le développement et le support de Numeric a été officiellement arrêté et celui de numarray le sera l'année prochaine, une fois que l'ensemble des programmes du STSCI (Space Telescope Science Institute) seront portés sur le nouveau module.

La bibliothèque scientifique scipy a été presque entièrement portée sur numpy et les extensions pour le traitement d'image provenant du STSCI ont été incluses.

Des logiciels, tel que matplotlib, utilisent déjà numpy par défaut.

Il est temps de regarder le python comme une bonne alternative pour l'analyse de données scientifiques. Tous les outils sont là pour arriver bientôt a concurrencer Matplab et IDL. Il suffit juste d'éduquer les étudiants à ces outils.
  • # Il faut informer la communauté scientifique

    Posté par (page perso) . Évalué à 7.

    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

      Posté par (page perso) . Évalué à 5.

      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)
      • [^] # Commentaire supprimé

        Posté par . Évalué à 4.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Il faut informer la communauté scientifique

        Posté par . Évalué à 7.

        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

          Posté par (page perso) . Évalué à 7.

          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

          Posté par (page perso) . Évalué à 5.

          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.
          • [^] # Re: Il faut informer la communauté scientifique

            Posté par (page perso) . Évalué à 1.

            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

            Posté par . Évalué à 1.

            Surtout qu'au produit de base, il faut ajouter les modules spécifiques dont on a besoin



            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

            Posté par (page perso) . Évalué à 8.

            > 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

              Posté par (page perso) . Évalué à 2.

              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

                Posté par (page perso) . Évalué à 7.

                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

                  Posté par (page perso) . Évalué à 3.

                  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

                    Posté par (page perso) . Évalué à 5.

                    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

                  Posté par . Évalué à 1.

                  Un logiciel est libre ou ne l'est pas, point final.

                  comme s'il n'y avait qu'une définition de logiciel libre.
                • [^] # Recherche publique bridé

                  Posté par . Évalué à -1.

                  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!

                  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.

                  Scilab ne peut pas être "inclus" dans un logiciel commercial
                  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?

                  Scilab a largement de quoi concurrencer Matlab
                  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.

                  Scilab risque de ne jamais avoir le succès qu'il mérite
                  Comme Ocaml? Lui est pourtant libre?
                  • [^] # Re: Recherche publique bridé

                    Posté par (page perso) . Évalué à 1.

                    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?

                    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é

                    Posté par . Évalué à 2.

                    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:

                    Additionally, the authors grant
                    permission to modify this software and its documentation for any purpose,
                    provided that such modifications are not distributed without the explicit
                    consent of the authors and that existing copyright notices are retained in
                    all copies.
      • [^] # Re: Il faut informer la communauté scientifique

        Posté par (page perso) . Évalué à 5.

        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

      Posté par (page perso) . Évalué à 1.

      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

        Posté par . Évalué à 2.

        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

        Posté par . Évalué à 2.

        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

          Posté par . Évalué à 2.

          >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

            Posté par (page perso) . Évalué à 2.

            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¢
            • [^] # Commentaire supprimé

              Posté par . Évalué à 2.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Il faut informer la communauté scientifique

                Posté par . Évalué à 3.

                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.
                • [^] # Commentaire supprimé

                  Posté par . Évalué à 1.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Il faut informer la communauté scientifique

                    Posté par . Évalué à 2.

                    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...
                    • [^] # Commentaire supprimé

                      Posté par . Évalué à 2.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Il faut informer la communauté scientifique

                        Posté par . Évalué à 4.

                        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

              Posté par (page perso) . Évalué à 2.

              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).
      • [^] # Commentaire supprimé

        Posté par . Évalué à 2.

        Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Il faut informer la communauté scientifique

      Posté par (page perso) . Évalué à 1.

      « 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 ...
  • # Pyrex, psyco

    Posté par . Évalué à 3.

    Pour l'optimisation de code calculatoire en Python, il serait bon de mentionner aussi Pyrex et Psyco.
    Pyrex permet de mélanger code Python et code natif, dans un dialecte de Python un peu spécial :
    http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
    Psyco est un module d'extension qui permet de faire de la compilation "à la volée" (JIT), de façon transparente :
    http://psyco.sourceforge.net/
  • # benchs/ tests

    Posté par (page perso) . Évalué à 2.

    Je traine assez souvent avec des gens qui font du calcul scientifique, et le truc qui revient (je trouve), c'est:
    * matlab, parcequ'en 2 commandes ça fait presque tout, mais c'est "lent"
    * C++/C parceque c'est "rapide", mais il faut une certaine rigueur pour éviter les fuites, éviter les segfault, faire une bonne gestion d'erreur,...

    Forcément, si on prend 2 programmes du même niveau de programmation (les chercheurs ne sont pas tous de bons codeurs), un truc en python va être loin derrière le C++ niveau perf. Maintenant, est-ce qu'en utilisant NumPy on rattrape ça ? J'aurais bien aimé avoir un tableau avec des chiffres pour me faire une idée... Quelqu'un a déjà vu ça ?
    • [^] # Re: benchs/ tests

      Posté par . Évalué à 2.

      J'utilise Python pour le calcul numérique depuis pas très longtemps, mais pour les perfs, il n'y a vraiment aucun souci par rapport à Matlab.

      Par contre, dire que Matlab, c'est lent par rapport à du C/C++, c'est un peu poussé je trouve. En écrivant correctement le code Matlab, tu peux presque tout vectoriser donc ça quand même très vite. Par contre, si tu as beaucoup de conditions ou de tests de variables, ça peu vite chuter.

      L'avantage de python par rapport à Matlab, c'est qu'on a un fonctionnement par référence, ce qui évite les copies inutiles des objets. Au début, c'est un peu déroutant, parce que quand on écrit:
      b = a[:,1]
      b est juste une référence à une partie de a, donc en modifiant b, on modifie a, mais l'avantage c'est qu'on évite de dupliquer inutilement des données, ce qui peut parfois être très rentable en temps de calcul.
      Evidemment, on peut copier explicitement un objet.

      Un gros avantage de Python est aussi que l'on peut écrire du code propre et réutilisable plus facilement qu'avec Matlab (à mon avis). En plus, on peut documenter son code proprement avec epydoc.
      • [^] # Re: benchs/ tests

        Posté par . Évalué à 2.

        >Un gros avantage de Python est aussi que l'on peut écrire du code propre et >réutilisable plus facilement qu'avec Matlab (à mon avis). En plus, on peut >documenter son code proprement avec epydoc.

        Un autre gros avantage, je pense, c'est la possibilité d'utiliser un tas de modules sans rapport avec la science, comme par exemple compresser en zip les résultats d'une analyse, puis les envoyer via ftp. Bon ce cas particulier est peut être faisable en matlab ou autre, mais l'idée est là.
      • [^] # Re: benchs/ tests

        Posté par (page perso) . Évalué à 1.

        moi je suis pas du domaine, je rapporte seulement ce que les utilisateurs me disent. Souvent, c'est:
        * on code un truc en matlab pour voir si ça marche sur de petites bases de données
        * si ça marche, on code le truc en C++ et on laisse mouliner plusieurs jours

        J'imagine que ça dépend aussi beaucoup du type de calcul. Si ton truc en matlab prend 1min a s'executer, c'est humain et le passage à quelquechose de plus "rapide" n'est pas forcément justifié. Là il s'agit de plusieurs jours de calculs sur des trucs qui font plusieurs Go. Et il faut pas oublier que les gens en questions ne sont pas des développeurs. S'il faut faire des siouxeries pour que ton matlab il trace, je doute que ça soit fait... En tout cas, je doute que python tel quel soit utilisable dans les cas que je connais...
        • [^] # Re: benchs/ tests

          Posté par . Évalué à 1.

          Effectivement, pour ce genre d'application, on peut dire Matlab/Scilab/Scipy/etc ne sont pas forcément très adaptés.
          Je crois qu'un grand sage a dit: " Il ne faut pas utiliser un marteau pilon pour enfoncer un clou, ni un pèse-personne pour peser un éléphant " (ou alors c'est de moi...)
          • [^] # Re: benchs/ tests

            Posté par (page perso) . Évalué à 1.

            ouai, enfin tu avouera quand même que ce genre de remarque ne fait pas avancer la chose... Ma question était là pour avoir une idée de la distance entre ce qu'on peut attendre de ce module python et d'un truc en C++.
            • [^] # Re: benchs/ tests

              Posté par . Évalué à 2.

              Excuse-moi je ne voulais pas être désagréable.
              En fait je pense que l'avantage avec python c'est qu'on peut faire la transition de manière assez douce.
              Je m'explique:
              Python s'interface assez facilement avec des librairies écrites en C/C++/Fortran, par conséquent on peut toujours écrire les parties "critiques" du code dans un langage performant et utiliser python pour faire l'import export de données, etc. On bénéficie alors des avantages des deux approches.
              Je te conseille le livre "python scripting for computational science" qui permet de bien comprendre l'intérêt d'utiliser python pour le calcul scientifique. On peut le trouver en PDF sur internet.

              Maintenant, pour ce qui est des performances de ce module python en particulier, ça doit dépendre énormément des algorithmes utilisés dans l'application. En effet, il n'y a a priori pas de différence entre un code écrit en C effectuant une multiplication de matrices et un code Python qui appelle une librairie écrite en C pour faire la multiplication des matrices (enfin je crois!).
        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: benchs/ tests

        Posté par (page perso) . Évalué à 0.

        Ici j'utilise Octave (plus les toolboxes de traitement de l'image dans octave-forge)
        compilé en 64 bits pour adresser plus de 2go.
        Pour la vitesse, j'essaye d'abord de bien vectoriser le code, et s'il ya encore un problème, j'ecris le code gourmand en c/C++ puis je fais appel à cette fonction dans le script octave. Ca semble efficace...

        C'est curieux ce que tu ecris sur le fonctionnement par réfénce. Pourquoi n'est pas ce pas utilisé dans matlab par ex?
      • [^] # Re: benchs/ tests

        Posté par (page perso) . Évalué à 2.

        Ici j'utilise Octave (plus les toolboxes de traitement de l'image dans octave-forge)
        compilé en 64 bits pour adresser plus de 2go.
        Pour la vitesse, j'essaye d'abord de bien vectoriser le code, et s'il ya encore un problème, j'ecris le code gourmand en c/C++ puis je fais appel à cette fonction dans le script octave. Ca semble efficace...

        C'est curieux ce que tu ecris sur le fonctionnement par réfénce. Pourquoi n'est pas ce pas utilisé dans matlab par ex?
        • [^] # Re: benchs/ tests

          Posté par . Évalué à 2.

          Pour le fonctionnement par référence ou par copie, il me semble que c'est essentiellement une question de génération. En fait, pratiquement tous les langages récents fonctionnent par référence, tandis que les langages plus anciens utilisent la copie. D'autres langages utilisent un peu les deux (les pointeurs en C permettent de faire la même chose).

          Je pense que ça n'est pas utilisé dans matlab parce que ça change vraiment beaucoup la façon d'écrire les programmes, et puis aussi parce que personne n'en parle.

          Dans le même ordre d'idée, matlab devient de plus en plus limité par le fait qu'il est fait pour une programmation procédurale. Il est par conséquent assez difficile de faire des programmes vraiment réutilisables, pourtant, la syntaxe ne change pas...
    • [^] # Re: benchs/ tests

      Posté par (page perso) . Évalué à 2.

      Matlab c'est lent pour la simple est bonne raison que ce bousin n'est pas multi thread.
      Donc meme sur un quadri opteron dual core, ça tourne sur un seule proc :/ Je suis preneur de solution si il y en a...
      Dans le labo ou je suis, j'ai vu Matlab tourner pendant 2 semaines d'affilé avant de fournir un résultat !!

      Au prix ou c'est vendu, ya de l'abus.

      Pour remplacer Matlab, il y a Octave.
      http://www.gnu.org/software/octave/
      • [^] # Re: benchs/ tests

        Posté par . Évalué à 1.

        Je confirme, Matlab est vraiment très lent...
        J'ai testé sous Windows l'an dernier pour des cours, et rien que l'éditeur de texte lague sur mon portable @800MHz (en mode économie d'énergie sur batterie).

        En plus je trouve ça inadmissible qu'un logiciel si cher prenne 70Mo de mémoire au démarrage, et plus de 100 après 2-3 petites multiplications de matrices 512x512...
        Sans oublier la politique de licences éducations pourrie...

        Heureusement dans mon école c'est Scilab only maintenant.

        Enfin je n'ai pas encore testé Scilab.
        Quelqu'un sait si les boucles sont aussi lentes que sous Matlab ? Parce que le langage est interprété très très lentement avec Matlab...


        Pour en revenir à Python je pense que ça peut vraiment être plus performant que Matlab, su fait que le langage est beaucoup plus rapide, et du fait de la richesse des bibliothèques autour. Pour en avoir parlé avec un thésard, le gros plus est de pouvoir écrire tout ce qui est périphérique de façon très simple, et de prototyper très vite.
        • [^] # Re: benchs/ tests

          Posté par . Évalué à 2.

          Scilab et Matlab c'est équivalent au niveau des performances et de l'utilisation mémoire. D'ailleurs, pour les 70 Mo ben je sais pas comment tu as eu ces chiffres mais pour moi ça serait plutôt 10Mo.

          Pour les boucles, c'est toujours aussi lent car le code est interprété, et c'est le même problème sous Octave, Scilab, Python, etc.

          Pour optimiser les performances, il faut écrire les opérations sous forme matricielle au maximum. C'est une gymnastique un peu difficile au début, mais ça fini par devenir un réflexe.
          En gros, il ne faut pas écrire:
          for i = 1:length(a)
          c(i) = a(i)*b(i);
          end
          Mais plutôt
          c = a.*b

          Evidemment, cet exemple est trivial. C'est souvent plus compliqué mais ça s'apprend.
          • [^] # Commentaire supprimé

            Posté par . Évalué à 1.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: benchs/ tests

              Posté par . Évalué à 2.

              Par contre je mettrai pas le . a pres le a a ta place ;)
              Ben si, il faut mettre le point après le a sinon on fait une multiplcation matricielle qui s'écrirait avec une boucle:
              c=0;
              for i =1:length(a)
              c = c + a(i)*b(i)
              end

              Voilà!!
              • [^] # Commentaire supprimé

                Posté par . Évalué à 1.

                Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Re: benchs/ tests

                  Posté par . Évalué à 3.

                  uh la je suis toujours pas d'accord....a moins que ce soit pas du python dont tu parles..
                  Effectivement, on parlait de Scilab/Matlab/Octave.
          • [^] # Re: benchs/ tests

            Posté par . Évalué à 1.

            Les 70Mo c'est en regardant dans le gestionnaire de tâches sous Windows XP, avec je ne sais plus quelle version de Matlab (R14 je crois).

            Les boucles sont particulièrement lentes sous Matlab, et par rapport à Python c'est très sensible...
            De plus tout écrire sous forme de matrice je ne suis pas convaincu par cette approche bien que c'est toujours celle qu'on finit par prendre car plus rapide.

            Exemple : la transformée de Fourier, qui est en O(n.log(n)) si on se débrouille bien, si on le fait trivialement avec des matrices ça devient du 0(n²).
            L'exemple est mal choisit parce que des fonctions internes de Matlab le font déjà, mais par exemple pour un algo où tu n'as besoin que d'un élément de la matrice, tout calculer est très lourd... Sans compter que par exemple pour un algo je me suis retrouvé avec une matrice 1000*1000 alors qu'une double boucle simple règle le problème.

            Ce n'est pas handicapant pour des petites matrices, mais dès que la taille du problème grandit...

            Sinon je ne nie pas que Matlab a de très bonnes toolboxes, mais je n'ai pas eut l'occasion de m'en servir.
            • [^] # Re: benchs/ tests

              Posté par (page perso) . Évalué à 1.

              > Les boucles sont particulièrement lentes sous Matlab, et par rapport à Python c'est très sensible...

              euh t'es sûr ? t'as un exemple ? parce que depuis la R12 ou la R13 matlab embarque un compilateur JIT et ça commence à dépoter pas mal, certainement beaucoup plus que l'interpreteur python.
        • [^] # Re: benchs/ tests

          Posté par (page perso) . Évalué à 2.

          Je confirme, Matlab est vraiment très lent...

          Matlab a des use cases très précis pour lesquels il est extrêmement rapide. Par exemple, tout son calcul matriciel est basé sur atlas, une bibliothèque open source dont les performances sont les meilleures du marché ou presque.

          Quand on attaque un problème qui se formule bien avec les opérateurs matriciels et qui ne nécessite pas d'accéder individuellement de façon "aléatoire" au contenu des matrices, un code matlab (ou R ou scilab) est aussi rapide que du C appelant atlas et donc des dizaines fois plus rapide qu'un code C utilise une bibliothèque de calcul matriciel naïve.

          Par contre, si on ne sait pas écrire les calculs d'une façon qui plait à matlab (ou si ce n'est pas possible), ça rame. Et c'est normal.
          • [^] # Commentaire supprimé

            Posté par . Évalué à 1.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: benchs/ tests

              Posté par (page perso) . Évalué à 2.

              Mon message n'est pas un argument contre numpy, il cherche juste à préciser les critiques contre matlab pour les rendre pertinentes. Personnellement, je n'utilise pas du tout matlab, mais R qui est libre et qui a les mêmes problèmes que matlab en terme d'efficacité (et les mêmes avantages). Je n'ai pas de doute sur la qualité de numpy en terme de calcul matriciel.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.