Articles précédents : Livre
- [11] PLEAC - Programming Language Examples Alike Cookbook
- [25] Art of Computer Programming Vol.4
- [19] Livre O'Reilly en Ligne
- [37] "Enfin" un livre sur les techniques de piratage
- [8] la seconde édition de Linux Device Drivers sous licence FDL
- [10] Une bible pour les développeurs de jeux sous Linux.
- [1] DocBook
- [7] Linkers and Loaders
- [10] Two Dozens Short Lessons in Haskell
- [37] Learning the vi Editor
Numerical Recipes (2319 hits)
> Lire la dépêche (32 commentaires, moyenne: 1,8).
Vite !
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 Francois Revol (page perso, ) le 03/09/2001 à 07:56. (lien). É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 machinereadable
copy to any other person, nor to have any other person type the programs into a
computer on your behalf."
-
[^]Re: Vite !
Posté par Anonyme () le 03/09/2001 à 07:56. (lien). É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 GP Le (page perso, ) le 03/09/2001 à 08:29. (lien). É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 gle () le 03/09/2001 à 08:22. (lien). É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 ogallos (page perso, ) le 03/09/2001 à 11:13. (lien). É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 !
-
[^]Y a pas l'feu au lac [Re: Vite !]
Posté par javiere () le 03/09/2001 à 09:32. (lien). É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
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 Anonyme () le 03/09/2001 à 08:11. (lien). É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 Jean-Michel Kelbert () le 03/09/2001 à 08:18. (lien). É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 vrm (page perso, ) le 03/09/2001 à 09:53. (lien). É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 Brice Favre (page perso, ) le 03/09/2001 à 08:30. (lien). É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 boubou (page perso, ) le 03/09/2001 à 09:11. (lien). É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 Jean-Michel Kelbert () le 03/09/2001 à 09:40. (lien). É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 reno () le 03/09/2001 à 12:35. (lien). É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 Anonyme () le 03/09/2001 à 12:57. (lien). É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 Vivi (page perso, ) le 03/09/2001 à 14:40. (lien). Évalué à 1.Je complète pour toi :
Le C est mort, ou plutot il va MOURIR...
-
-
-
[^]Re: Autres source
Posté par boubou (page perso, ) le 03/09/2001 à 14:51. (lien). É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 Eddy () le 03/09/2001 à 15:16. (lien). É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!
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.
-
[^]Re: Un must!
Posté par kadreg () le 03/09/2001 à 08:52. (lien). Évalué à 2.Et pendant qu'on y est, achetez-vous un bon bouquin sur les design patterns...
Je conseille fortement celui de Martin Fawler, "Analysis patterns". C'est pas le plus complet, mais il est très clair, et présente les patterns les plus interressant et leur application sur des exemples simples.
A noter des complements sur son site :
http://www.martinfowler.com/(...)
Par exemple le pattern range : http://martinfowler.com/ap2/range.html(...)-
[+] [^]Ouhahaha :)
Posté par Johann Deneux (page perso, ) le 03/09/2001 à 11:43. (lien). Évalué à -1.En suivant un lien depuis ton site, on tombe sur cette page:http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=02018954(...)
Un extrait:
He shares with you his wealth of abject modeling experience and his keen eye for identifying repeating problems and transforming them into reusable models
Le livre montrerait-il ce qu'il ne faut pas faire ? ;)
-
et JAVA ?
C'est possible de faire de l'annalyse numérique en Java, ququn a testé ?
vrm
-
[^]Re: et JAVA ?
Posté par Jean-Michel Kelbert () le 03/09/2001 à 10:33. (lien). É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 ?
-
[^]Re: et JAVA ?
Posté par boubou (page perso, ) le 03/09/2001 à 15:09. (lien). É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 NeuCeu () le 03/09/2001 à 12:03. (lien). É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 Anonyme () le 03/09/2001 à 12:41. (lien). É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 gnu scientific library
je n'ai pas eu l'occasion de l'essayer, mais c'est visiblement un projet très dynamique.
http://sources.redhat.com/gsl/(...)




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.