Petite actu des outils d’analyse numérique

Posté par  . Modéré par Lucas Bonnet. Licence CC By‑SA.
Étiquettes :
45
16
juin
2011
Science

Au pays des scientifiques (entreprises & labos), en plus de la « taxe Microsoft » (Windows + MS Office), s’ajoute souvent la « taxe MATLAB » (employé comme grosse calculatrice graphique programmable…). Pourtant, dans ce milieu, les geeks ne sont pas rares. Continuons à porter la bonne parole : il existe des alternatives très valables, à choisir selon ses priorités !

Petit tour des candidats et leurs mises à jour dans la seconde partie de la dépêche.

Python avec SciPy (NumPy) & matplotlib

Ça s’installe aussi simplement sur une bonne distrib’ Linux / *BSD que sur Mac OS X ou Windows. Compatible Python 3, mais certains binaires ne sont fournis que pour Python 2.

Passer à Python demande d’ajuster ses habitudes de programmation (syntaxe très particulière), mais pour y gagner vraiment au passage. On peut garder des petits scripts sans se casser la tête, mais si on veut structurer un projet, appeler des modules externes, ça devient bien bien plus propre (horreur, un fichier « .m » pour la moindre fonction, l’affreux mex pour appeler du C…).

On bénéficie alors de l’océan d’extensions Python pour répondre à tous les petits besoins annexes, gratuitement et simplement : le réseau, l’accès au matériel (ports série, GPIB), Tkinter pour les petites interfaces ou PyQt pour les grosses.

Concrètement, côté numérique, l’« ossature » de manipulation de vecteurs et matrices est assurée par NumPy (version 1.6 sortie en mai), les fonctions scientifiques étendues sont fournies par SciPy (version 0.9 sortie fin février. Bientôt la 1.0 ?), et pour les beaux graphiques dans tous les sens, exportés dans tous les formats, appelez matplotlib à la rescousse (version 1.0.1 de janvier). Tout ça est maintenant bien stable, toutes les fonctions courantes sont disponibles.

Scilab

Depuis bien longtemps cet outil est pleinement satisfaisant, avec toute la documentation en français ! Développé initialement par l’ENPC et l’INRIA (occasions de stages ?), il s’est ouvert à travers un consortium.

La syntaxe ne dépayse pas trop, bien que pas exactement identique aux vieilles habitudes (scripts à modifier).

Le passage à la version 5 l’a largement modernisé (et sensiblement alourdi !), de nombreux outils pratiques de déverminage ont bien mûri. Un autre plus de Scilab par rapport aux autres : Xcos (ex‐scicos), le simulateur « synoptique bloc » (à la Simulink), lui aussi devenu bien plus attrayant… De nombreuses « boîtes à outils » sont disponibles pour ajouter des fonctionnalités (via les ATOMS et la forge).

Scilab 5.3.2 date de mai, la version 6 est en chantier.

Octave

Octave vise la compatibilité avec les programmes MATLAB, pour une transition à court terme sans trop de râleries, mais en ajoutant également des petits raccourcis pour améliorer « l’expérience de développeur ».

La version 3.4.0 est sortie en février, et on sent depuis quelque temps qu’on a atteint un produit stable (plus de bogues de tuyau gnuplot…), performant et fonctionnel (notamment avec les greffons de Octave-Forge). Toujours pas d’environnement « sexy » de base, mais le shell, c’est très bien ; pourquoi l’emballer ? Je règle mon Term et mon éditeur comme je le préfère !

FreeMat

Même objectif de compatibilité avec la « référence coûteuse », mais avec une interface plus léchée, FreeMat semble être un plus petit projet qui s’est développé doucement : la version 4.0 date d’octobre 2009.

R

R est depuis longtemps une référence pour les statistiques et l’analyse de données. La dernière révision est sortie en avril.

Et les « gadgets »… aussi pratiques ?

Pour ceux qui aiment ne jamais faire comme les autres, on peut retrouver des capacités vectorielles et graphiques dans de nombreux autres petits langages. Par exemple, le bon vieux S-Lang accompagné de Grace, le tout pimpant Kpl, le Perl Data Language avec PLplot, des tentatives avec JavaScript comme NumCalc ou gRaphaël…

Et, bien‐sûr, du C++, du Ruby, du OCaml, etc., et GnuPlot, plotutils, Qt, GTK, Tk, SVG, Fig, PostScript…

Aller plus loin

  • # Et Sagemath?

    Posté par  . Évalué à 8.

    Tu peux aussi rajouter sagemath à ta liste: http://www.sagemath.org/

    Il se compare peut-être un peu plus à mathematica avec son "notebook" assez similaire et est plus orienté calcul formel en intégrant maxima par exemple. Globalement, tu peux assez facilement l'utiliser depuis python et il y a même un module latex.

    • [^] # Re: Et Sagemath?

      Posté par  . Évalué à 10.

      C'est effectivement très bien, je l'utilise souvent, mais il faut quand même signaler au passage sa méthode de packaging la plus pourrie que l'on puisse imaginer. L'installation consiste à télécharger une grosse archive de ≈400MB, et de décompresser tout ça dans /usr/local.

      OK, ça marche, mais on se retrouve avec toute une flopée de programmes installés avec; Sage arrive avec son propre python, son propre maxima, R, librairies diverses (Atlas, GSL, ...), etc. Ils trouvent même le besoin de balancer leurs propres versions de programmes effectivement super rares tels bzip2, patch, et j'en passe. Bref, zéro intégration. Typiquement, je n'ai aucune idée de la manière d'utiliser sage à partir de mes scripts pythons, vu qu'ils faut passer par leur propre shell... Franchement dommage, cela limite énormément son utilité.

      • [^] # Re: Et Sagemath?

        Posté par  (site web personnel) . Évalué à 5.

        D'ailleurs, ces informations complètent bien un journal récent sur le sujet.

      • [^] # Re: Et Sagemath?

        Posté par  . Évalué à 1.

        Il me semble que la "version" de Python présente dans Sage fait juste un preparsing du genre : "**" <=> "^" (puissance/exponentiation), etc. Mais guère plus.
        Le fait d'avoir Python comme langage est vraiment très puissant et confortable, je trouve. Quel type de problème y a t-il pour charger votre code ?

        • [^] # Re: Et Sagemath?

          Posté par  . Évalué à 3.

          Ben c'est simple:
          à partir de sage:
          import sage -> pas de problèmes
          import h5py -> import error (exemple typique de module python installé sur le système)

          à partir du python système:
          import sage -> import error
          import h5py -> pas de problèmes

          Les deux pythons ne sont simplement pas connectés: on peux utiliser sage seulement avec les modules qui y sont liés, et on ne peut pas utiliser sage avec le python système. Bref, du gros monolitique inutilisable en dehors de ce qui est prévu par les développeurs sage.

      • [^] # Re: Et Sagemath?

        Posté par  . Évalué à 1.

        D'un autre côté, les autres solutions c'est quoi?

        • le tar.gz à compiler qui va te demander la lib-foo-bar en version >= 2.63.45 alors que ta distro a la version 2.63.44 (miam, se manger toute la doc sur le paquet-pinning et fracasser 10% du système pour ça),

        • les paquets pré-compilés pour RedHat 2.1AS et Linux Mint 10 LXDE (autres distros: démerden zie dich),

        • le tar.gz précompilé qui va pas gueuler pour se décompresser, qui marchera partout, qui te fait confiance pour avoir les pré-requis sur ton système, et qui va te jeter aléatoirement en disant "function foo-bar-azimutor-metatron not found, lib-foo-bar at minimum version 2.63.45 required".

        Ça a été dit et redit, ce point est un des gros points noirs caca sous Linux. Et la solution de la grosse archive qui emmène toute la Smalah pour ne manquer de rien, n'est pas si mauvaise que ça.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Et Sagemath?

          Posté par  (site web personnel) . Évalué à 5.

          Ça a été dit et redit, ce point est un des gros points noirs caca sous Linux. Et la solution de la grosse archive qui emmène toute la Smalah pour ne manquer de rien, n'est pas si mauvaise que ça.

          Pas si sûr !

          C'est ce que fait Microsoft depuis toujours. C'est ce qu'on n'a jamais voulu faire avec les Unix où chaque chose doit avoir sa place : les binaires dans /usr, la configuration dans /etc, les données modifiables dans /var, etc. On peut ainsi protéger les binaires (pas de virus), sauver toute la configuration et sauvegarder les données sans y inclure les programmes.
          Voir http://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

          La "simplification" de Microsoft qui peut sembler intéressante vue de loin ne résiste pas à un examen à peine plus détaillé !

          • [^] # Re: Et Sagemath?

            Posté par  . Évalué à 3.

            Je veux garder mon Windows XP et installer Firefox 4: no problem.

            Je veux garder ma Debian Etch (allez, soyons gentils: Debian Lenny) et installer Firefox 4: et merdre.

            Clairement, il manque un format permettant d'installer des applis dans le dossier utilisateur, juste pour cet utilisateur. Des sortes d'applications portables qui se mettraient dans ~/.user_apps/$nom_de_l_application/bin-usr-etc...

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: Et Sagemath?

              Posté par  . Évalué à 5.

              Clairement, il manque un format permettant d'installer des applis dans le dossier utilisateur, juste pour cet utilisateur.

              Pas sûr qu'il manque le format: http://0install.net/, la popularité, peut-être.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Et Sagemath?

                Posté par  . Évalué à 2.

                Dans le temps il y avait Klik.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Et Sagemath?

              Posté par  . Évalué à 5.

              L'exemple de Firefox n'est pas bon car, justement, il suffit de dézipper l'archive et ça roule.
              J'ai le quasi-dernier Firefox sur une bécane pas à jour depuis plusieurs années. Il est installé dans /opt (avec le dernier Thunderbird, le dernier Freemind, etc).

              Mais bon, avec d'autres exemples c'est ok.

        • [^] # Re: Et Sagemath?

          Posté par  (site web personnel) . Évalué à 2.

          C'est que que font tous les programmes privateurs. Lorsque tu les installes, ils viennent avec leur propre version de java, de tcl/tk, de PVM, de MPI, de...

    • [^] # Re: Et Sagemath?

      Posté par  (site web personnel) . Évalué à 2.

      Ce n'est pas vraiment un outil de calcul numérique plutôt de calcul symbolique.

  • # Eigen

    Posté par  (site web personnel) . Évalué à 7.

    Dans la même veine, mais un peu plus bas niveau puisqu'il s'agit d'une librairie d'algèbre linéaire, il y a l'excellent Eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page), fait par des Français qui passent par ici de temps en temps si mes souvenirs sont bons.

    C'est vraiment une excellente librairie, avec une API sympathique à utiliser et d'excellentes performances.

  • # G'MIC

    Posté par  (site web personnel) . Évalué à 9.

    G'MIC également, particulièrement dans sa version "ligne de commande", permet de visualiser des données 1d (courbes), 2d (images) et 3d (volumes et/ou objets vectoriels). Il ne fait pas "que" de l'image, puisqu'il est également capable de faire de l'évaluation d'expressions et du calcul matriciel (inversion, résolution de systèmes linéaires, SVD, ..), tout ça à partir du shell. En ce qui me concerne, il a remplacé Matlab, au moins pour les calculs simples, et la visualisation de données.

    • [^] # Re: G'MIC

      Posté par  (site web personnel) . Évalué à 3.

      Tu aurais des pointeurs vers de la doc sur ces fonctionnalités ?
      En regardant vite fait, sur le site, je n'ai vu que du traitement et analyse d'image.

      Merci

      • [^] # Re: G'MIC

        Posté par  (site web personnel) . Évalué à 10.

        Oui, les fonctionnalités sont décrites dans la doc de référence. En particulier, pour le calcul et la visualisation, je conseille de regarder les sections :

        Ca permet par exemple d'utiliser G'MIC comme une calculatrice pas trop basique :

        dtschump@xxx:$ gmic -e "{a=pi/3;cos(a)^2+sin(a)^2}"

[gmic]-0./ Start G'MIC instance.
[gmic]-0./ 1
[gmic]-0./ End G'MIC instance.

        (ici '-e' est équivalent à '-echo' et affiche juste le résultat sur la console).

        Quelques opérateurs d'opérations matriciels sont disponibles ici, par exemple pour inverser une matrice :

        dtschump@xxx:$ gmic "(0,1,0;0,0,1;1,0,0)" -invert -p

[gmic]-0./ Start G'MIC instance.
[gmic]-0./ Input image at position [0], with values '(0,1,0;0,0,1;1,0,0)' (1 image 3x3x1x1).
[gmic]-1./ Invert image [0].
[gmic]-1./ Print image [0].

image [0] = '(unnamed)': this = 0xa7f403c, size = (3,3,1,1) [36 b], data = (float*)0xa7f2318..0xa7f233b (non-shared) = [ 0 0 1 ; 1 0 0 ; 0 1 0 ], min = 0, max = 1, mean = 0.333333, std = 0.5, coords(min) = (0,0,0,0), coords(max) = (1,2,0,0).

[gmic]-1./ End G'MIC instance.

        (une matrice est simplement définie comme une image, i.e. un tableau de valeurs). Ici on lit que l'inverse de [0,1,0;0,0,1;1,0,0] est [0,0,1;1,0,0;0,1,0].

        Pratique pour visualiser des données (en particulier '-plot' pour les courbes 1d). Par exemple,

        dtschump@xxx:$ gmic -plot "'x^2*cos(x)'",1024,1,0,0,100

[gmic]-0./ Start G'MIC instance.
[gmic]-1./ Plot image [0] = 'x^2*cos(x)'.

x^2*cos(x): this = 0x93a8bec, size = (1024,1,1,1) [8 Kb], data = (double*)0x93ae3e0..0x93b03df (non-shared) = [ 0 0.0094913 0.0374217 0.0821735 0.141094 0.210557 0.286054 0.362302 ... 2517.3 3439.99 4333.45 5189.03 5998.41 6753.65 7447.34 8072.6 ], min = -9476.38, max = 8880.45, mean = -53.0707, std = 3123.35, coords(min) = (997,0,0,0), coords(max) = (965,0,0,0).

[gmic]-0./ End G'MIC instance.

        Titre de l'image

        • Après, si on combine quelques commandes entres elles, on peut avoir des choses assez sympas 'facilement', pour la visu de fonctions :

        dtschump@xxx:$ gmic 128,128 -f "X=(x-64)/6;Y=(y-64)/6;90*exp(-(X^2+Y^2)/30)*abs(cos(X)*sin(Y))" --n[-1] 0,255 -map[-1] 5 -elevation3d[-1] [-2] -rm[-2] -o3d 0.4

[gmic]-0./ Start G'MIC instance.
[gmic]-0./ Input black image at position [0] (1 image 128x128x1x1).
[gmic]-1./ Fill image [0] with expression 'X=(x-64)/6;Y=(y-64)/6;90*exp(-(X^2+Y^2)/30)*abs(cos(X)*sin(Y))'.
[gmic]-1./ Normalize image [0] in range [0,255].
[gmic]-2./ Map jet color LUT on image [1].
[gmic]-2./ Create 3d elevation of image [1], with elevation map [0].
[gmic]-2./ Remove image [0] (1 image left).
[gmic]-1./ Set opacity of 3d object [0] to 0.4.
[gmic]-1./ Display 3d object [0] = '(unnamed)*' (16384 vertices, 16129 primitives).
[gmic]-1./ Selected 3d pose = [ 2.51969,0,0,-160,0,2.51969,0,-160,0,0,2.51969,-104.929,0,0,0,1 ].
[gmic]-1./ End G'MIC instance.

        Titre de l'image

        ou encore :

        dtschump@xxx:$ gmic 64,1,1,20,"X=x/w;cos(0.2*X*c+?(0.01*c))" -dg 800,600,0,4,0,1,-1,1 512,1,1,1,"X=x/w;3*sinc(20*X)" -dg[1] 800,600,2,0,0,1,-1,1 -+

[gmic]-0./ Start G'MIC instance.
[gmic]-0./ Input image at position [0], with values 'X=x/w;cos(0.2*X*c+?(0.01*c))' (1 image 64x1x1x20).
[gmic]-1./ Render graph plot from data of image [0].
[gmic]-1./ Input image at position [1], with values 'X=x/w;3*sinc(20*X)' (1 image 512x1x1x1).
[gmic]-1./ Render graph plot from data of image [1].
[gmic]-2./ Add images [0,1].
[gmic]-1./ Display image [0] = '(unnamed)*'.
(unnamed)* (800x600x1x3): this = 0xbfbd910c, size = 1 [5625 Kb], data = (CImg<float>*)0x93ff5c4..0x93ff5db.
  [0]: this = 0x93ff5c4, size = (800,600,1,3) [5625 Kb], data = (float*)0xb6077008..0xb65f5407 (non-shared) = [ 220 220 220 220 220 220 220 220 ... 220 220 220 220 220 220 220 220 ], min = 0, max = 255, mean = 243.949, std = 31.8313, coords(min) = (412,594,0,2), coords(max) = (783,583,0,2).

[gmic]-1./ End G'MIC instance.

        Titre de l'image

        Si on se penche ensuite vraiment sur la syntaxe du langage, on peut faire des choses assez sophistiquées, en combinant rendus 2d et 3d par exemple, en très peu de lignes.

        • [^] # Re: G'MIC

          Posté par  (site web personnel) . Évalué à 2.

          Merci
          Ça valait le coup de poser la question pour une aussi bonne réponse !

        • [^] # Re: G'MIC

          Posté par  (site web personnel) . Évalué à 2.

          Je suis impressionné par le rendu mais c'est jamais plaisant de devoir réapprendre encore une nouvelle syntaxe. Dommage que les courbes 3d de gnuplot ne soient pas rendu avec gmic

  • # R et Scilab

    Posté par  (site web personnel) . Évalué à 7.

    J'utilise fréquemment R et Scilab.
    R est un petit bijoux pour faire des stats. On tire des nombre aléatoire suivant un paquet de lois avec une grande simplicité et une bonne rapidité.

    Scilab est bien sympa notamment grâce à une exécution des scripts aisées et une interface sobre et simple.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Python et Matplotlib

    Posté par  . Évalué à 7.

    J'attire aussi l'attention sur cet excellent shell interactif qui est couplé avec matplotlib et que j'ai découvert récemment:
    http://dreampie.sourceforge.net/

    • [^] # Re: Python et Matplotlib

      Posté par  . Évalué à 4.

      Ça semble être dans la même veine que ipython mais avec plus d'interactions graphiques.

      • [^] # Re: Python et Matplotlib

        Posté par  . Évalué à 2.

        Oui et surtout plus simple à utiliser.

        Le seul truc que je regrette est la possibilité de sauvegarder son historique dans un fichier py plutôt que dans un html.

        Enjoy

    • [^] # Re: Python et Matplotlib

      Posté par  . Évalué à 4.

      Remarque perso sur le couple python/matplotlib (que j'utilise quotidiennement, venant de IDL) :

      Ca marche très bien, mieux qu'IDL même, mais c'est encore lourd, lent, et pas optimisé. Typiquement, afficher un tableau/image 2000x2000 prends plusieurs dizaines de Mo en RAM, et est sensiblement plus lent qu'en IDL.

      Visiblement, après en avoir discuté un peu sur leur mailing-list, ils ont fait des choix pas très judicieux a une époque (pour associer une couleur a un nombre, ils utilisent 4 octets : RGB+alpha), et ils luttent pour optimiser ca (j'en veux pour preuve la plethore de routine de display, qui font toutes à peu près la même chose, mais plus ou moins vite, ou avec des options en moins).

      Mais pas de meprise, hein, au final, ca reste super. Il faut juste faire attention a sa mémoire.

      • [^] # Re: Python et Matplotlib

        Posté par  . Évalué à 2.

        Idem, je viens aussi d'IDL que je n'utilise pour ainsi dire plus maintenant, remplacé par numpy/scipy/matplotlib et quelques bibliothèques un peu plus spécialisées. Ce que je trouve le plus agaçant est le temps de sauvegarde des graphes. Sauver un “scatter” avec quelques milliers de points en PDF peut prendre des dizaines de secondes et sortir un fichier d'1 Mo. Avoir plusieurs graphes dans un même fichier est aussi légèrement plus casse-tête qu'avec IDL mais rien de bien méchant. D'ailleurs si un expert de matplotlib passe, comment on fait pour activer les minorticks par défaut ?

        • [^] # Re: Python et Matplotlib

          Posté par  . Évalué à 2.

          Regarde dans ton fichier: .matplotlib/matplotlibrc ou .matplotlib/matplotlib.conf

        • [^] # Re: Python et Matplotlib

          Posté par  . Évalué à 2.

          Quelques dizaines de secondes c’est qu’il y a un problème. Par contre me suis bêtement fait avoir parce que j’étais en interactif. Du coup :

          pyplot.plot(a)
xlim(0, 1)
xscale('log')
legend()
...

          Recalculait le graphe à chaque ligne… -_-

          Une fois corrigé ce petit problème j’ai mes graphes en même pas une seconde (des milliers de points et leur carte de densité). Ceci en deux passes de sauvegarde (j’ai surchargé les fonctions de pyplot pour faire ma petite tambouille).

      • [^] # Re: Python et Matplotlib

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Pour les amateurs d'IDL, il faut citer GDL (GnuDataLanguage), qui permet d'exécuter des scripts IDL : [http://gnudatalanguage.sourceforge.net/]

  • # QtOctave

    Posté par  (site web personnel) . Évalué à 5.

    Toujours pas d’environnement « sexy » de base
    Il ne faut pas oublier QtOctave, moins complet que l'interface de MatLab mais bien fournie tout de même ;)

    • [^] # Re: QtOctave

      Posté par  . Évalué à 1.

      +1
      Je trouve aussi QtOctave assez "sexy" et avec les plug-ins (comme zenity) il suffit à mon bonheur d'utilisateur de logiciel libre.

  • # SQL

    Posté par  . Évalué à 7.

    Je vais sans doute faire bondir des gens ici, mais pour de l'analyse de données, SQL c'est très bien aussi.

    Les View, join, group by etc permettent facilement de travailler sur de gros volumes de données, d'agreger plusieurs sources, filtrer etc. J'ai monté plusieurs fois des bases pour des amis thésards (pas forcement en info). Ils ont trouvé ça assez intuitif, plus que R par exemple pour lesquels ils avaient pourtant eu des cours à l'inverse de SQL (bon l'utilisation de phpmyadmin aide aussi).

    Le dernier exemple en date: une amie l'utilise pour traiter des données issues de l'INSEE. Avec souvent plusieurs tables à croiser, et une ou plusieurs lignes par communes (donc > 36000).

    Quelques défauts par contre:
    - Il semble y avoir un foutu bug dans mySQL qui double le nombre de ligne quand on fait des GROUP BY et des jointures implicites.
    - Le EXPLAIN sous mySQL c'est franchement pas ça.. Faudrait que j'essai avec pgSQL.

    • [^] # Re: SQL

      Posté par  (site web personnel) . Évalué à 5.

      Pour du calcul, il vaut mieux utiliser des bases de données binaires comme HDF ou NetCDF (basé aujourd'hui sur HDF). C'est plus orienté tableau.

      • [^] # Re: SQL

        Posté par  . Évalué à 2.

        J'adhère ! Le jour où j'ai découvert HDF ma vie a changé. (rien de moins)

        Les avantages sont nombreux : la structuration des données est excellente, le travail sur des volumes très importants ne pose pas de problèmes (ni de gestion, ni de temps d'accès), et couplé à python (ou en interactif) l'accès à nos données est d'une extrême facilité (syntaxe similaire à un système de fichiers).
        Et grâce à cette facilité de manipulation des données et au fait que le tout est assemblé dans un fichier, les sauvegardes sont aisées !
        Un must have quand on fait de l'analyse de données !

    • [^] # Re: SQL

      Posté par  . Évalué à 2.

      Ca aide beaucoup de maitriser SQL, mais il y a bien un moment ou c'est plus adapté, en gros quand on passe de la manipulation à l'analyse. Que ce soit pour faire des stats, construire des modèles ou visualiser ses données.

      Un projet qui pourrait t'intéresser: sqldf. Du sql dans des data frames R.

    • [^] # Re: SQL

      Posté par  (site web personnel) . Évalué à 4.

      pour de l'analyse de données, SQL c'est très bien aussi

      Mais la question porte sur l'analyse numérique, pas l'analyse de données. :)

    • [^] # Re: SQL

      Posté par  . Évalué à 2.

      Il est bon de connaître les requêtes analytiques pour ce genre d'utilisation car c'est vraiment plus agréable (et nettement plus performant).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Et aussi...

    Posté par  (site web personnel) . Évalué à 5.

    Spyder (Scientific PYthon Development EnviRonment)

    Il y a une conf sur le passage Matlab => Python (/Spyder) à l'école Polytechnique la semaine prochaine.

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: Et aussi...

      Posté par  . Évalué à 1.

      Merci, je pourrait montrer un zoli IDE a ceux qui viennent de Matlab et qui trouvent ma ligne de commande "limitée" !

    • [^] # Re: Et aussi...

      Posté par  . Évalué à 1.

      Tu n'aurais pas un lien|date et lieu exact pour la conf ?

      • [^] # Re: Et aussi...

        Posté par  (site web personnel) . Évalué à 4.

        Calcul scientifique avec Python

        Traitement et visualisation de données

        Pierre Raybaut – CEA/DAM

        Lundi 20 juin 2011, 10h30-11h30
        Amphithéâtre Becquerel, École Polytechnique

        Résumé
        Python est un langage de programmation à la fois simple, efficace et polyvalent. C’est pourquoi il remporte un franc succès auprès de la communauté scientifique depuis quelques années. Après un tour d’horizon des spécificités de ce langage, nous examinerons les raisons de cet engouement, en particulier au CEA/DAM Île-de-France. Ensuite, à travers un exemple concret et des démonstrations, nous nous intéresserons aux motivations et aux modalités pratiques d’une migration de MATLAB® vers Python pour le traitement et la visualisation de données.

        Exemple d’une migration réussie depuis MATLAB®
        Un logiciel de traitement sera présenté dans sa version MATLAB®, puis dans sa version Python afin de démontrer les avantages d’une telle migration.
        De plus, nous verrons qu’il est possible de retrouver un environnement de développement interactif aussi efficace que celui de MATLAB® grâce à Spyder.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # McLab & McVM

    Posté par  (site web personnel) . Évalué à 1.

    Il y a un labo à McGill qui travaille sur le language MATLAB: McLab. Apparamment ils définissent un sous-ensemble de la syntaxe MATLAB (qui n'est d'ailleurs par vraiment spécifiée à ce qu'il paraît). Ils proposent McVM, une machine virtuelle avec un JIT (compilateur à la volée, en français je crois) dont les sources sont déjà disponibles. Leur but étant aussi d'offrir un générateur de code FORTRAN, il paraît que les scientifiques aiment ce language.

    • [^] # Re: McLab & McVM

      Posté par  . Évalué à 4.

      Je pense que les scientifiques n'aiment pas plus Fortran que les programmeurs d'application commerciales aiment Cobol. Mais entre ça et récrire les millions de lignes de code qui existent...

      • [^] # Re: McLab & McVM

        Posté par  . Évalué à 1.

        Cela depend de ce a quoi tu compares. Entre le fortran et le C il y a pas photo pour faire du calcul numerique. La raison en est simple, le fortran est fait pour, le C non. Naturellement je ne parle des versions fortran 77 et inferieurs et si il existe encore des personnes programant dans des melanges de 77 et 66.

        Par contre si tu compares avec des langages de haut niveau tel que python/IDL/Matlab associe avec les differents outils autour (en particulier les plots) en effet le fortran c'est nul.

        • [^] # Re: McLab & McVM

          Posté par  (site web personnel) . Évalué à 3.

          Si tu fais un code pour l'envoyer sur un cluster de 1000 noeuds avec MPI, ton python, c'est nul et Fortran est génial.

          A chaque langage son usage et le Fortran n'est plus forcément adapté pour faire des trucs plus souple à faire avec un langage de script sur son poste de travail.

          • [^] # Re: McLab & McVM

            Posté par  . Évalué à 1.

            Mouais, alors MPI et fortran sur 1000 noeuds, je demande à voir en condition réelle. Parce qu'avec 1000 noeuds, tu as besoin d'un programme vraiment très parallèle. Fortran ayant une gestion pour le moins limité de la dynamicité (allocation dynamique, ...), si tu veux un programme efficace, il faut que ces tâches parallèles soient très régulières. Il doit y avoir quelques applis qui respectent ce cahier des charges (algèbre linéaire pleine par exemple), mais ça ne coure pas les rues.

            • [^] # Re: McLab & McVM

              Posté par  (site web personnel) . Évalué à 4.

              Sur les machines pétaflopiques du groupement européen PRACE (universitaire), le ticket d'entrée est d'avoir un job qui tourne sur 10000 coeurs normalement...

              On a des programmes qui tournent sur plus de 1000 coeurs en Fortran. Ca tourne très bien. Mais même sur 200 coeurs, cela marche aussi ;-)

              Quand on voit la consommation électrique de ces centres de calcul ainsi que le soucis écologique, il est quand même important d'avoir en tête l'impact écologique d'un code de calcul.

              PS : pour rappel, Fortran, depuis la version 2003, est aujourd'hui un langage objet ayant l'héritage simple ce que n'est pas encore le C !

              • [^] # C objet

                Posté par  . Évalué à 2.

                PS : pour rappel, Fortran, depuis la version 2003, est aujourd'hui un langage objet ayant l'héritage simple ce que n'est pas encore le C !

                Remarque à peine plus pertinente que de dire « le C++ est un langage objet, ce que n’est toujours pas le Fortran 77 ».

                Il y a déjà deux dérivés objet du C qui tiennent la route du C, le C++ et l’Objective-C. OK, ils n’ont pas été faits par les mêmes et appelés C 83 et C 86, mais ça ne change rien au fait que la place est déjà prise.

                Ceux qui développent encore en C le font parce qu’ils veulent rester à un langage plus bas niveau ou parce qu’il s’agit de compléter du code existant, un peu comme ceux qui utilisent encore le Fortran 77.

                « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Gourré de bouton !

                  Posté par  . Évalué à 1.

                  Il y a déjà deux dérivés objet du C qui tiennent la route du C

                  Je voulais me relire et j’ai cliqué sur « Poster » par erreur.

                  Cherchez pas « la route du C » comme quelque chose du genre de « la voie du Zen », le deuxième « du C » est juste en trop...

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

                • [^] # Re: C objet

                  Posté par  (site web personnel) . Évalué à 3.

                  Le Fortran 77 a 34 ans !

                  Tout le monde code normalement en Fortran 95 minimum de nos jours. Qui dis Fortran dis Fortran 95 (ou 90 les deux étant très proche). Il y a deux catégories de personne qui pensent encore Fortran = Fortran 77 -> Quelques anciens qui n'ont pas suivis l'évolution technologique comme on trouve des admin système qui sont resté sur Windows 98 et n'ont pas fait le pas des domaines... -> Quelques jeunes qui n'ont jamais vraiment fait de Fortran moderne ;-)

                  • [^] # Re: C objet

                    Posté par  . Évalué à 2.

                    Tout le monde code normalement en Fortran 95 minimum de nos jours

                    Non.

                    Plein de monde continue à coder en Fortran 77, ou Fortran 90. Plein. C'est comme de dire "Le C a plus de 35 ans ! Tout le monde code en C99 de nos jours". Et je ne te parle même pas des codes utilisés dans les centres de type CEA ou autres, qui ont une durée de vie d'environ 30-40 ans.

                    • [^] # Re: C objet

                      Posté par  . Évalué à 2.

                      La difference entre Fortran 95 et fortran 90 etant tellement minime que c'est un peu la meme chose. Apres que le fortran 77 soit encore utilise cela est certains, il y a meme des personnes qui programme encore en fortran 4 (66) ou plutot un mix de 77 et 66.

                    • [^] # Re: C objet

                      Posté par  (site web personnel) . Évalué à 3.

                      Il n'y a pas tant de différence que cela avec le C99...

                      Pour les applications critiques et anciennes, certes certaines personnes codent en F77 mais cela est valable pour tout langage dont le code doit avoir une très longue durée de vie. Je me trompe peu être, mais cela ne me semble pas représentatif de ce que je voulais dire initialement, c'est à dire recentrer le débat sur les grosses machines de calcul pour dire que Python, c'était bien mais ne pouvait pas tout faire.

                      Les vieux code du CEA tournent sur Tera-100 en pleine puissance ?

                      • [^] # Re: C objet

                        Posté par  . Évalué à 2.

                        Les vieux code du CEA tournent sur Tera-100 en pleine puissance ?

                        Je serais incapable de te dire. Par contre, dans les 5 dernières années, j'ai croisé un certain nombre de simulations codées en F77, un peu moins en F90, et aucune en F95/F2003... Et je ne parle pas que du CEA, mais aussi de Dassault, de certaines boites allemandes avec qui j'avais bossé, etc.

                        Ces codes étaient récents pour la plupart (i.e. moins de 10 ans). Bien entendu, certains réutilisaient des codes plus anciens, écrits au début-milieu des années 1990.

                        • [^] # Re: C objet

                          Posté par  (site web personnel) . Évalué à 2.

                          A vrai dire, on ne sais pas si on fait du F95 ou du F90 la plupart du temps... Pour le F2003, cela ne m'étonne pas, les compilateurs ont mis le temps et gfortran par exemple n'implémente pas tout, loin de là.

                          Personnellement, je ne sais pas en terme de performance l'implication que va avoir la programmation objet en Fortran. Si quelqu'un a des liens ?

                        • [^] # Re: C objet

                          Posté par  . Évalué à 4.

                          Le fortran 90 et 95 c'est exactement la meme chose avec juste l'instruction forall et les fonctions "pure" en plus pour le 95.

                          Le 7 et le 95 sont eux totalement different que ce soit pour les tableaux, l'allocations dynamique, les modules, la surdefinition d'operateurs...

                          Les versions 2003 et 2008 apportent surtout il me semble, par rapport au 90/95, l'heritage simple et "l'interoperability" avec le C.

                          Les versions 2003 et 2008 ne sont pas tres utilise pour pas mal de raisons je pense. En raison de la mauvaise presse faite au fortran, peu de jeunes programmerus l'utilisent sauf si ils y sont contraint et force par le fait de devoir reprendre le code (bien souvent tres mal ecrit et datant du fortran 77) de leur directeur de these et aussi que les compilos les supportant ne sont pas legions. Pour le GCC les deux liens suivant te donnent l'etat de l'implementation:

                          http://gcc.gnu.org/wiki/Fortran2003Status
                          http://gcc.gnu.org/wiki/Fortran2008Status

              • [^] # Re: McLab & McVM

                Posté par  (site web personnel) . Évalué à 3.

                PS : pour rappel, Fortran, depuis la version 2003, est aujourd'hui un langage objet ayant l'héritage simple ce que n'est pas encore le C !

                Donc le C est mieux vu qu'il ne s'amuse pas à suivre la mode 10 ans après ?

                • [^] # Re: McLab & McVM

                  Posté par  (site web personnel) . Évalué à 0.

                  Un langage qui n'évolue pas risque à terme la mort. Le Fortran a été déclaré mort un paquet de fois, il est bien plus vieux que le C et est toujours vivant. Enfin, plus le temps passe, moins il est beaucoup plus vieux que le C !

                  Le C a pour lui le coeur des OS actuels...

                  Ceci dis, l'héritage simple est quelque chose de quasi-natif dans tous les langages qui ont la notion de type vu la facilité de l'implémenter. C'est dommage que le C ne l'intègre pas déjà. Je ne parlerais pas d'une mode qui a 10 ans, la bataille Objective C vs C++ a déjà 25 ans et le premier langage objet normalisé date de 95...

                  Ceci dis, effectivement l'assertion suivante est vrai :

                  C++ < C

                  • [^] # Re: McLab & McVM

                    Posté par  . Évalué à 4.

                    ...blablabla...blablabla...
                    ...bla....blabla...blablabla...
                    ...blabla....bla...bla...blabla...

                    LE C++ C'EST NUL !

                    C'est quoi ton gros et vieux troll à la noix (de Grenoble) ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: McLab & McVM

                      Posté par  (site web personnel) . Évalué à 1.

                      Je te conseille la lecture de Bruno Latour notamment "Aramis ou l'amour des techniques". Il y fait de l'antropologie symétrique et tente d'expliquer pourquoi Aramis est mort alors que le VAL existe...

                      Pour le reste, tu as du me lire de travers. Je dis simplement qu'il est dommage que le C n'intègre pas en natif un système objet. L'extension du C a eu lieu au début des années 80 selon deux pistes très différentes mais qui n'ont pas intégré le tronc central. Vala est une autre piste plus moderne, plus dans les pas de Java et C#. Comme Vala d'ailleurs, au début C++ était un simple pré-compilateur pour le C.

                      Sinon, la dernière assertion était pour les petits jeunes qui ne la connaissait pas encore. Il n'y a aucun jugement de ma part, c'est plus une blague qui traînait ici même je croie il y a des années. Coluche aurait bien réussi à transformer cela en blague populaire ;-)

          • [^] # Re: McLab & McVM

            Posté par  . Évalué à 1.

            Note qu'il existe un package MPI pour python MPI4py. Ca marche bien (meme si j'avoue ne pas avoir essayé avec 1000 noeuds, seulement quelques centaines de processeurs).

            Par ailleurs, j'ai découvert récemment cython qui permet d'augmenter sensiblement les perfs des modules de calcul
            numérique tout en conservant une syntaxe tres proche du python. C'est par ailleurs tout a fait compatible avec le module multi-processing ce qui permet en plus de faire de la parallelisation a grains fins assez facilement.

    • [^] # Re: McLab & McVM

      Posté par  (site web personnel) . Évalué à 1.

      Pour information, leur JIT est basé sur LLVM.
      C'est un travail assez académique (dans le sens qu'il n'y a pas vraiment une équipe derrière).

    • [^] # Re: McLab & McVM

      Posté par  (site web personnel) . Évalué à 3.

      Leur but étant aussi d'offrir un générateur de code FORTRAN, il paraît que les scientifiques aiment ce language.

      FORTRAN est un langage spécialisé dans le calcul numérique et c'est le meilleur.

      • [^] # Re: McLab & McVM

        Posté par  (site web personnel) . Évalué à 4.

        c'est le meilleur parce qu'il n'a pas de concurrents, pas parce que c'est un bon langage. Le fortran ça pue , c'est moche, et depuis fortran 90 c'est atrocement verbeux.

  • # Python(x,y)

    Posté par  . Évalué à 4.

    http://www.pythonxy.com/

    Maintenu par un français, python(x,y) est la première chose que j'installe sur un ordinateur Windows pour bosser. C'est une distribution python qui intègre (entre autre) l'excellent IDE Spyder, pyQt pour faire des interface graphique rapidement, ainsi que pylab. Pratique quand on a pas la possibilité d'avoir un PC sous Linux.

  • # Conférence python

    Posté par  . Évalué à 4.

    Pour ceux qui seraient intéressés par l'utilisation de python en sciences, la conférence Euroscipy se déroulera à Paris cet été:
    http://www.euroscipy.org/conference/euroscipy2011
    Il y aura des tutoriels et des présentations rapportant l'utilisation de python, scipy & Co dans de nombreux domaines.

    Quelques liens utiles et conseils d'installation sont regroupés ici (en anglais):
    http://homepages.dias.ie/~jmorin/python/index.html
    pour ceux qui voudraient s'essayer aux joies du python.

    Et bien évidemment n'oubliez pas d'utiliser le module antigravity si vous êtes sous python >= 2.7 ;).

  • # maxima !

    Posté par  (site web personnel) . Évalué à 3.

    Il ne faut pas oublier maxima http://maxima.sourceforge.net/ qui est un très logiciel de manipulation symbolique dont l'écriture remontre à 1982.

    "La première sécurité est la liberté"

  • # Et aussi ScalaLab !

    Posté par  (site web personnel) . Évalué à 2.

    ScalaLab est plus que prometteur.

    Sans vouloir faire du prosélytisme à outrance, on peut presque considérer ScalaLab comme un démonstrateur des possibilités de Scala.
    Pour ne parler que de la vitesse d'exécution, ScalaLab laisse Scilab et Matlab loin derrière : un bench ici
    Mais ScalaLab a bien d'autres atouts.

    Pour les pythoneux sceptiques sur les languages statiques, l'avis de Bruce Eckel sur Scala mérite le détour.
    The Static Language that Feels Dynamic

    • [^] # Re: Et aussi ScalaLab !

      Posté par  (site web personnel) . Évalué à 2.

      Je veux pas être rabat-joie mais il me semble que leur évaluation tient plus de la blague que d'autre chose. La méthode est peu claire (combien de fois ont-t'ils fait tourner le bench, que mesurent-t'ils exactement ? ), ils n'ont que trois benchs, de plus il est très discutable de mesurer des benchs qui s'éxécutent en moins d'une seconde sur une machine virtuelle avec un JIT, de la gestion automatique de la mémoire, etc.

      • [^] # Re: Et aussi ScalaLab !

        Posté par  (site web personnel) . Évalué à 2.

        Il est vrai que tous les benchs sont à prendre avec des pincettes mais avez vous lu le document ?

        We should note also that although our benchmarks involve rather small computation times, they are accurate. Indeed by increasing two times the number of points for Henon map, we have on all systems about two times increase in delay also.

        Le bundle contient d'autres benchs pour vous faire une idée.
        En pratique on constate que le langage de script utilisé par ScalaLab est la plupart du temps effectivement plus rapide que le script Matlab équivalent.
        Il y a des raisons mécaniques à cela qui sont décrites dans le chapitre "Scala and Groovy" du document ...

  • # Pour R...

    Posté par  . Évalué à 4.

    Sans oublier qu'un (très bon) IDE pour R est sorti fin février !

  • # GLE

    Posté par  (site web personnel) . Évalué à 2.

    Pour les Figures, il y a aussi GLE (Graphics Layout Engine) qui est parfois une alternative intéressante à gnuplot

  • # Langage fonctionnel ?

    Posté par  . Évalué à 2.

    Je suis surpris de ne rien trouver en relation avec le caml, le lisp ou l'haskel par exemple. Le paradigme fonctionnel plaisant beaucoup aux matheux et permettant de décrire facilement de puissants algorithmes.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Langage fonctionnel ?

      Posté par  (site web personnel) . Évalué à 2.

      Le paradigme fonctionnel ça plait aux matheux qui n'ecrivent pas de code (pas les numériciens quoi). Le seul domaine sur lequel ça a percé c'est le calcul formel (Maple..) mais ce n'est pas de l'analyse numérique.

      Celà dit, il y a quand même lush: http://lush.sourceforge.net/ qui est vraiment orienté analyse numérique.

      • [^] # Re: Langage fonctionnel ?

        Posté par  (site web personnel) . Évalué à 3.

        Le paradigme fonctionnel ça plait aux matheux qui n'ecrivent pas de code (pas les numériciens quoi). Le seul domaine sur lequel ça a percé c'est le calcul formel (Maple..)

        Bref, ils n'écrivent pas de code mais en écrivent quand même …

        mais ce n'est pas de l'analyse numérique

        Exactement! Donc rien à voir avec le sujet initial.

    • [^] # Re: Langage fonctionnel ?

      Posté par  (site web personnel) . Évalué à 1.

      C'est précisément l'un des intérêts majeurs de ScalaLab cité un peu plus haut.
      ScalaLab utilise et encourage l'approche fonctionnelle. C'est une volonté de l'auteur.

      Ceci est possible puisque Scala intègre également le paradigme de programmation fonctionnelle que ScalaLab utilise et étend.

Suivre le flux des commentaires

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