Re: LUSH : Lisp Universal SHell

• [^]Re: LUSH : Lisp Universal SHell

  Posté par Troy McClure (page perso, ) le 02/11/2002 à 13:54. (lien). Évalué à 1.

  J'aurais tendance à dire qu'il s'agit de quelque chose de beaucoup plus spécialisé que guile, et accessoirement plus performant pour le calcul numérique, mais comme je ne connais ni guile ni lush, je ne dirais rien.
  
  Y'a quand même un truc relativement original, voire tordu, c'est la possibilité d'inliner du code C directement dans le lisp, celui-ci étant compilé à la volée ! http://lush.sourceforge.net/images/screendumps/helptool01.png(...)

Pas convaincu

• [^]Re: Pas convaincu

  Posté par Vaillant Jerome () le 04/11/2002 à 12:51. (lien). Évalué à 1.

  Pour ceux qui ont du mal a parler le lisp couramment, il y a Yorick. Un language interprete, avec une syntaxe proche du C, tres puissant au niveau traitement des matrices et des tableaux multidimensionnels (bien mieux que Matlab!). C'est tres bien adapte au traitment d'image genre deconvolution. Un certain nombre de bibliotheques de fonctions son disponible grace a la communaute des utislisateurs. Son seul point faible est l'interface graphique quelque peu rustique, mais David Munro est en train de l'ameliorer... A suivre...
  http://wuarchive.wustl.edu/languages/yorick/yorick-ad.html(...)
  http://yorick-mb.sourceforge.net/(...)

  • [^]Une news, une news, une news, ....

    Posté par Jack () le 04/11/2002 à 21:54. (lien). Évalué à 1.

    Pas mal du tout Yorick.
    Ca mérite une news en pleine page de linuxfr ce language.
    Qui se lance ?
    
    Jack

• [^]Re: Pas convaincu

  Posté par LupusMic (page perso, ) le 04/11/2002 à 17:21. (lien). Évalué à 1.

  Je crois que l'humanité est condamné à parler plusieurs langages depuis la tour de Babel.
  Tu es au courant que c'est de la mythologie chrétienne ?

Un progrés évident.

• [^]Re: Un progrés évident.

  Posté par Jack () le 02/11/2002 à 16:30. (lien). Évalué à 1.

  Ce qui nuit à octave et scilab c'est le rendu graphique de matrices et de volume (je sais de quoi je parle, je travaille dans le traitement d'images).
  
  A part cela, ces derniers sont mieux conçus que matlab (gestion mémoire, principes de base, création de types, modularité... ).
  
  Le premier tente quelque peu de clôner matlab sans pour autant perdre sa philosophie et en oubliant les mauvaises solutions matlabiennes.
  
  Le second est un peu indépendant et offre des solutions très intéressantes par exemple pour la création de nouveaux types et d'opérateurs.
  
  Alors, faut pas décrier trop vite ces outils fort bien conçus.
  Matlab me fait ch... tous les jours par exemple avec ces nouveaux outils "java" qui n'ont apporter qu'une chose, des bugs supplémentaires et des arrêts brusques avec perte de données.
  En plus, j'ai jamais compris comment matlab gèrait la mémoire qu'il alloue à la création de matrices. C'est vraiment devenu une usine à gaz.
  
  En plus quand on est habitué au libre, c'est vraiment frustrant de voir le nombre de bibliothèques et toolbox payantes.
  
  Jack.

  • [^]Re: Un progrés évident.

    Posté par E V () le 02/11/2002 à 18:03. (lien). Évalué à 1.

    Matlab c'est pas libre, c'est cher et c'est pas ideal pour tout. OK. Mais Scilab et Octave manquent de fonctionalités et cela freine enormement leur diffusion.
    En plus, Scilab et un langage très différent de Matlab. Certaine fonctionalités comme les sorties graphiques ne sont pas faciles à utiliser (par rapport à Matlab). Les parametres des fonctions sont souvent alambiqués et jamais compatibles avec Matlab. Meme un truc bete comme la fft n'est pas compatible avec Matlab.
    Personnellement c'est Scilab qui me fait ch... Si on utilise Matlab c'est quand même pour la simplicité. Octave, du fait de la compatibilité Matlab, j'aime mieux, mais ça manque de tout. C'est certainement bien pour les petits projets, genre, quand on a pas matlab sous la main.
    
    Avec lush, on peut espérer que la comunauté scientifique developpe de chouets outils pour LUSH et que ça finisse par devenir aussi intéressant que Matlab.

    • [^]Re: Un progrés évident.

      Posté par Troy McClure (page perso, ) le 02/11/2002 à 18:50. (lien). Évalué à 1.

      Je suis plutot d'accord, d'autant que <pincettes>je suis pas sûr sûr de moi, mais il me semble avoir entendu que scilab serait un projet plus ou moins à l'abandon à l'inria</pincettes>. Et octave a comme tu le dis beaucoup de lacunes.. D'autant que la compatibilité avec le langage matlab n'est finalement pas une bonne chose, surtout quand on voit la tournure que celui-ci prend: son nouvel aspect "orienté objet' me semble particulièrement crétin (faire un répertoire par type d'objet !?), l'introduction des types (uint32, single, char, ...) est incomplète et mal foutue, le nombre de fonctions intrinsèques devient astronomique (du coup c'est de moins en moins simple). Et je ne parle pas des javaneries.. Bref l'utilisation de matlab a le don de me foutre de mauvaise humeur.. Mais il reste incontournable, d'autant plus qu'il est souvent utilisé par des gens qui ne connaissent pas d'autre langages et qui n'ont aucune envie de changer leurs habitudes (ça rejoint ce que tu disais sur scilab, et c'est aussi pour cette raison que je n'ai jamais fait l'effort d'apprendre à m'en servir).

      • [^]Compatibilité ??? Pensez plus loin!

        Posté par Jack () le 04/11/2002 à 08:55. (lien). Évalué à 1.

        Vos discours sont quand même un peu paradoxales.
        Dans un sens vous critiquer matlab pour son manque de liberté et le fait qu'il soit propriétaire, et de l'autre vous trouvez que scilab et octave ne sont pas assez compatible avec matlab.
        
        Au début je pensais comme vous. Je voulais avoir un max de compatibilité entre ces langages. Par la suite, en discutant sur des forums spécialisés et aux travers de mails avec les développeurs de ces projets libres, je me suis rendu compte qu'il fallait quelque peu "oublier" matlab et voir ce que scilab et octave ont à offrir.
        
        Alors si vous trouvez que scilab est un peu trop "alambiqué" c'est que vous avez pas azssez creusé. Une fois que l'on passe au delà de ce style, on se rend compte des fonctionnalités qu'il offre. Pour Scilab, je vous conseille d'ailleurs les très bons articles parut dans Gnu Linux Magazine il y'a un peu moins d'un an.
        
        En outre, pour avoir manipuler la fft tous les jours, je peux vous assurer que celle de scilab fonctionne très bien et aussi rapidement que celle de matlab:
        --> x = rand(1,1024);
        --> y = fft(x,-1); %% pour la fft
        --> nx = fft(x, 1); %% pour la ifft
        
        
        Jack.

        • [^]Re: Compatibilité ??? Pensez plus loin!

          Posté par E V () le 04/11/2002 à 19:03. (lien). Évalué à 1.

          Scilab est un langage à part (raison historique: avant c'etait un concurent propriétaire de matlab developpé par l'INRIA). Aujourd'hui Scilab est devenu libre parce que le retard accumulé par rapport à son concurrent est devnu trop grand et le logiciel était condamné à mourir sinon. Cela ne fait pas pour autant de Scilab un concurent sérieux à Matlab. Il vaudrait peut etre mieux privilégier des alternatives différentes et plus puissantes que Matlab. Flush semble avoir le potentiel et le lisp n'est pas trop difficile à apprendre. Malheureusement, après avoir examiné la question de près, il me semble que le choix des auteurs concernant la manipulation des matrices est douteux. Pourquoi passer par la notion de tenseurs pour multiplier deux matrices? De plus, il n'est pas clair que la mise en oeuvre garrantit des performances interessantes. Notamment il n'est pas précisé dans la présentation du logiciel que flush s'appuie sur des routines de type BLAS/ATLAS, ce qui pourrait être quand meme un argument vendeur. De plus, l'interface avec des matrices gsl me semble plus être une redondance qu'un atout. D'autant que gsl possède aussi a ce stade deux types de routines pour la manipulation de matrices (gsl natif et BLAS)
          
          Bref que penser ?

          • [^]Re: Compatibilité ??? Pensez plus loin!

            Posté par Vivi (page perso, ) le 04/11/2002 à 22:32. (lien). Évalué à 1.

            Bref que penser ?
            
            Déjà c'est lush, pas flush.
            
            Pour ce qui est de l'interface gsl, c'est pas vraiment une redondance. Les routines d'algèbre linéaire (qui ne sont pas aussi générales que celles de BLAS il est vrai) ne constituent qu'une petite partie de la GSL. J'imagine que ce sont toutes les autres routines qui les intéressaient (minimisation, fft, solveurs, ...).
            
            Je comprends pas trop quel est ton problème avec les tenseurs mais pour moi, il est clair que la mise en oeuvre garantit des performances interessantes. :)
            
            De toutes façons, je pense pas qu'avoir de la redondance soit un problème. Apparemment un des intérêts de lush, c'est l'interfacage facile avec les bibliothèques en C et la possibilité de compiler en C certaines fonctions tout en utilisant la même syntaxe. Une fois que tu maîtrises ça, c'est bien de pouvoir choisir parmi différentes bibliothèques de calcul.

            • [^]Re: Compatibilité ??? Pensez plus loin!

              Posté par E V () le 06/11/2002 à 10:36. (lien). Évalué à 1.

              D'abord, le nouveau systeme d'archives de linuxfr est penible.
              Ensuite flush ou lush on a le droit aux typos!
              Plus sérieusement, le problème c'est que un matin je vais décider de commencer un projet avec gsl. Ensuite, le lendemain je m'aperçois que je dois utiliser une autre bibliothèque. et hop! je dois convertir toutes les vecteurs et matrices pour utiliser la nouvelle bibliothèque qui n'aura pas le m^eme format. Ca c'est vraiment pénible! Je ne comprends pas du tout la position qui consiste à dire que ce n'est pas un probleme. Pour moi, quand pour mon travail, ça l'est. Et si je veux faire de l'informatique de bas niveau, je ferai du C/C++, point, mais écrire un algorithme en C, ca prend du temps. Pourquoi les gens sont pret à payer 10kEUR une licence Matlab à votre avis?
              
              Je veux que ce soit simple avant tout. et que je puisse écrire
              y=A*x ou (* A x) peu importe mais que ce ne soit pas idx_machin1multmachin2transp puis gsl_matrix_mult, puis gsl_blas_dgemm. Voilà! Je suis pour "Un code simple et lisible"

              • [^]Re: Compatibilité ??? Pensez plus loin!

                Posté par daniel () le 08/11/2002 à 18:28. (lien). Évalué à 1.

                et qu'est ce que vous pensez de python, en particulier en ce qui concerne numpy ?

                • [^]Re: Compatibilité ??? Pensez plus loin!

                  Posté par E V () le 10/11/2002 à 14:12. (lien). Évalué à 1.

                  Je remarque qu'il faut aller pecher la news de plus en plus loin dans les archives...
                  Je ne connais pas bien. Mais j'ai surtout l'impression que l'on ne peut pas faire grand chose d'intéressant avec pour le moment. Se limiter à wrapper les routines de bases LAPACK/BLAS c'est assez léger pour une utilisation intensive. Des tas (enfin ... moins de dix quand même) de bibliothèques C++ le font déjà avec plus ou moins de succés.
                  Le minimum de fonctionnalités pour qu'un logiciel scientifique prenne de l'essort c'est >= GSL à mon avis. Sinon ça ne vaut pas le coup et personne n'acceptera d'investir du temps là dedans.

Cool

• [^]Re: Cool

  Posté par Marc Lavallée () le 03/11/2002 à 18:41. (lien). Évalué à 1.

  Je l'ai téléchargé à partir du CVS, que j'ai archivé dans un "tarball".
  J'ai aussi créé un fichier SPEC pour compiler un paquet rpm:
  ----------------------------------------------------------------------------------------
  Summary: Lisp Universal SHell
  Name: lush
  Version: 0.95CVS
  Release: 1
  Group: Applications/Scientific
  Copyright: GPL
  Source: lush-%{version}.tar.bz2
  BuildRoot: /tmp/lush-root
  URL: http://lush.sourceforge.net/(...)
  
  %description
  Lush is an object-oriented Lisp interpreter/compiler with features
  designed to please people who want to prototype large numerical
  applications. Lush includes an extensive library of
  vector/matrix/tensor manipulation, numerous numerical libraries
  (including GSL, LAPACK, and BLAS), a set of graphic functions, a
  simple GUI toolkit, and interfaces to various graphic and multimedia
  libraries such as OpenGL, SDL, Video4Linux, and ALSA (video/audio
  grabbing), and others. Lush is an ideal frontend script language for
  programming projects written in C or other languages.
  
  %prep
  %setup -n lush
  
  %build
  CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=%{_prefix}
  make
  
  %install
  mkdir -p $RPM_BUILD_ROOT%{_bindir}
  mkdir -p $RPM_BUILD_ROOT%{_prefix}/man/man1
  mkdir -p $RPM_BUILD_ROOT%{_datadir}
  make install prefix=$RPM_BUILD_ROOT%{_prefix}
  cp -r doc $RPM_BUILD_ROOT%{_datadir}/lush
  rm -rf $RPM_BUILD_ROOT%{_datadir}/lush/src
  
  %clean
  [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "$RPM_BUILD_ROOT"
  
  %files
  %defattr(-,root,root)
  %{_bindir}/lush
  %{_prefix}/man/man1/lush.1*
  %{_datadir}/lush
  %doc COPYING COPYRIGHT NOTES README
  ----------------------------------------------------------------------------------------
  
  Un des aspect les plus intéressant de Lush est 'intégration de plusieurs librairies, entre-autre pour la saisie vidéo et la reconnaissance de formes.
  --
  Marc