Discussion :

[SebGR]

Bonjour à tous,

Pour ceux qui trouvent que les capacité de calcul mathématique et statistique (optimisation, analyse prédictive, clustering, ODE, PDE, etc...) de SciPy sont insuffisantes - manque de robustesse, de précison etc... -, il existe désormais le module PyIMSL qui consiste en une collection de wrappers Python téléchargeables permettant d'appeler très facilement les routines de la librairie mathématique et statistique IMSL en C.

Particulièrement pratique pour le prototypage rapide ainsi que pour une éventuelle mise en production de l'application (recodage en C facilité grâce à des APIs quasi-identiques) !


Si ça peut aider...
SebGR

[fred1599]

Pour ceux qui trouvent que les capacité de calcul mathématique et statistique (optimisation, analyse prédictive, clustering, ODE, PDE, etc...) de SciPy sont insuffisantes

PyIMSL n'utilise pas Numpy?

et comme Scipy depend de Numpy

En ce moment j'étudie Numpy, je te redis ca, j'ai commandé le livre de Matthieu, mais il me semble que ceux que tu fais avec PyIMSL sera surement possible avec Numpy, non?

[SebGR]

Fred,

Je rappelle que PyIMSL sert d'intermédiaire (wrapper) entre Python et la librairie IMSL en C (bien que PyIMSL repose effectivement sur Numpy, essentiellement en ce qui concerne la manipulation des tableaux).
Donc, tu vas pouvoir appeler facilement n'importe quelle routine d'IMSL en C depuis Python. Et si tu regardes le catalogue de fonctions de cette librairie, tu vas remarquer que ce qui s'y trouve est sans commune mesure avec ce qui est proposé par Numpy et SciPy.
Cela dit, ça ne sert a rien d'avoir une Porsche quand une Clio vous suffit


SebGR

[fred1599]

Ok ok en effet j'ai un peu regardé et trouve ça très intéressant, je te remercie pour le lien

[Matthieu Brucher]

Fred,

Je rappelle que PyIMSL sert d'intermédiaire (wrapper) entre Python et la librairie IMSL en C (bien que PyIMSL repose effectivement sur Numpy, essentiellement en ce qui concerne la manipulation des tableaux).
Donc, tu vas pouvoir appeler facilement n'importe quelle routine d'IMSL en C depuis Python. Et si tu regardes le catalogue de fonctions de cette librairie, tu vas remarquer que ce qui s'y trouve est sans commune mesure avec ce qui est proposé par Numpy et SciPy.

Il y a tout de même énormément de choses dans Numpy et dans Scipy. De plus, Numpy passe dans le coeur de Python 3, donc j'espère que Numpy est supporté par PyIMSL, sans quoi son intérêt est... limité. Pourquoi ? Parce qu'on se retrouve dans le même état qu'en C ou en C++ : il y a n paquets permettant de faire des calculs, mais ils ne sont pas compatibles entre eux. Garder Numpy comme base permet de ne pas mettre en concurrence PyIMSL et Scipy (quoique tu en dises, un effort considérable est actuellement mis pour tester exhaustivement Numpy et Scipy, et de l'énergie financière est aussi injectée par différentes entreprises dans ces paquets), mais de les faire coopérer pour en tirer le meilleur.
C'est pour ce dernier point que je trouve dommage l'introduction que tu donnes de PyIMSL. D'ailleurs, je rappelle l'intérêt de Python est de permettre un prototypage rapide. Quand on veut développer une vraie application complexe, on porte les éléments critiques en C ou en C++ (et là, on peut songer à IMSL )

edit : pas vu la différence flagrante entre les capacités de Numpy/Scipy et de IMSL. En revanche, mettre les Réseaux de neurones dans les stats...

edit 2 : j'ai vu que PyISML nécessitait Numpy, mais j'imagine que ce qui est effectivement exposé est l'interface Numpy et non un tableau Numpy ?

[fred1599]

pas vu la différence flagrante entre les capacités de Numpy/Scipy

Et c'est ce que j'expliquais, quand on dépend d'un module, c'est qu'on l'utilise!

Ce qui veut dire que quelqu'un maitrisant la théorie mathématiques pourra se permettre de reproduire les meme choses avec numpy.

En revanche, mettre les Réseaux de neurones dans les stats...

Tout à fait d'accord

[Matthieu Brucher]

Et c'est ce que j'expliquais, quand on dépend d'un module, c'est qu'on l'utilise!

C'est aussi que la liste des capacités mathématiques des deux ont l'air très proches. Par exemple, la partie sur les nombres aléatoires fait doublon avec celle déjà très complète de Numpy.

En revanche, dans l'absolu, est-ce qu'on peut brancher des bibliothèques optimisées sur IMSL ? Genre BLAS, FFT, ... ?

Ce qui veut dire que quelqu'un maitrisant la théorie mathématiques pourra se permettre de reproduire les meme choses avec numpy.

Je pense En tout cas toutes les généralités sont bien représentées dans les deux modules. Pour tout ce qui est spécifique, on se rabat toujours sur des modules dédiés, plus pratique

[SebGR]

Matthieu & Fred,

PyIMSL a été conçu principalement pour 2 raisons :
1) Parce que Python devient un langage de plus en plus populaire, tous secteurs d'activités confondus. Fondamentalement, tous ces secteurs ont besoin - avec différents niveaux d'exigence - de faire du calcul ;
2) Parce Python et consorts ne sont pas encore assez matures pour pouvoir proposer des fonctionnalités mathématiques et statistiques de haut-niveau (une étude sérieuse a été menée là-dessus, il faudrait que j'en retrouve la source...). On pourrait d'ailleurs faire un rapprochement avec Java : ses possibilités en matières de calcul restent limitées. La librairie JMSL a été une réponse à cette faiblesse.


L'open source a l'avantage d'être gratuit, mais seulement en apparence : que fait le développeur quand il rencontre un bug, quand il cherche de la doc sur un algo (parfois inexistante) ? Il perd du temps à fouiner à droite et à gauche.
L'avantage d'une librairie commerciale est d'être entièrement documentée et supportée.

Je suis conscient que tous les développeurs Python n'ont pas les mêmes exigences en matière de calcul : pas besoin d'une Porsche quand une Clio est suffisante. S'il y a satisfaction avec NumPy et SciPy, pourquoi donc chercher ailleurs ?

En revanche, dans des secteurs telles que la finance par exemple (gestion des risques, gestion de portefeuilles, etc...), tu ne trouveras pas grand monde qui va s'appuyer sur de l'open source s'agissant de calculs mathématiques et statistiques. C'est simple : soit ils développent leurs algos en interne (les "quants" sont très qualifiés et - très bien - payés pour cela), soit il font appel à une librairie commerciale.

S'agissant du peu de différences que tu remarques entre les 2 "modules" en questions, je vais te citer quelques exemples pour lesquels il n'y a pas photo :
1) l'optimisation non-linéaire sous contraintes. Incontournable. En effet, ce genre d'algo est extrêmement prisé, mais très très dur à mettre au point.
2) la programmation linéaire sous contraintes. Pour information, celui d'IMSL en C a nécessité plusieurs années de travail. Il a été benchmarké (sur des cas-tests de la Netlib) en termes de fiabilité, faisabilité, rapidité et robustesse par rapport à un conccurent reconnu dans ce domaine : le verdict a été sans appel.
3) Auto_ARIMA. C'est un algo "automatique" permettant de trouver les paramètres optimum pour un calcul de prévisions (sur des données historisées) suivant un modèle ARIMA. C'est novateur, et je ne crois pas qu'il y ait vraiment d'équivalent ailleurs.

En gros, mon avis est qu'on ne peut pas se permettre de "confier" des méthodes de calcul sophistiquées à de l'open source (bien que je sois de ceux qui pensent que l'open source soit l'avenir...). Un algo présent dans une librairie commerciale - si son éditeur fait bien son boulot - se doit d'avoir été passé au crible avant d'être releasé, afin qu'il puisse être utilisable immédiatement, facilement et l'esprit tranquille.

Bon, PyIMSL en est à sa 1ère version (ça fait une excuse pour le coup du réseaux de neurones dans les stats ). Son avenir va dépendre du succès qu'il va rencontrer (ou pas). Une chose est sûr : il devrait suivre les évolutions de la "plateforme Python" afin de rester accessible à la majorité des développeurs qui en seraient demandeurs. Je pense aussi aux universitaires et chercheurs qui disposent déjà de la librairie IMSL en C et qui développent en Python : ils seront ravis d'avoir la possiblité d'utiliser PyIMSL !

Matthieu, pour le cas de prototypage rapide puis d'industrialisation de code, tu as tout compris.

Pour ceux qui veulent tenter l'expérience, PyIMSL et une version d'évaluation d'IMSL en C sont directement téléchargeables (gratuitement) depuis : ce lien.

Pour ceux qui auront tenté l'expérience (et même pour les autres, d'ailleurs !), vos commentaires sont les bienvenus sur ce forum dédié.


Bonne journée à tous,
SebGR

[Matthieu Brucher]

Matthieu & Fred,

PyIMSL a été conçu principalement pour 2 raisons :
1) Parce que Python devient un langage de plus en plus populaire, tous secteurs d'activités confondus. Fondamentalement, tous ces secteurs ont besoin - avec différents niveaux d'exigence - de faire du calcul ;
2) Parce Python et consorts ne sont pas encore assez matures pour pouvoir proposer des fonctionnalités mathématiques et statistiques de haut-niveau (une étude sérieuse a été menée là-dessus, il faudrait que j'en retrouve la source...). On pourrait d'ailleurs faire un rapprochement avec Java : ses possibilités en matières de calcul restent limitées. La librairie JMSL a été une réponse à cette faiblesse.

J'aimerai aussi voir cette étude, parce que pour le moment tout ce que je vois, c'est que Python est largement supérieur aux solutions usuelles pour la calcul scientifique. Et ça fait des années que les scientifiques utilisent Python (la communauté astronomique a été précurseur dans ce domaine, et on ne peut pas dire qu'ils peuvent utiliser n'importe quoi).

L'open source a l'avantage d'être gratuit, mais seulement en apparence : que fait le développeur quand il rencontre un bug, quand il cherche de la doc sur un algo (parfois inexistante) ? Il perd du temps à fouiner à droite et à gauche.
L'avantage d'une librairie commerciale est d'être entièrement documentée et supportée.

Commercial et documenté, c'est orthogonal. Effectivement, Numpy avait des défaust à ce niveau, mais il y a tout de même sur scipy.org la liste complète des fonctions avec exemples. Et un marathon a été effectué pour remettre à jour les docstrings. Bref, cet argument ne tient pas.

Ah oui, le support de OS X pour PyIMSL ?

Je suis conscient que tous les développeurs Python n'ont pas les mêmes exigences en matière de calcul : pas besoin d'une Porsche quand une Clio est suffisante. S'il y a satisfaction avec NumPy et SciPy, pourquoi donc chercher ailleurs ?

Encore une orthogonalité. Si on se base sur des bibliothèques optimisées, on a une Porsche. Et c'est le cas de Numpy et de Scipy, je ne vois pas la même chose pour PyIMSL, donc la Porsche serait plutôt le couple Numpy/Scipy, non ? (et je ne parle même pas de Cython).
Et les astronomes, ils n'ont pas besoin d'une Porsche quand ils travaillent sur des Go de données ? Idem pour les traiteurs d'images 3D ?

En revanche, dans des secteurs telles que la finance par exemple (gestion des risques, gestion de portefeuilles, etc...), tu ne trouveras pas grand monde qui va s'appuyer sur de l'open source s'agissant de calculs mathématiques et statistiques. C'est simple : soit ils développent leurs algos en interne (les "quants" sont très qualifiés et - très bien - payés pour cela), soit il font appel à une librairie commerciale.

Un problème purement politique. Ce n'est pas parce que c'est une bibliothèque commerciale que c'est meilleur qu'une solution Open Source. Dire que c'est une solution commerciale n'est pas équivalent à dire c'est le meilleur. Encore une fois, les préjugés ont la vie dure.

J'ai fait de la finance en projet avec un grand groupe français. Si les solutions que j'avais proposées étaient open source, ça n'aurait pas changé grand chose.

S'agissant du peu de différences que tu remarques entre les 2 "modules" en questions, je vais te citer quelques exemples pour lesquels il n'y a pas photo :
1) l'optimisation non-linéaire sous contraintes. Incontournable. En effet, ce genre d'algo est extrêmement prisé, mais très très dur à mettre au point.

scikits.openopt, permettant de sélectionner l'algorithme qu'on veut pour un problème spécifique parmi plusieurs optimiseurs y compris commerciaux existants avec une interface commune. Comme un optimiseur ne peut pas répondre à toutes les problématiques, c'est bien pratique.

2) la programmation linéaire sous contraintes. Pour information, celui d'IMSL en C a nécessité plusieurs années de travail. Il a été benchmarké (sur des cas-tests de la Netlib) en termes de fiabilité, faisabilité, rapidité et robustesse par rapport à un conccurent reconnu dans ce domaine : le verdict a été sans appel.

Effectivement, c'est une problématique difficile, mais une fois de plus, permettre de choisir l'outil qu'on veut choisir parmi plusieurs, c'est pas mal, non ?

3) Auto_ARIMA. C'est un algo "automatique" permettant de trouver les paramètres optimum pour un calcul de prévisions (sur des données historisées) suivant un modèle ARIMA. C'est novateur, et je ne crois pas qu'il y ait vraiment d'équivalent ailleurs.

On parle là d'un cas spécifique, nécessitant un algorithme pas courant (sauf... en finance). Bref, PyIMSL est un complément, dans ce cas, à ce que propose Scipy.

En gros, mon avis est qu'on ne peut pas se permettre de "confier" des méthodes de calcul sophistiquées à de l'open source (bien que je sois de ceux qui pensent que l'open source soit l'avenir...). Un algo présent dans une librairie commerciale - si son éditeur fait bien son boulot - se doit d'avoir été passé au crible avant d'être releasé, afin qu'il puisse être utilisable immédiatement, facilement et l'esprit tranquille.

Préjugés. Ce que tu dis est purement absurde. Sincèrement. ATLAS, c'est pas aussi bien que les solutions commerciales ? C'est pas assez testé ? FFTW, c'est pas assez rapide et testé ? Matlab qui se base dessus, c'est tout de même gage de robustesse, non ?
Dans mon bientôt-ex-domaine de recherche, le logiciel principal utilisé par tout le monde en clinique, c'est un logiciel... en GPL.

Dans le monde de la recherche, on choisit une solution qui correspond à ce qu'on veut. On ne commence pas par virer toutes les solutions open source, au contraire. On cherche des solutions robustes qui ont fait leurs preuves. C'est le cas par exemple de netlib.

Bon, PyIMSL en est à sa 1ère version (ça fait une excuse pour le coup du réseaux de neurones dans les stats ). Son avenir va dépendre du succès qu'il va rencontrer (ou pas). Une chose est sûr : il devrait suivre les évolutions de la "plateforme Python" afin de rester accessible à la majorité des développeurs qui en seraient demandeurs. Je pense aussi aux universitaires et chercheurs qui disposent déjà de la librairie IMSL en C et qui développent en Python : ils seront ravis d'avoir la possiblité d'utiliser PyIMSL !

Exact, ils auront l'habitude des fonctionnalités, et si la compatibilité avec Numpy est fiable, ils utiliseront les autres solutions existantes pour tirer le meilleur de tout ce qui existe. Ne crois pas qu'ils n'utiliseront que PyIMSL parce que dans votre vision, c'est commercial donc c'est bien. Les mailing lists scipy et numpy montrent bien la vivacité croissante des outils open source pour les scientifiques (et je ne parle même pas de ce qu'on trouve sur le net).

Matthieu, pour le cas de prototypage rapide puis d'industrialisation de code, tu as tout compris.

Ca fait quelques temps que je travaille avec Python, et après avoir fait pas mal de recherches avec, sans compter les discussions avec les utilisateurs, je pense à peu près cerner ce à quoi il peut servir

Pour ceux qui veulent tenter l'expérience, PyIMSL et une version d'évaluation d'IMSL en C sont directement téléchargeables (gratuitement) depuis : ce lien.

Pour ceux qui auront tenté l'expérience (et même pour les autres, d'ailleurs !), vos commentaires sont les bienvenus sur ce forum dédié.

Je pense que je testerai bientôt, le temps de finir ma thèse

Pour conclure, je ne fais pas une charge contre PyIMSL, c'est bien de proposer des wrappers pour le meilleur langage pour les scientifiques Ce que je combats, c'est la confrontation Numpy/Scipy vs PyIMSL sous prétexte que l'un est commercial et pas l'autre (sachant que plusieurs sociétés sont derrière Numpy/Scipy qui vendent des logiciels basés sur ces bibliothèques). C'est déjà difficile de s'en sortir à cause des problèmes de compatibilité entre les bibliothèques, pour une fois qu'il semble qu'il y ait une compatibilité, cessons de dénigrer l'un ou l'autre.

[SebGR]

J'aimerai aussi voir cette étude, parce que pour le moment tout ce que je vois, c'est que Python est largement supérieur aux solutions usuelles pour la calcul scientifique. Et ça fait des années que les scientifiques utilisent Python (la communauté astronomique a été précurseur dans ce domaine, et on ne peut pas dire qu'ils peuvent utiliser n'importe quoi).

L'étude, Je vais essayer de mettre la main dessus ou, au moins d'avoir plus d'infos.
La communauté astronomique ? Ce sont des chercheurs, non ? Tu connais la raison pour laquelle ils utilisent Python ? Parce qu'ils... n'ont pas d'argent ! Les fonds qui leurs sont alloués sont dérisoires. Du coup, ils n'ont plus que le choix de l'open source. Tu peux y inclurent les CNRS (certains) CEA et les universitaires. Combien de fois avons-nous été contactés par des professeurs/PhD/chercheurs intéressés par IMSL mais ayant déclarés d'emblée : "nous sommes techniquement intéressés mais nous n'avons pas de budget ! Ben du coup, on va faire de l'open source". Ce que je dis ici vaut pour la France, mais pas pour les US.

Commercial et documenté, c'est orthogonal. Effectivement, Numpy avait des défaust à ce niveau, mais il y a tout de même sur scipy.org la liste complète des fonctions avec exemples. Et un marathon a été effectué pour remettre à jour les docstrings. Bref, cet argument ne tient pas.

La documentation d'IMSL a parcouru 41 kilomètres, le dernier sera couvert lorsque les réseaux de neurones voudront bien passer la ligne d'arrivée.
Simple question : que penses-tu de la qualité de l'une par rapport à l'autre ? J'ai (un peu) regardé, et je pense que mon argument tient.

Ah oui, le support de OS X pour PyIMSL ?

Cette plateforme est encore trop marginale sur le marché. Si la demande s'en fait sentir, un éventuel portage sera considéré.

Encore une orthogonalité. Si on se base sur des bibliothèques optimisées, on a une Porsche. Et c'est le cas de Numpy et de Scipy, je ne vois pas la même chose pour PyIMSL, donc la Porsche serait plutôt le couple Numpy/Scipy, non ? (et je ne parle même pas de Cython).
Et les astronomes, ils n'ont pas besoin d'une Porsche quand ils travaillent sur des Go de données ? Idem pour les traiteurs d'images 3D ?

Ca dépend ce que tu entends par "bibliothèques optimisées" : Optimisées par rapport à quoi ? Ce que recherche l'utilisateur, c'est d'abord une fonctionnalité qui colle à son besoin (critères fonctionnels, de précision, de robustesse, de rapidité...). Ensuite, le choix du langage est presque anecdotique.

Un problème purement politique.

Faux, c'est purement stratégique. Quel est leur but, sinon gagner plus d'argent que leurs concurrents ? J'ai travaillé sur plusieurs projets financiers "sensibles" (parties purement calculatoire) pour des grands groupes internationaux. Ils font (tous) le choix soit :
1) de gagner du temps en s'appuyant sur des librairies commerciales reconnues et prêtes à l'emploi ;
2) de prendre l'avantage sur leurs concurrents en développant leurs algos eux-mêmes en interne (les analystes quantitatifs). Dans ce cas, ils veulent "garder la main" sur leur(s) bébé(s).

Les R, Numerical Recipes et autres GSL sont éliminés dès le 1er round (je commence à connaitre leur chanson, depuis le temps...).

Ce n'est pas parce que c'est une bibliothèque commerciale que c'est meilleur qu'une solution Open Source. Dire que c'est une solution commerciale n'est pas équivalent à dire c'est le meilleur. Encore une fois, les préjugés ont la vie dure.

Je te serais gré de ne plus me prêter des propos que je n'ai jamais tenus.
Sinon, j'avertirais le modérateur.

scikits.openopt, permettant de sélectionner l'algorithme qu'on veut pour un problème spécifique parmi plusieurs optimiseurs y compris commerciaux existants avec une interface commune. Comme un optimiseur ne peut pas répondre à toutes les problématiques, c'est bien pratique.

Je ne connais pas.

Effectivement, c'est une problématique difficile, mais une fois de plus, permettre de choisir l'outil qu'on veut choisir parmi plusieurs, c'est pas mal, non ?

L'essentiel n'est pas de choisir, mais de choisir en connaissance de cause.

On parle là d'un cas spécifique, nécessitant un algorithme pas courant (sauf... en finance). Bref, PyIMSL est un complément, dans ce cas, à ce que propose Scipy.

Et dans les télécoms également : calcul de prévisions de traffic SMS
Ah, enfin ! Un complément ! Longtemps, j'ai eu l'impression que tu faisais le procès des librairies commerciales. Avec le mot complément, tu as parfaitement positionné le produit.

Préjugés. Ce que tu dis est purement absurde. Sincèrement. ATLAS, c'est pas aussi bien que les solutions commerciales ? C'est pas assez testé ? FFTW, c'est pas assez rapide et testé ? Matlab qui se base dessus, c'est tout de même gage de robustesse, non ?
Dans mon bientôt-ex-domaine de recherche, le logiciel principal utilisé par tout le monde en clinique, c'est un logiciel... en GPL.

ATLAS, je ne connais pas.
FFTW, LaPACK, ScaLAPACK etc... Tout ça c'est du ressucé : évidemment que ça a fait ses preuves, depuis le temps que ça existe, nous n'étions même pas nés (j'ai 34 ans) ! Mais combien d'utilisateurs en ont fait les frais auaparavant ?
Au passage : quand tu parles de Matlab et de robustesse dans la même phrase, ça me fait frémir. Surtout que tu fais du traitement d'images, non ?

Dans le monde de la recherche, on choisit une solution qui correspond à ce qu'on veut. On ne commence pas par virer toutes les solutions open source, au contraire. On cherche des solutions robustes qui ont fait leurs preuves. C'est le cas par exemple de netlib.

Les industriels (sérieux) commencent par une chose : ils testent plusieurs produits et choisissent en fonction des critères pondérés. Ils n'éliminent pas d'emblée l'open source comme tu le sous-entends.
Je peux juste te dire que d'après mon expérience, l'open source n'est pas souvent retenu pour ce qui me concerne.
Je peux aussi te dire (je pense que tu vas apprécier) qu'un truc bien à la mode en ce moment, c'est l'open source au sein du BI.

Ca fait quelques temps que je travaille avec Python, et après avoir fait pas mal de recherches avec, sans compter les discussions avec les utilisateurs, je pense à peu près cerner ce à quoi il peut servir

Je n'en doute pas un instant !

Et pour répondre à ton dernière paragraphe, comprends bien que je ne dénigre rien du tout: "je propose une (éventuelle) solution aux développeurs Python qui ne trouveraient pas leur bonheur dans Numpy/SciPy". Il n'y a rien de plus à dire !

Je pense que je testerai bientôt, le temps de finir ma thèse

Tes remarques seront les bienvenues !

Quelle est donc le sujet de ta thèse ?
Tu la présentes quand ?

Cordialement,
SebGR

[Matthieu Brucher]

La communauté astronomique ? Ce sont des chercheurs, non ? Tu connais la raison pour laquelle ils utilisent Python ? Parce qu'ils... n'ont pas d'argent ! Les fonds qui leurs sont alloués sont dérisoires. Du coup, ils n'ont plus que le choix de l'open source. Tu peux y inclurent les CNRS (certains) CEA et les universitaires. Combien de fois avons-nous été contactés par des professeurs/PhD/chercheurs intéressés par IMSL mais ayant déclarés d'emblée : "nous sommes techniquement intéressés mais nous n'avons pas de budget ! Ben du coup, on va faire de l'open source". Ce que je dis ici vaut pour la France, mais pas pour les US.

L'ensemble des outils Numpy et Scipy sont venus des US principalement (financement privé par Enthought)
J'ai oublié de parler d'ITK ou de VTK, qui malgré leurs gros inconvénients, sont pas mal utilisés.

Et c'est dommage pour la recherche française de ne pas pouvoir accès à des outils comme les vôtres. Mais bon, ça serait un autre débat

La documentation d'IMSL a parcouru 41 kilomètres, le dernier sera couvert lorsque les réseaux de neurones voudront bien passer la ligne d'arrivée.
Simple question : que penses-tu de la qualité de l'une par rapport à l'autre ? J'ai (un peu) regardé, et je pense que mon argument tient.

Complètement d'accord avec toi, la documentation d'ISML) est meilleure (grâce aussi à l'existence de la documentation dans les autres langages, ça aide tout de même).

Ca dépend ce que tu entends par "bibliothèques optimisées" : Optimisées par rapport à quoi ? Ce que recherche l'utilisateur, c'est d'abord une fonctionnalité qui colle à son besoin (critères fonctionnels, de précision, de robustesse, de rapidité...). Ensuite, le choix du langage est presque anecdotique.

Je te parle des BLAS et autres. C'est indépendant du langage. Effectivement, on cherche des fonctionnalités. Mais la moindre des choses est de déléguer le travail possible à une bibliothèque adaptée, qui est robuste, rapide, ...

Faux, c'est purement stratégique. Quel est leur but, sinon gagner plus d'argent que leurs concurrents ? J'ai travaillé sur plusieurs projets financiers "sensibles" (parties purement calculatoire) pour des grands groupes internationaux. Ils font (tous) le choix soit :
1) de gagner du temps en s'appuyant sur des librairies commerciales reconnues et prêtes à l'emploi ;
2) de prendre l'avantage sur leurs concurrents en développant leurs algos eux-mêmes en interne (les analystes quantitatifs). Dans ce cas, ils veulent "garder la main" sur leur(s) bébé(s).

Les R, Numerical Recipes et autres GSL sont éliminés dès le 1er round (je commence à connaitre leur chanson, depuis le temps...).

Gagner de l'argent, c'est indépendant du type de licence du support, non ? Si l'open source propose des fonctionnalités permettant de gagner plus d'argent que les solutions commerciales, ils prendraient le premier, non ? Enfin, j'espère pour eux...

Je te serais gré de ne plus me prêter des propos que je n'ai jamais tenus.
Sinon, j'avertirais le modérateur.

Arf
J'ai peut-être légèrement déformé tes propos, mais le fond y est. Tu dis que le commercial, c'est mieux que l'open source (alors que l'un n'empêche pas l'autre).

Je ne connais pas.

L'essentiel n'est pas de choisir, mais de choisir en connaissance de cause.

Et dans les télécoms également : calcul de prévisions de traffic SMS
Ah, enfin ! Un complément ! Longtemps, j'ai eu l'impression que tu faisais le procès des librairies commerciales. Avec le mot complément, tu as parfaitement positionné le produit.

C'est l'impression que j'avais de toi au début aussi. Il faut choisir en connaissance de cause et prendre le meilleur dans chaque problématique. L'impression que j'avais, c'était Numpy, Scipy, à la trappe, on prend juste PyIMSL parce que c'est le meilleur, il y a la meilleure doc.

ATLAS, je ne connais pas.
FFTW, LaPACK, ScaLAPACK etc... Tout ça c'est du ressucé : évidemment que ça a fait ses preuves, depuis le temps que ça existe, nous n'étions même pas nés (j'ai 34 ans) ! Mais combien d'utilisateurs en ont fait les frais auaparavant ?

Et combien en font encore les frais actuellement ? (surtout pour compiler ATLAS, l'implémentation libre de BLAS, LAPACK, mais qui est très performante)
L'intérêt de les conserver, c'est que c'est robuste maintenant (grosse batterie de test), rapide, et qu'on peut choisir le meilleur pour son processeur.

Au passage : quand tu parles de Matlab et de robustesse dans la même phrase, ça me fait frémir. Surtout que tu fais du traitement d'images, non ?

C'est clair que je ne suis pas le plus grand fan de Matlab, mais force est de constater que c'est un outil utilisé partout, malgré ses défauts, car il bénéficie d'une grande communauté d'utilisateurs et d'un grand nombre de fonctionnalités. Et très performant en terme de calcul vectoriel.

Les industriels (sérieux) commencent par une chose : ils testent plusieurs produits et choisissent en fonction des critères pondérés. Ils n'éliminent pas d'emblée l'open source comme tu le sous-entends.
Je peux juste te dire que d'après mon expérience, l'open source n'est pas souvent retenu pour ce qui me concerne.
Je peux aussi te dire (je pense que tu vas apprécier) qu'un truc bien à la mode en ce moment, c'est l'open source au sein du BI.

Dans mon futur-ex-domaine, c'est l'outil principal, dans mon nouveau domaine, c'est moitié open-source, moitié commercial (enfin, je ne connais pas les proportions, mais de nombreux outils sont basés sur des projets en licence BSD par exemple).

Et pour répondre à ton dernière paragraphe, comprends bien que je ne dénigre rien du tout: "je propose une (éventuelle) solution aux développeurs Python qui ne trouveraient pas leur bonheur dans Numpy/SciPy". Il n'y a rien de plus à dire !

Grâce au support de Numpy, je pense que PyIMSL permettra de résoudre certaines problématiques plus facilement, toujours en assemblant les outils avec la meilleure fonctionnalité pour le problème posé. En tout cas, j'espère que vous continuerez à développer PyIMSL, car Python est le meilleur langage pour tester rapidement (bien plus pratique que le C, le C# ou Java), et il est nécessaire d'avoir un maximum de choix différents. Et si par la suite on bascule en partie vers du C/C++/... c'ets mieux d'avoir une bibliothèque intermédiaire à attaquer.

Tes remarques seront les bienvenues !

Vous avez sans doute des retours de clients (sans compter les projets internes) bien plus pertinents

Quelle est donc le sujet de ta thèse ?
Tu la présentes quand ?

Octobre si tout va bien. C'est de l'apprentissage non supervisé de variétés non linéaires, avec application au traitement d'image.

[SebGR]

L'ensemble des outils Numpy et Scipy sont venus des US principalement (financement privé par Enthought)
J'ai oublié de parler d'ITK ou de VTK, qui malgré leurs gros inconvénients, sont pas mal utilisés.

Et c'est dommage pour la recherche française de ne pas pouvoir accès à des outils comme les vôtres. Mais bon, ça serait un autre débat

On fait pourtant de gros efforts proposer des offres commerciales attractives, car nous sommes conscients des contraintes budgétaires de ce secteur...

Je te parle des BLAS et autres. C'est indépendant du langage. Effectivement, on cherche des fonctionnalités. Mais la moindre des choses est de déléguer le travail possible à une bibliothèque adaptée, qui est robuste, rapide, ...

Ah, OK. IMSL en C repose effectivement sur les BLAS. Selon ta plateforme, tu peux te plugger sur ESSL, MKL, SunPerf et profiter d'une architecture SMP. S'agissant de PyIMSL, je ne sais pas trop comment ça se goupille au travers du wrapper...

Gagner de l'argent, c'est indépendant du type de licence du support, non ? Si l'open source propose des fonctionnalités permettant de gagner plus d'argent que les solutions commerciales, ils prendraient le premier, non ? Enfin, j'espère pour eux...

Evidemment. A fonctionnalités strictement équivalentes, un client sain d'esprit va prendre la solution la moins chère. Cela dit, certains acheteurs ne sont pas spécialement moteurs pour faire gagner de l'argent à leur entreprise : ils préfèrent parfois la facilité (puisque ce ne sont pas eux qui paient "directement" de leurs poches).

Arf
J'ai peut-être légèrement déformé tes propos, mais le fond y est. Tu dis que le commercial, c'est mieux que l'open source (alors que l'un n'empêche pas l'autre).


C'est l'impression que j'avais de toi au début aussi. Il faut choisir en connaissance de cause et prendre le meilleur dans chaque problématique. L'impression que j'avais, c'était Numpy, Scipy, à la trappe, on prend juste PyIMSL parce que c'est le meilleur, il y a la meilleure doc.

Tu sais, je ne crois pas avoir grand chose à gagner ici : j'apprécie la discussion et le débat, le mois d'août est plutôt calme au bureau. Je ne m'attends pas à ce que ces quelques posts sur PyIMSL changent la face du monde. Vu le temps que j'ai passé à argumenter, je pense que ma société perd même de l'argent !

Grâce au support de Numpy, je pense que PyIMSL permettra de résoudre certaines problématiques plus facilement, toujours en assemblant les outils avec la meilleure fonctionnalité pour le problème posé. En tout cas, j'espère que vous continuerez à développer PyIMSL, car Python est le meilleur langage pour tester rapidement (bien plus pratique que le C, le C# ou Java), et il est nécessaire d'avoir un maximum de choix différents. Et si par la suite on bascule en partie vers du C/C++/... c'ets mieux d'avoir une bibliothèque intermédiaire à attaquer.

Et pour info, si tu veux appeler des librairies maths et stats depuis IronPython ou Jython, il y a aussi (respectivement) IMSL C# et JMSL.

Vous avez sans doute des retours de clients (sans compter les projets internes) bien plus pertinents

Cela reste un marché de niche. Le lancement de PyIMSL a été effectué il y a quelques jours, attendons un peu pour voir quel en sera l'accueil.

Octobre si tout va bien. C'est de l'apprentissage non supervisé de variétés non linéaires, avec application au traitement d'image.

Ah... d'accord, j'ai compris : c'est pour travailler dans l'audiovisuel. "le traitement d'image des variétés super télévisées"

Eh bien... bon courage, et mes amitiés à Guy Lux.


SebGR

[Matthieu Brucher]

Ah... d'accord, j'ai compris : c'est pour travailler dans l'audiovisuel. "le traitement d'image des variétés super télévisées"

Mort de rire

Je constate d'après tes réponses que IMSL se base au moins en partie sur les meilleures bibliothèques pour faire du calcul, ce qui, à la réflexion, ne m'étonne qu'à moitié (et PyIMSL se basant sur IMSL, il bénéficie automatiquement des avantages du second). Une bonne alternative à Scipy

[SebGR]

Bonjour,

Je fais remonter cette discussion pour y ajouter un lien vers un tutoriel (et le code qui va bien) illustrant l'intérêt de PyIMSL Studio, non seulement pour les développeurs Python, mais aussi pour ceux qui désirent prototyper et industrialiser facilement une application scientifique.

Vos commentaires et remarques sont forcément les bienvenus.

-SebGR