L'annonce a été faite lors du 2ème séminaire du Groupe Thématique Logiciel Libre du pôle de compétitivité System@tic.
NdM : nous avons souvent par le passé ajouté des NdM sur les dépêches évoquant Scilab, concernant sa licence. Il nous semble donc adéquat aujourd'hui de nous réjouir de ce passage sous une licence de logiciel libre et remercier l'INRIA d'avoir travaillé à la libération de son logiciel. L'équipe de Scilab a travaillé d'arrache-pieds pour arriver à cette publication sous une nouvelle licence, cette fois réellement libre, notamment en faisant un audit complet du code pour s'assurer que les contributions faites pendant les 20 dernières années étaient toutes publiables sous CeCill, et sinon, pour réécrire les éléments manquants.
Au 1er juillet, le consortium Scilab devrait quitter le giron de l'INRIA pour intégrer la fondation de coopération scientifique du RTRA Diiteo, ce qui lui permettra, selon ses leaders actuels, de se développer de façon plus efficace, en restant toujours dans une perspective non-commerciale.
Avec cette nouvelle licence, une nouvelle version plus mature et une nouvelle structure pour le Consortium, Scilab vise à être d'ici 2012 une solution réellement alternative à Matlab, et cette fois vraiment libre.
Aller plus loin
- Présentation au séminaire System@tic (21 clics)
- Scilab (112 clics)
- Release Scilab 5.0 beta 2 (16 clics)
- Nouveau consortium (7 clics)
- Digiteo (4 clics)
# Bonne nouvelle! vague de libération!
Posté par glattering . Évalué à 4.
Matlab est vraiment l'outil qui me manque le plus sous Linux (et surtout chez moi à la maison, là où je ne peux pas me payer une liscense à 10000 dollars)
[^] # Re: Bonne nouvelle! vague de libération!
Posté par MiniMoi . Évalué à 2.
Après, il reste le problème de la licence... Mais pour un usage basique (celui que j'avais), Python + quelques packages me semblaient bien meilleur, parce que je déteste vraiment la syntaxe de Matlab, et tous les petites inconsistences et limitations dans le langage...
[^] # Re: Bonne nouvelle! vague de libération!
Posté par PegaseYa . Évalué à 1.
Si tu as matlab sous windows, tu peux pour le même prix l'avoir sous linux. J'ose espérer que tu l'as bien payé...
[^] # Re: Bonne nouvelle! vague de libération!
Posté par Mildred (site web personnel) . Évalué à 2.
Dans le cadre de mes études, je dois l'utiliser (et je ne peux malhereusement pas utiliser scilab ... le prof utilise matlab, donc nous aussi). Dans certains TP j'ai pu utiliser octave qui cherche à cloner matlab, mais pas souvent.
Là où j'ai eu des problèmes, c'est quand le prof avait compilé une DLL (donc pour Windows) d'un certain module simulink ... pour qu'on ne puisse pas voir le code source. Le but était d'identifier le système comme boîte noire.
Et là, bien sûr, ça ne pouvait pas marcher.
[^] # Re: Bonne nouvelle! vague de libération!
Posté par brunus (site web personnel) . Évalué à 3.
# Octave
Posté par neologix . Évalué à 6.
A comparer à Scilab.
[^] # Re: Octave
Posté par Troy McClure (site web personnel) . Évalué à 0.
[^] # Re: Octave
Posté par arnaudus . Évalué à 8.
[^] # Re: Octave
Posté par Troy McClure (site web personnel) . Évalué à 4.
Mon humble avis est que gnuplot aurait du mourir il y a 15 ans. ça aurait permis l'apparition d'un remplaçant mieux foutu, qui ne se limite pas à 15 couleurs (dont un jaune et un vert particulièrement ignobles sur lesquels des generations de scientifiques se sont explosés la rétine -- ok la version 4 a fait des progrès sur les couleurs), qui soit scriptable (ça eviterait la multiplication des options. Y'en a combien dans gnuplot des flags et des switchs ? 1000 ? 10000 ? Si tu compares au nombre d'options disponibles sous matlab c'est incommensurable. Et pourtant les graphiques matlab sont bien plus puissants.
Si gnuplot avait sombré dans l'oubli ça aurait forcé les projets du genre octave et assimilés à faire un vrai effort sur la partie graphique au lieu de se livrer à des bricolages à base de pipes et de scotch pour essayer de reutiliser gnuplot. En fait c'est octave (ou scilab) qui aurait du remplacer gnuplot. Le monde s'en porterait mieux
[^] # Re: Octave
Posté par abramov_MS . Évalué à 7.
http://matplotlib.sourceforge.net/
Pour la 3D il vaut mieux voir du cote de mayavi2
https://svn.enthought.com/enthought/wiki/MayaVi
[^] # Re: Octave
Posté par Cédric Chevalier (site web personnel) . Évalué à 4.
À propos de Scotch (http://gforge.inria.fr/projects/scotch/ ), il est maintenant disponible dans debian, mais je vois pas trop en quoi il est utile à Octave ou Gnuplot.
[^] # Re: Octave
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: Octave
Posté par Christophe Duparquet (site web personnel) . Évalué à 7.
S'il n'a pas sombré dans l'oubli, c'est parce qu'il a des utilisateurs et je ne vois pas en quoi cela gène l'apparition d'un « remplaçant mieux foutu ».
Je ne suis pas sûr que vouloir enterrer un logiciel sous prétexte qu'il n'est pas parfait et que d'autres s'appuient dessus soit la meilleure façon de promouvoir le libre.
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Octave
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: Octave
Posté par djibb (site web personnel) . Évalué à -1.
[^] # Re: Octave
Posté par briaeros007 . Évalué à 1.
C'est pas plutot pour les stats ?
(rem moi ca me convient, je cherchais justement un truc comme ça! XD)
[^] # Re: Octave
Posté par Yusei (Mastodon) . Évalué à 4.
Par contre, en n'y passant que quelques heures à chaque fois que je m'y intéresse, je n'ai pas réussi à avoir des graphiques aussi jolis (ou moins moches) que ceux de Gnuplot, et je n'ai pas retrouvé la simplicité d'utilisation et de scriptage qui me fait utiliser Gnuplot pour tracer des trucs à partir de mes logs de simulations.
J'ai l'impression que R est plus intéressant si on s'en sert pour traiter les données, pas seulement pour tracer.
[^] # Re: Octave
Posté par tinou . Évalué à 2.
Du reste, les capacités graphiques ne sont pas l'objet du dévelopement d'Octave, qui sous-traîte à Gnuplot. De plus, la finalité d'un graphique n'est pas d'être joli, mais de mettre en ordre les données sous une forme qui facilite la compréhension au premier coup d'oeil. Enfin, je ne vois pas en quoi piloter gnuplot via un pipe empêche de faire quelque chose de robuste et rapide. Je ne conteste pas que l'interactivité manque, après, je me demande juste si elle est nécessaire, à part pour afficher en temps réel les coordonnées du point en-dessous duquel se trouve le pointeur de la souris.
[^] # Re: Octave
Posté par Troy McClure (site web personnel) . Évalué à 2.
Eh bien je considère que c'est une grosse erreur. La presentation graphique des données est *cruciale* et se doit d'etre parfaitement integrée. Et elle a besoin d'interactivité.
> la finalité d'un graphique n'est pas d'être joli
Ce n'est peut etre pas la finalité, mais ça aide *beaucoup* a faire passer le message. Et assurer un minimum de lisibilité c'est bien (oui je pense encore aux courbes vertes et jaunes de gnuplot)
> e ne vois pas en quoi piloter gnuplot via un pipe empêche de faire quelque chose de robuste et rapide.
J'imagine que tu n'as jamais comparé le temps necessaire pour faire un plot de 100000 points sous matlab et sous octave. Et que tu n'as jamais fait "Ctrl-C" dans octave après avoir attendu 3 minutes qu'il daigne t'afficher le graphique (ça dechire le pipe qui deverse ses données dans ton terminal, super robuste)
> je me demande juste si elle est nécessaire, à part pour afficher en temps réel les coordonnées du point en-dessous
Il y a au moins la rotation du graphique quand on affiche des objets 3D (heureusement gnuplot ne sait pas faire ça, a part avec quelques surfaces 3d très limitées). Et ensuite des choses plus evolués avec des callbacks etc.
[^] # Re: Octave
Posté par tinou . Évalué à 1.
> Ce n'est peut etre pas la finalité, mais ça aide *beaucoup* a faire passer le message. Et assurer un minimum de lisibilité c'est bien.
Pour moi, la lisibilité, c'est le travail de l'utilisateur, pas celui de l'outil qu'il utilise. J'irais même jusqu'à dire qu'un graphique lisible doit pouvoir se comprendre quand il est affiché en noir et blanc (mais c'est peut-être à force de bosser avec un chef daltonien ...)
> J'imagine que tu n'as jamais comparé le temps necessaire pour faire un plot de 100000 points sous matlab et sous octave.
C'est vrai, je n'ai jamais comparé. Je crois que la plupart de mes programmes voit sa sortie mettre nettement plus de temps à se calculer qu'à s'afficher ... Mais si lenteur il y a, la mettre juste sur le dos du pipe ??
> Et que tu n'as jamais fait "Ctrl-C" dans octave après avoir attendu 3 minutes qu'il daigne t'afficher le graphique (ça dechire le pipe qui deverse ses données dans ton terminal, super robuste)
Je ne me souviens pas avoir vu ça. Je reconnais que c'est pas très propre.
[^] # Re: Octave
Posté par tipote . Évalué à 1.
>>Ce n'est peut etre pas la finalité, mais ça aide *beaucoup* a faire passer le message. Et assurer un minimum de lisibilité c'est bien.
>Pour moi, la lisibilité, c'est le travail de l'utilisateur, pas celui de l'outil qu'il utilise. J'irais même jusqu'à dire qu'un graphique lisible doit pouvoir se comprendre quand il est affiché en noir et blanc (mais c'est peut-être à force de bosser avec un chef daltonien ...)
Je suis d'accord avec ce dernier point, un graphe de qualité est aussi un graphe qui est lisible en noir et blanc. J'ai en effet des collègues daltoniens, et en plus l'imprimante du bureau est, comme dans bien des endroits, noir et blanc. De ce côté, gnuplot fait un très bon bouleau, l'export en postscript en noir et blanc produit des lignes en pointillés bien distinguables.
Je rajouterais qu'un bon logiciel de graphe doit être capable d'exporter dans tous les formats dont j'ai besoin : postscript (ou pdf) pour l'impression, pdf pour l'envoi par courrier électronique, svg (ou pdf) pour l'édition ultérieure, png également, mais aussi latex. Matplotlib gère bien le pdf depuis les dernières versions (merci à http://www.cairographics.org ), mais pas le latex. Gnuplot fait tout ça, et il le fait bien (le pdf avec cairo, c'est encore dans le CVS et pas en version officielle, mais ça vient!).
# Python
Posté par SaintGermain . Évalué à 8.
En effet le noyau de calcul de Matlab s'appuie (je crois) en partie sur les bibliothèques de calcul lapack et blas.
Les modules Scipy et Numpy ont développé une surcouche (c'est un peu réducteur mais c'est l'idée) qui permet d'avoir à peu près les mêmes fonctionnalités algorithmiques que Matlab.
Si on ajoute à cela les fonctionnalités graphiques de matplotlib, les différentes boîtes à outils graphique (pyGTK, pyQT, wxPython) et l'excellent interpréteur Ipython, on arrive à recouvrir une grosse partie des fonctions les plus utilisées de Matlab.
Et avec Python on ouvre la porte à un grand nombre d'autres bibliothèques et avec un langage beaucoup plus 'propre' que celui de Matlab.
[^] # Re: Python
Posté par アントニ ドミ . Évalué à 4.
Sous Windows c'est la misère de devoir faire du Python dans les "consoles DOS" :'(
[^] # Re: Python
Posté par SaintGermain . Évalué à 5.
Il est vraiment pas mal du tout et est même compatible avec matplotlib en mode interactif (pour peu que tu configures en "shell externe").
Il y a aussi Wing IDE je crois qui est très bien fichu (mais payant).
Moi j'utilise emacs-NT avec Ipython et ça fonctionne très bien...
[^] # Re: Python
Posté par Larry Cow . Évalué à 2.
Bon ok, c'est pas excessivement sexy, et c'est limité en diable. Mais c'est pas non plus une "console DOS". Faut pas exagérer.
[^] # Re: Python
Posté par アントニ ドミ . Évalué à 2.
[^] # Re: Python
Posté par abramov_MS . Évalué à 3.
Avoir une interface "a la matlab" pour python cela reduirait les possibilites du langage qui sont bien plus etendu que ce que propose matlab. Il est vrai que des outils plus graphiques seraient bienvenu en particulier pour les windowsiens mais bon pour le moment le travail essentiel se situe a ameliorer numpy et tous les logiciels en dependant (scipy et matplotlib pour ne citer qu'eux) et en particulier la documentation associe qui souffre de leger problemes et manques (1) actuellement. Cet ete un gros effort est prevu pour cela et j'invite toutes les personnes interesse a aller sur les mails listes de numpy/scipy pour aider sur ce point crucial.
(1) dans ipython, par exemple, de tres nombreuses fonctions n'ont pas de documentations accessible avec un: help foo
[^] # Re: Python
Posté par scls19fr (site web personnel) . Évalué à 2.
Parlons par exemple du domaine de la régulation, du traitement du signal, etc...
Existe-il actuellement un moyen de définir
- un fonction de tansfert
- un espace d'état (space state)
Existe-il des graphes genre
Diagramme de Bode
Diagramme de Nyquist
Diagramme de Black
Est-il possible de faire des transformées en z ?
Obtenir une équivalence en un modèle continu et un modèle discret ?
[^] # Re: Python
Posté par Gilles G. . Évalué à 3.
- un fonction de tansfert
- un espace d'état (space state)
Les réponses sont oui.
Pour ce qui est du traitement du signal, voir le module scipy.signal qui a tout ce qui tu veux.
<c ite>Existe-il des graphes genre
Diagramme de Bode
Diagramme de Nyquist
Diagramme de Black
Tu dois pouvoir faire cela avec matplotlib.
Et oui, Python/Numpy/Scipy est une réelle alternative à matlab.
# Pas encore farfait ;-)
Posté par Pol' uX (site web personnel) . Évalué à 1.
C'est tout de même une bonne nouvelle pour Scilab, cette libération. Amha ce logiciel à des bases solides (il roxe, en calcul !) mais il lui manque atrocement des utilisateurs, et des contributions d'utilisateur. Maintenant, si tout cet écosystème peut se mettre en oeuvre, je pense qu'un certain nombre de mauvais choix (e.g. ergonomie) liés à ce logiciel vont pouvoir s'estomper, de façon à ce qu'on dispose d'un puissant outil pour les mathématiques appliquée.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas encore farfait ;-)
Posté par TNorth . Évalué à 1.
http://bugzilla.scilab.org/index.cgi
[^] # Re: Pas encore farfait ;-)
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
[^] # Re: Pas encore farfait ;-)
Posté par Pol' uX (site web personnel) . Évalué à 1.
Enfin bon, je pourrais reporter, quand j'aurais le temps.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas encore farfait ;-)
Posté par TNorth . Évalué à 1.
[^] # Re: Pas encore farfait ;-)
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
[^] # Re: Pas encore farfait ;-)
Posté par Sylvestre Ledru (site web personnel) . Évalué à 3.
# presque... encore un petit effort!
Posté par oliv . Évalué à 2.
Mais quand on regarde les "release-notes", on tombe sur le bémol suivant.
"Some license issues have not been fixed."
http://www.scilab.org/download/index_download.php?page=RELEA(...)
Mais c'est super de voir un langage de la famille de Matlab devenir libre. J'ai toujours trouvé plus de potentiel à Scilab qu'à Octave, mais le dernier Octave commençait à rattraper son retard...
En plus, Scilab et Octave contiennent de nombreux ajouts (toolboxes) qui coûtent une fortune chez Matlab.
[^] # Re: presque... encore un petit effort!
Posté par Sylvestre Ledru (site web personnel) . Évalué à 5.
Il y a encore des choses à enlever/remplacer. Exemple, l'optimisation quadratique dans Scilab est sous une licence "on vous donne le droit de le mettre dans votre software mais seulement à vous"; faut donc le remplacer par quelque chose d'autre... Et faire les tests puis intégrer, ça prend du temps mais on avance...
# Et Scicos?
Posté par Maclag . Évalué à 5.
Je m'en sers quasi tous les jours en toute tranquilité, ça m'a évité de demander une licence matlab à mon boss (enfin, on l'aurait piraté quoi, je bosse en Chine quand même...).
Par contre, il y a un autre truc qui manque cruellement en équivalent libre: l'excellent Labview (proprio, tout ça). Celui-là on le paie, par contre, et c'est pas donné.
Hors, il me semble que Scicos pourrait devenir une alternative viable à Labview. Et le développement de Scicos est assez lié à celui de Scilab.
Alors, Scicos, il fait partie des plans?
[^] # Re: Et Scicos?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 3.
http://www.scilab.org/developers/index_developers.php?page=r(...)
[^] # Re: Et Scicos?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Autant je pense que pas mal de programme Matlab pourrait être écrit sous Scilab, autant j'ai des doutes de virer Labview de mon laboratoire avant des années !
[^] # Re: Et Scicos?
Posté par Maclag . Évalué à 3.
Des cartes d'acquisitions, ça se trouve!
Par contre, nous on utilise des cartes d'acquisition et des générateurs de signaux, le tout piloté par Labview.
Virer Labview, peut-être pas pour tout de suite, mais au moins avoir un début d'alternative, ce sera bien!
[^] # Re: Et Scicos?
Posté par freejeff . Évalué à 4.
Il permet d'utiliser tout un tas de cartes dont beaucoup de NI.
J'ai personnellement acheté une carte USBDUX, car toute son architecture est open source et tous les programmes et drivers aussi.
On peut utiliser n'importe quelle carte d'acquisition compatible comedi depuis scicos. Il existe deux modules permettant de faire cela, Hardware In Loop qui comme son nom l'indique permet de faire tourner la carte directment dans scilab/scicos, mais aussi RTAI qui est bien plus compliqué à faire fonctionné puisqu'il nécessite l'installation d'un noyau RT.
En bref, même si ce n'est pas aussi convivial que LabView, il existe des moyens de faire de l'acquisition et du pilotage en open source.
[^] # Re: Et Scicos?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: Et Scicos?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
http://www.scilab.org/contactus/index_contactus.php?page=mai(...)
[^] # Re: Et Scicos?
Posté par tinou . Évalué à 1.
http://pyvisa.sourceforge.net/
Bon, j'ai pas encore essayé. ;-)
[^] # Re: Et Scicos?
Posté par tipote . Évalué à 1.
J'utilise un oscilloscope Agilent série 6000 pour faire de l'acquisition de données sur 4 voies. L'oscilloscope est connecté en usb2. Le programme tourne sous Windows, essentiellement parce que j'ai aussi d'autres instruments à contrôler qui n'ont pas de pilotes linux, et est construit de la sorte :
- sous-couche VISA fournie par Agilent (la seule partie non-libre),
- pyvisa
- numpy & scipy four le traitement de données
- pyqt pour l'interface graphique, avec pyqwt pour les graphes en tant que tels
Honnêtement, ça fonctionne remarquablement bien, et c'est particulièrement agréable de pouvoir écrire ainsi un programme dédié aussi rapidement avec tous ces éléments de qualité !
# Scilab/Octave/Python?
Posté par michelj . Évalué à 2.
Cecill puisque Cecill+GPL => GPL ? il aurait été plus simple de passer
directement à GPL, a moins de ne pas incorporer du GPL dans Scilab?
Pour quelqu'un qui vient de Matlab, Octave est un meilleur choix: on
retrouve la meme syntaxe et les memes fonctions.
Octave a toujours passé sans problèmes tous mes fichiers
mfiles venant de Matlab, alors que le traducteur Matlab-Scilab est affreux.
Le code traduit est toujours illisible, souvent faux, et toujours beaucoup
beaucoup plus lent.
Pour le graphique Scilab est mieux et c'est vrai que le passage par Gnuplot
dans Octave n'est pas terrible...
Octave est aussi bien plus moderne que Scilab qui avait encore récemment
un interprete en Fortran (77! trente ans déjà!) qui utilisait une grosse
pile statique qui empèchait d'utiliser des gros fichiers.
(La derniere version de Scilab5 en beta travaille enfin en dynamique...
A vérifier?).
Le vrai plus de Scilab, c'est Scicos qui malheureusement n'est toujours
pas compatible avec Simulink mais permet de faire plein de jolies simulations.
Bizzarement, il y a une aussi interface LabView/Scilab qui fonctionne sous
Windows uniquement (?). Pas très logiciel libre ...
Mais finalement, est-ce que la licence libre de Scilab n'arrive pas trop tard ?
A coté de SciPy et NumPy, ou Sage que peut faire Scilab ?
Le jour ou Python aura son Simulink que fera Scilab ?
Etre libre c'est bien, mais donner l'impression de devenir libre parce
que le modèle précédent (avec des membres payants et des contributeurs libres)
a foiré, c'est pas top pour avoir, avec des années de retards, des contributeurs du libre.
On voit mal les contributeurs Octave passer à Scilab (et encore plus mal
la communauté Python qui est la seule alternative crédible à Matlab), mais on
peut toujours réver...
[^] # Re: Scilab/Octave/Python?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2.
Bienvenue ceci dit
[^] # Re: Scilab/Octave/Python?
Posté par TeXitoi (site web personnel) . Évalué à 3.
Cecill puisque Cecill+GPL => GPL ? il aurait été plus simple de passer
directement à GPL, a moins de ne pas incorporer du GPL dans Scilab?
La licence CeCILL est co-écrite par l'INRIA (d'où le I de CeCILL), et il y a donc une explication. La licence CeCILL est en francais (ainsi qu'en anglais). CeCILL est une licence qui colle plus au droit européen, vu que basé sur le droit d'auteur et non le copyright. Ainsi, les juristes de l'INRIA peuvent valider cette licence.
Ensuite, comme la CeCILL est explicitement compatible avec la GPL, ca ne te restreint pas dans l'utilisation de scilab.
[^] # Re: Scilab/Octave/Python?
Posté par Sylvestre Ledru (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.