Numerical Recipes

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
3
sept.
2001
Doc
Si vous avez besoin d'algorithmes d'analyse numérique et que votre bibliothèque favorite est fermée il vous reste toujours la possibilité de consulter gratuitement en ligne les versions C et Fortan 77 et 90 des ouvrages "numerical recipes in ..." au format .ps et .pdf

Aller plus loin

  • # Vite !

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

    Brevetons tout ça avant qu'un M$ ou un Fraunhofer se jette dessus !
    Quand-est-ce qu'on les interdira en plein ces ù*$^ brevets logiciels ??

    Au fait c'est sous quelle licence ce pavé ?
    (je viens de regardé le sommaire... c'est bien un gros pavé :) )

    • [^] # Re: Vite !

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

      Hmmm ça me parrait pas très Free comme code...
      Et le bouquin lui même a un gros texte sur le coté de chaque page mettant bien en évidence les restrictions. Dommage c'est intéressant pourtant :-(

      "You can type the programs from this book directly into your computer. In this
      case, the only kind of license available to you is the free immediate license
      (see below). You are not authorized to transfer or distribute a machine­readable
      copy to any other person, nor to have any other person type the programs into a
      computer on your behalf."

    • [^] # Re: Vite !

      Posté par  . Évalué à 1.

      c'est un très bon bouquin parcequ'il rasseble plein d'algo différents très utiles en physique mais faites attention ils sont très loin d'être optimisé et la logique est parfois un peu spéciale va t'on on dire.

      • [^] # Re: Vite !

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

        Je confirme la non optimisation.

        Mais le gros problème vient du traitement de cas particulier. Souvent les algo explosent parce que le cas courant n'est pas traiter et que le code n'est pas blinde.

        Comme les explications des codes sont assez 'legères', tu passes beaucoup de temps comprendre pourquoi ca explose et finalement coder ca toi emem aurait pris moins de temps ;)

        Bref, quand on recupere du code, faut toujours faire attention !!!

    • [^] # Re: Vite !

      Posté par  . Évalué à 3.

      Faut pas tomber dans la parano!

      Ces algorithmes sont hyper-classiques et ont été implémentés des milliers de fois. Je crois que ça suffit pour avoir des exemples de prior art, non?

      Je rappelle qu'on ne peut breveter que des choses innovantes, pas ce qui est déjà connu et utilisé par tout le monde.

      • [^] # Re: Vite !

        Posté par  . Évalué à 1.

        Pourtant, il me semblait que MacAffee souhaitait breveter les mise à jours via internet.
        Or, ceci n'est pas une réelle innovation.

    • [^] # Re: Vite !

      Posté par  . Évalué à 2.

      Les numerical recipes ne sont pas vraiment libres ( c'est le moins que l'on puisse dire!!).
      Mais elles sont REELLEMENT utiles.
      Et rien n'empeche de trouver qqn qui a paye et qui veut bien envoyer 1-2 fichiers...

    • [^] # Y a pas l'feu au lac [Re: Vite !]

      Posté par  . Évalué à 2.

      >Brevetons tout ça avant qu'un M$ ou un Fraunhofer se jette dessus !
      Ouais, c'est ça, breuvetons...
      Les numerical recipes sont en lignes depuis des lustres.
      De plus ce sont des routines connues, ça sert plutôt comme recette de cuisine.

      Que ceux qui parlent d'optimisation du code qu'il est pas toujours bien se rappellent qu'il n'y a pas que des informaticiens qui codent, je m'en suis servi en temps qu'océanologue, pour de la modélisation biologique...

      --
      - Il est contant il élève des abeilles
      - Je suis happy culteur
      -- Sttellla in « Dark side of the moule »

  • # Autres source

    Posté par  . Évalué à 10.

    Pour ceux qui ne connaissent pas il y a également netlib.org qui permet d'avoir des codes en fortran ou C de pas mal d'Algorithmes. Vous y trouverez des algos traditionnels tels que Gauss, Choleski et d'autres bien plus poussés

    • [^] # Re: Autres source

      Posté par  . Évalué à 1.

      pour ceux qui veulent du code libre, il suffit d'aller voir les pages persos des eleves de genie mathematique de l'INSA de Rouen
      http://gm.insa-rouen.fr(...)

      analyse numerique
      algorythmique et arithmetique
      info scientifique
      etc...
      et la page perso de jmk : http://www.kelbert.com(...)

      • [^] # Re: Autres source

        Posté par  . Évalué à -1.

        Vous trouverez pas de code sur mon site qui est complétement pourri. D'autre part si Romain Durdos (http://moudos1.free.fr(...)) pouvais arrêter de poster en anonyme...

        Pour ce qui est de code vous pouvez toujours écrire au étudiants du département de Mathématiques à l'INSA de ROUEN

        • [^] # Re: Autres source

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

          Si dlfp faisait payer les pub pour les sites perso dans les commentaires, ils seraint riche.


          vrm

          PS:
          Apres le troll EPITA on va ptre troller sur l'INSA :)

    • [^] # Re: Autres sources en crypto

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

      Pour ceux que ça intéresse actuellement j'utilise une librarie free qui contient pas mal d'algo en cryptographie.

      Très bien programmé, pas mal de docs et de bon developpeur derrière qui répondent à vos questions très rapidement. Un régal pour aborder le cryptage.

      http://www.cryptopp.com(...)

    • [^] # Re: Autres source

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

      Tout à fait, d'autant plus que contrairement à une opinion classique, les numerical recipes, c'est loin d'être génial. La partie sur la minimisation dans R^n, par exemple, n'est pas vraiment représentative de l'état de l'art, c'est le moins qu'on puisse dire. La programmation n'est pas non plus géniale. En général, il vaut mieux éviter les NR surtout quand on peut utiliser d'autres sources qui sont :
      - plus exactes (articles de recherche, livres écrits par des spécialistes (ce que ne sont pas les auteurs des NR)
      - plus libres (netlib)

      Si vous voulez une bibliothèque numérique assez complète, il existe GSL sous licence GPL http://sources.redhat.com/gsl/(...) (disclaimer: j'ai écrit un micro-bout de GSL). Le gros avantage de GSL est d'avoir été écrite par des spécialistes et d'être sous une licence correcte (attention, c'est pas du LGPL !). Le gros défaut de GSL est d'être écrit en C (et oui, même pour le numérique, ça pue).

      • [^] # Re: Autres source

        Posté par  . Évalué à 1.

        Pourquoi le C puerait-il ?
        Il commence à y en avoir marre du fortran pour faire de l'Analyse Numérique !

        • [^] # Re: Autres source

          Posté par  . Évalué à 2.

          Moi, je ne dirais pas que le C pue.

          Mais par contre:
          1) les compilateurs Fortrans sont en general meilleur pour l'analyse numerique que ceux pour le C.
          De plus les compilateurs Fortrans ne sont pas embeter par les pointeurs comme en C.
          2) le C99 possede l'option "restrict"(?) pour que le compilateur puisse optimiser plus en etant sure que deux pointeurs ne vont pas se chevaucher..

          Maintenant je ne crois pas qu'il y ait deja des compilateurs a la norme C99 super-optimise pour le numerique.

          Ceci dit j'ai utilise un peu le Fortran: beurk!!
          Donc ca compense :-)

          • [^] # Re: Autres source

            Posté par  . Évalué à 0.

            Le est mort, ou plutot il va MOURIR...

            le JAVA le depasse pour les applications generalistes et le web

            pour l'analyse numerique, y a le fortran 90, qui est vraiment surpuissant ( langage objet ...)

            Bref, y a plus que les developpers de jeux pour faire du C ...

        • [^] # Re: Autres source

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

          Tout à fait d'accord, le fortran c'est de la merde. Le truc c'est que dès que tu veux faire une bibliothèque facile à utiliser, tu dois ajouter un peu d'approche objet (parce que les pointeurs sur fonctions, c'est pas la joie). Dans GSL, nous avons donc des modèles objets et c'est plutôt naze les objets en C. Je pense qu'il faudrait un GSL en C++, ça serait beaucoup plus utile (en plus il y aurait la surcharge d'opérateurs ce qui est vraiment indispensable en numérique). Donc mon argument sur le C qui pue, c'était pas du tout en comparaison avec le fortran qui est une merde, mais avec le C++. Voilà.

          • [^] # Re: Autres source

            Posté par  . Évalué à 1.

            le fortran c'est de la merde
            Tu dois pas avoir besoin de faire des gros calculs souvent alors.
            J'utilise le C et le Fortran pour des trucs non scientifiques. Mais des qu'il s'agit de programmer des calculs, le C il dit: " Tuez moi, je sais pas faire". Et le Fortran arrive, sort sa mitraileuse et acheve le C.

            Ne dis pas de betises. Pour une interfrace graphique, ok, le fortran est plutot mal adapte. Mais pour la science, c'est le C qui l'est.

  • # Un must!

    Posté par  . Évalué à 9.

    Ce livre doit faire partie de la bibliothèque de tout programmeur qui se respecte. Ca vous évitera de réinventer la roue (en la faisant carée sans le vouloir) à chaque problème un peu sérieux.

    Un autre must-read: The Art of Computer Programming par Donald Knuth, ça coute la peau des c... mais c'est toujours aussi bien, même si on sent que ça a été écrit à une autre époque...
    http://www-cs-faculty.stanford.edu/~knuth/taocp.html(...)

    Et pendant qu'on y est, achetez-vous un bon bouquin sur les design patterns...

    Voilà, c'est votre liste pour la rentrée.

  • # et JAVA ?

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

    C'est possible de faire de l'annalyse numérique en Java, ququn a testé ?

    vrm

    • [^] # Re: et JAVA ?

      Posté par  . Évalué à 2.

      L'anana num va demander de grosses ressources et donc un code optimisé. Le java est beaucoup plus lent que le C ou le Fortran donc n'est pas du tout adapté à une telle utilisation !

      • [^] # Re: et JAVA ?

        Posté par  . Évalué à 0.

        Si tu me cherches tu vas me trouver
        Jean-michel KELBERT

      • [^] # Re: et JAVA ?

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

        Ca, c'est la tarte à la crème standard. Il y a des raisons profondes de ne pas utiliser Java (pour l'instant) pour faire du numérique, mais ce n'est clairement pas le problème de l'optimisation, vu que comme le dit très bien quelqu'un plus bas, le JIT marche d'enfer sur les algos numériques simples. Ce qui rame en Java, c'est swing et l'objet pur et dur. Faire de l'objet pur et dur pour la partie basse d'un programme numérique, c'est crétin, donc pas de gros problème en Java. Ce qui craint en Java, c'est :

        - le modèle de calcul numérique qui doit être complètement reproductible sur deux plateformes différentes : cela empêche d'utiliser optimisations très pratiques qui n'existent que sur certaines plateforme (par exemple les long doubles qui n'existent pas au niveau hardware sur les power pc mais qui existent sur les x86)

        - l'absence de surcharge des opérateurs qui rend l'écriture des algorithmes lourdingue et préhistorique (par rapport au C++ par exemple)

        - la sémantique par référence uniquement des objets qui obligent à écrire une classe objet sous-efficace par rapport à ce qu'on peut faire en C++.

        - etc.

        Java c'est super, mais pas pour le numérique pour l'instant.

    • [^] # Re: et JAVA ?

      Posté par  . Évalué à 1.

      Tu peux tout faire en Java...
      Le tout est de savoir en combien de temps...

      Java n'est vraiment pas adapté pour ça, sauf si tu veux écrire un applet pour un site web,etc...

      Java est beaucoup mieux dans la gestion de graphes par exemple (arbres, plus courts chemin, etc), en plus on peut avoir une sortie graphique très facilement.

      NeuCeu

      • [^] # Re: et JAVA ?

        Posté par  . Évalué à 0.

        >Le tout est de savoir en combien de temps

        Pas vraiment d'accord car les algos sont en général assez court et répétitifs et se pretent donc assez bien à une compilation agressive par le JIT. C'est d'ailleurs dans ce genre de domaine ou les resultats des benchs C et Java sont les plus proches.

  • # il y aussi la <U>gnu scientific library</U>

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

    je n'ai pas eu l'occasion de l'essayer, mais c'est visiblement un projet très dynamique.

    http://sources.redhat.com/gsl/(...)

Suivre le flux des commentaires

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