Discussion:Tri rapide

message: Bonjour, un léger détail mais la version anglaise et la version française de cette page ne s'accordent pas sur les dates d'invention de cet algo.
La page anglaise (et je viens de voir que la page allemande également) donne 1960 tandis que la page française donne 1962. Une recherche rapide sur google scholar me donne un article de 1962 []. Je retrouve 1960 ou 1962 un peu partout (et même un 1961...) en faisant une rapide recherche.
Quelqu'un aurait il un peu de temps pour faire une recherche un peu plus approndie et aligner les dates ?
D'ailleurs la page en français concernant l'auteur donne également 1960 pour la date de l'algo.
:La première date de publication est 1961 donné dans les références « Algorithm 64: Quicksort CAR Hoare - Communications of the ACM, 1961 », possible que l'algo a été développé plus tôt mais je n'en trouve pas de trace sure, il faudrait avoir accès à cette publication pour voir si Hoare en parle, en tout cas j'ai corrigé de 1962 à 1961 l'intro. - phe 15 novembre 2007 à 10:32 (CET)
thread_title:  Date d'invention 

message: Les notions de complexité moyenne et au pire cas sont très mal présentées.
Dans le langage courant de l'algorithmique, quand on donne la complexité sans plus préciser, il est clair que le "au pire cas" est sous-entendu.
Ici Quicksort est présenté comme ayant une complexité en nlogn, avec des tournures comme "voire peut être lent (complexité en n2)", et la précision "si l'implémentation est malhabile (au niveau du choix du pivot)" n'a pas de sens car la complexité théorique n'est pas liée à l'implémentation (on peut toujours programmer n'importe quoi).83.206.37.61
:j'ai essayé d'exprimer cela un peu moins maladroitement. Est-ce un progrès ? Bluestorm (d) 25 mars 2008 à 23:10 (CET)
thread_title:  Compléxité bis 

message: La meilleure implémentation utilise un choix de pivot aléatoire, la complexité moyenne est toujours O(nlgn) mais la probabilité du pire des cas O(n2) est 1/n! soit infinitésimal. Il en est de même si on permute aléatoirement les données avant de les trier. L'importance n'est pas le pire des cas, mais la distribution de probabilité de la fonction de complexité. --Nipou (d) 8 août 2008 à 17:08 (CEST)
replies: text: tout à fait, la complexité dans la pire des cas n'a d'intérêt que dans le cas de système temps réels. - phe 9 août 2008 à 09:36 (CEST)
replies: text: Non, la complexité dans le pire des cas n'a d'intérêt qu'avec une mauvaise implémentation de quicksort, c'est-à-dire, autre chose que randomize-quicksort. --Nipou (d) 9 août 2008 à 11:11 (CEST)
thread_title:  Complexité bis bis 

message: (Loloof64) => J'ai rajouté les modifications à éffectuer pour traduire le code en C Sharp, dans la section Java.
 En C# les tableaux ne sont-ils pas intrinséquement passés par référence ? et non en valeur. D'où le fait que mot clé "ref" soit inutil.--Azgaroth (d) 4 décembre 2009 à 10:43 (CET)
thread_title:  Equivalent C Sharp 

message: À force de récursions… Il est dit dans cette page : « Une variante du tri rapide devenue largement utilisée est introsort alias introspective sort. Elle démarre avec un tri rapide puis utilise un tri par tas lorsque la profondeur de récursivité dépasse une certaine limite prédéfinie. »
Et dans la page sur le tri par tas : « A la fin du tri par tas, pour les 15 derniers éléments environ, l'algorithme effectue plusieurs fois de suite les mêmes inversions, ce qui est inutile. On peut à la place arrêter l'algorithme quand il n'y a plus beaucoup d'éléments et passer à un autre. Les données qui restent sont à peu près triées à l'envers. On peut donc, par exemple : effectuer un tri rapide sur les données restantes »
En gros, on peut améliorer un tri rapide en finissant par un tri par tas et vice-versa. J'ai mal compris ou c'est louche ?
:Bonjour. À mon avis, la remarque dans l'article tri par tas était injustifiée. Je l'ai supprimée. L'idée, c'est que le tri rapide est plus rapide que le tri par tas en moyenne mais plus lent dans le pire cas. En mettant du tri par tas dans le tri rapide, Introsort améliore le pire cas sans trop changer le cas moyen. Par contre, il n'y a pas d'intérêt à finir le tri par tas avec un tri rapide. Cordialement, Nordald (d) 16 mai 2010 à 19:10 (CEST)
thread_title:  Incohérence ? 

message: 83.145.122.242 a publié ce commentaire le 4 octobre 2013 (voir tous les retours).
il y a une petite erreur dans votre algorithme
échanger T[pivot] et T[dernier] n'est pas possible car pivot n'est pas un indice de tableau
merci quand meme
Avez-vous des remarques à formuler ?
Litlok (m'écrire) 2 mars 2014 à 23:41 (CET)
thread_title:  Commentaire du lecteur : il y a une petite er...