Calcul scientifique : Scilab 5 enfin libre

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
0
30
mai
2008
Science
La version 5.0bêta2 du logiciel de calcul scientifique Scilab est publiée, et enfin sous une licence libre (la CeCill). La version finale 5.0 doit sortir courant juin. Mais on peut désormais intégrer Scilab dans les distributions de logiciels libres sans états-d'âme. On se souvient des nombreux débats parfois houleux ayant opposé les tenants de la communauté du Logiciel Libre aux promoteurs du projet, sur la nature "open source" de ce logiciel, par ailleurs une excellente solution de calcul scientifique, alternative au logiciel propriétaire Matlab, leader du secteur.

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

  • # Bonne nouvelle! vague de libération!

    Posté par  . Évalué à 4.

    Et bien je ne peux que me réjouir de cette décision (et mise en oeuvre) et perspective de developpement pour scilab!
    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  . Évalué à 2.

      Pour avoir utilisé Matlab sous Linux, je peux dire que ça marche, sauf en cas d'utilisation de certains modules externes un peu exotiques...

      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  . Évalué à 1.

        Pour confirmer, je fais tourner matlab sur un cluster de calcul SGI foncitonnant sous linux (suse), avec pas mal de bibliothèques, et toutes fonctionnent sous linux.

        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  (site web personnel) . Évalué à 2.

        Oui ça marche (Java powered ...)
        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  (site web personnel) . Évalué à 3.

      Je me suis laissé dire, par le développeur de la distribution LIVE-CD universitaire Artouste, que la combinaison Scilab + R couvrait les besoins d'utilisateurs de matlab qui préfèrent utiliser des outils libres ou presques libres (anciennes versions de scillab).

  • # Octave

    Posté par  . Évalué à 6.

    Je ne connais pas Scilab, mais j'ai toujours utilisé Octave, qui est un équivalent à Matlab, compatible avec sa syntaxe/scripts, et qui marche très bien. On peut faire des trucs marrants, comme fft, ondelettes, et plein d'autres trucs en utilisant les plugins octave-forge. Le seul truc qui manquait, la dernière fois que j'ai jeté un oeil, c'était une interface graphique (utile lorsqu'on a des figures).
    A comparer à Scilab.

    • [^] # Re: Octave

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

      malheureusement octave c'est pas mal buggé, très lent, et les capacité graphiques font un peu pitié (piloter l'immonde gnuplot via un pipe c'est pas le top pour faire quelque chose d'un peu robuste, rapide, et interactif). Par contre la compatibilité matlab est un gros avantage etant donné l'hégémonie de mathworks dans la recherche et l'éducation

      • [^] # Re: Octave

        Posté par  . Évalué à 8.

        Ouais, bon, et à part des attaques gratuites? Que tu n'aimes pas un logiciel c'est ton droit, mais bon de là à parler d'"immonde" et de "faire pitié"... Pour ma part, j'utilise gnuplot en alternance avec R pour produire des sorties graphiques, et je trouve les graphes gnuplot de meilleure qualité, et ma productivité est plus élevée avec gnuplot (options intuitives, aide bien foutue, défauts adéquats). En tout cas, les sorties postscript sont de qualité tout à fait professionnelle --surtout en noir et blanc, pour la couleur c'est très clean mais il y a moins de flexibilité. Bon, faut avouer aussi que gnuplot est extrêmement faiblard sur les histogrammes. J'imagine que ça dépend énormément de ce dont tu as besoin, évidemment.

        • [^] # Re: Octave

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

          > Que tu n'aimes pas un logiciel c'est ton droit, mais bon de là à parler d'"immonde" et de "faire pitié".

          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  . Évalué à 7.

            regarde un peu du cote de matplotlib pour des graphes 2D beaux et avec la puissance de python derriere. Ce logiciel a encore quelques defauts. Je citerais en particulier la gestion des grosses images (ca devient lent en particulier a cause du passage en rvb) et le cassage regulier de l'API (normal le projet est jeune et pas encore en version 1) autrement c'est que du bonheur.

            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  (site web personnel) . Évalué à 4.

            bricolages à base de pipes et de scotch
            À 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  (site web personnel) . Évalué à 7.

            Si gnuplot avait sombré dans l'oubli...

            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  (Mastodon) . Évalué à 3.

            J'aimerais bien savoir comment Gnuplot pourrait sombrer dans l'oubli avant qu'un concurrent mieux foutu apparaisse...

            • [^] # Re: Octave

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

              R est pas mal...

              • [^] # Re: Octave

                Posté par  . Évalué à 1.

                R ? ce R là : http://www.r-project.org/ ?
                C'est pas plutot pour les stats ?
                (rem moi ca me convient, je cherchais justement un truc comme ça! XD)

                • [^] # Re: Octave

                  Posté par  (Mastodon) . Évalué à 4.

                  C'est pour les stats, et ça possède un module graphique qui sait faire plein de choses.

                  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  . Évalué à 2.

        Buggé ? Où ça ?

        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  (site web personnel) . Évalué à 2.

          > les capacités graphiques ne sont pas l'objet du dévelopement d'Octave, qui sous-traîte à Gnuplot.

          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  . Évalué à 1.

            > > 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.

            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  . Évalué à 1.

              >>>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.
              >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  . Évalué à 8.

    Personnellement j'ai eu d'excellents résultats pour les portage Matlab -> Python.

    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.

      Je plussoie fortement. A mon avis, il manque qu'une chose à Python, c'est d'avoir une GUI user-friendly (comme celle de matlab).

      Sous Windows c'est la misère de devoir faire du Python dans les "consoles DOS" :'(

      • [^] # Re: Python

        Posté par  . Évalué à 5.

        Tu peux essayer Pyscripter : http://pyscripter.googlepages.com/

        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  . Évalué à 2.

        Et IDLE, c'est pour les chiens?

        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.

          Au début j'utilisais IDLE, mais quand des fonctions écrivaient plein de trucs sur la sortie standard, au lieu de les afficher, il se blo

      • [^] # Re: Python

        Posté par  . Évalué à 3.

        tout ce qui est cite plus haut existe aussi sous windows. On peut aussi rajouter eclipse+pydev dans la liste de tout ce qui est cite, ou encore eric (quoique j'aime pas vu l'impossibilite de pouvoir utiliser ipython avec), vim etc.

        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  (site web personnel) . Évalué à 2.

      Je suis un peu perplexe concernant l'utilisation de Python + quelques packages pour faire "la même chose" que Matlab... voir même Scilab.

      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  . Évalué à 3.

        Existe-il actuellement un moyen de définir
        - 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  (site web personnel) . Évalué à 1.

    Perso, ce qui me manque le plus, autour de Scilab, c'est un gestionnaire de bugs (et il aurait du boulot, le pauvre !!!)

    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 ?

  • # presque... encore un petit effort!

    Posté par  . Évalué à 2.

    La dépêche annonce: "Mais on peut désormais intégrer Scilab dans les distributions de logiciels libres sans états-d'âme."
    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  (site web personnel) . Évalué à 5.

      C'est une des raisons pour lesquels ça reste une version beta pas une stable. ;)
      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  . Évalué à 5.

    Scilab c'est génial!
    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  (site web personnel) . Évalué à 3.

      Yep, ca fait parti des plans:
      http://www.scilab.org/developers/index_developers.php?page=r(...)

    • [^] # Re: Et Scicos?

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

      Labview est très lié à National Instrument et à ses cartes d'acquisition. Donc dès que l'on aborde ce thème, on pense de suite aux drivers de ces dites cartes...

      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  . Évalué à 3.

        Certes! Mais il faut bien commencer par quelquechose!
        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  . Évalué à 4.

          Il existes le projet comedi dont j'avais parlé dans ce journal : http://linuxfr.org/~freejeff/22273.html

          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  . Évalué à 1.

        Ceci dit, sans que ce soit une solution 100% libre, il existe des moyens d'accéder différemment aux données des cartes d'acquisition:

        http://pyvisa.sourceforge.net/

        Bon, j'ai pas encore essayé. ;-)

        • [^] # Re: Et Scicos?

          Posté par  . Évalué à 1.

          J'ai testé, et j'ai validé !

          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  . Évalué à 2.

    Scilab logiciel libre, voila une bonne nouvelle. Mais pourquoi choisir
    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  (site web personnel) . Évalué à 2.

      Tiens, c'est amusant de poster ce troll comme premier message sur LinuxFr ;)
      Bienvenue ceci dit

    • [^] # Re: Scilab/Octave/Python?

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

      Scilab logiciel libre, voila une bonne nouvelle. Mais pourquoi choisir
      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.

Suivre le flux des commentaires

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