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.
Aller plus loin
- numpy (204 clics)
- scipy (61 clics)
- numarray (71 clics)
- matplotlib (167 clics)
# Il faut informer la communauté scientifique
Posté par Ju Hash (site web personnel) . Évalué à 7.
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 Sylvestre Ledru (site web personnel) . Évalué à 5.
(disclosure : je participe à Scilab)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut informer la communauté scientifique
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
http://norma.mas.ecp.fr/wikimas/ScientificComputingSoftware
[^] # Re: Il faut informer la communauté scientifique
Posté par BAud (site web personnel) . Évalué à 3.
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
Posté par ashram4 . Évalué à 7.
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 Sylvestre Ledru (site web personnel) . Évalué à 7.
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 lolop (site web personnel) . Évalué à 5.
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.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Il faut informer la communauté scientifique
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
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 ashram4 . Évalué à 1.
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 Benoît Sibaud (site web personnel) . Évalué à 8.
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 Sylvestre Ledru (site web personnel) . Évalué à 2.
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 boubou (site web personnel) . Évalué à 7.
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 Sylvestre Ledru (site web personnel) . Évalué à 3.
[^] # Re: Il faut informer la communauté scientifique
Posté par boubou (site web personnel) . Évalué à 5.
[^] # Re: Il faut informer la communauté scientifique
Posté par Gniarf . Évalué à 1.
comme s'il n'y avait qu'une définition de logiciel libre.
[^] # Recherche publique bridé
Posté par salvaire . Évalué à -1.
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.
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?
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é
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
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 Sebastien . Évalué à 2.
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
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Le passage sous une licence libre serait en cours (dixit le responsable du projet).
[^] # Re: Il faut informer la communauté scientifique
Posté par Troy McClure (site web personnel) . Évalué à 1.
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 gyhelle . Évalué à 2.
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 Gilles G. . Évalué à 2.
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 gyhelle . Évalué à 2.
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 Rémi Hérilier . Évalué à 2.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . Évalué à 3.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . Évalué à 2.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut informer la communauté scientifique
Posté par Gilles G. . Évalué à 4.
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 lolop (site web personnel) . Évalué à 2.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il faut informer la communauté scientifique
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 1.
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 Antoine . Évalué à 3.
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 Marc (site web personnel) . Évalué à 2.
* 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 Gilles G. . Évalué à 2.
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 gyhelle . Évalué à 2.
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 Marc (site web personnel) . Évalué à 1.
* 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 Gilles G. . Évalué à 1.
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 Marc (site web personnel) . Évalué à 1.
[^] # Re: benchs/ tests
Posté par Gilles G. . Évalué à 2.
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!).
[^] # Re: benchs/ tests
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 1.
As-tu l'URL ? Car moi tout ce que je trouve c'est comment l'acheter. Scholar me trouve un pdf et un ps, mais les liens sont cassés O:-)
Merci
[^] # Re: benchs/ tests
Posté par gyhelle . Évalué à 2.
http://mdolab.utias.utoronto.ca/resources/python/Python_Scri(...)
[^] # Re: benchs/ tests
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 0.
Merci beaucoup :-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: benchs/ tests
Posté par Mat (site web personnel) . Évalué à 0.
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 Mat (site web personnel) . Évalué à 2.
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 Gilles G. . Évalué à 2.
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 Christophe Merlet (site web personnel) . Évalué à 2.
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 MiniMoi . Évalué à 1.
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 Gilles G. . Évalué à 2.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: benchs/ tests
Posté par Gilles G. . Évalué à 2.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: benchs/ tests
Posté par Gilles G. . Évalué à 3.
Effectivement, on parlait de Scilab/Matlab/Octave.
[^] # Re: benchs/ tests
Posté par MiniMoi . Évalué à 1.
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 Troy McClure (site web personnel) . Évalué à 1.
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 boubou (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: benchs/ tests
Posté par boubou (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.