Je ne suis que pertiellement d'accord avec toi. OCAML est un très joli langage mais le coup de la complexité, c'est quand même un peu pipo.
La complexité, je connais bien. C'est mon fond de commerce pour pouvoir faire des trucs bien théorique sur des graphes. Si on me demande à quoi ça sert, je répond que sur de grosses classes de graphe, je sais résoudre des problèmes NP-complets en temps linéaire.
Oui mesdames et messieurs, vous avec bien vu, en temps LINÉAIRE!!!
Sauf que bien évidemment dans la constante, il se cache un 2^k qui rend tout ce que je dis bidon mais je m'en fout, moi, je suis un théoricien.
Pourquoi tout le monde utilise-t-il quicksort alors qu'il n'est pas optimal? Alors que heapsort est optimal et est un tri en place? Tout simplement parce que dans la vraie vie, ben quicksort est plus rapide.
Dans le même genre le problème de savoir si une solution est optimale pour un programme linéaire entier est NP complet. Pourtant la prog linéaire, dans la vraie vie...
[^] # Re: Comparaison de neuf langages sur un micro-benchmark
Posté par fmaz fmaz . En réponse à la dépêche Comparaison de neuf langages sur un micro-benchmark. Évalué à 2.
La complexité, je connais bien. C'est mon fond de commerce pour pouvoir faire des trucs bien théorique sur des graphes. Si on me demande à quoi ça sert, je répond que sur de grosses classes de graphe, je sais résoudre des problèmes NP-complets en temps linéaire.
Oui mesdames et messieurs, vous avec bien vu, en temps LINÉAIRE!!!
Sauf que bien évidemment dans la constante, il se cache un 2^k qui rend tout ce que je dis bidon mais je m'en fout, moi, je suis un théoricien.
Pourquoi tout le monde utilise-t-il quicksort alors qu'il n'est pas optimal? Alors que heapsort est optimal et est un tri en place? Tout simplement parce que dans la vraie vie, ben quicksort est plus rapide.
Dans le même genre le problème de savoir si une solution est optimale pour un programme linéaire entier est NP complet. Pourtant la prog linéaire, dans la vraie vie...