Bonjour
@Dranreb ,
@RyuAutodidacte et tous les autres
bon après avoir fait ce recueil de fonction de tri
ce matin je me suis dit ;
bon il faudrait quand même les tester a petite échelle (ça c'est déjà fait)
mais surtout à grande echelle
alors il y a des surprises et de taille( sans jeu de mots)
rentrons tout de suite dans le vif du sujet
j'ai donc testé nos fonctions de tri avec un array de 10 000 nombres sans doublons
alors la
insertionsort et la
bubble qui sont les plus lentes bien entendu
et bien figurez vous que la version de chacune d'entre elle
avec le JUMP EST PLUS LONGUE QUE SANS JUMP
Et là je vous le dit on marche sur la tête je vous le dis
la fonction mode insertion
sur 10 000 plus de 1000 passes en moins et c'est plus long
sans jump
Regarde la pièce jointe 1181990
avec jump
Regarde la pièce jointe 1181988
vous en comprendrez ma déconvenue
et pourtant j'ai la réponse
en fait que ce soit pour n'importe quelle methode le fait de passer de l'un a l'autre et intervertir
jusqu'a obtention de la bonne position fait que au passge les autres qui ne remplissaient pas le critère < ou plus grand ben il ont été déplacés aussi donc les prochains tours moins de travail
conclusion :
les méthodes insertion et bubble ne peuvent pas êtres améliorées pour des tri à grande échelle
le jump donne une toute petite amélioration dans les tableaux de petites tailles
passons au plus rapide
la quicksort et la fusion
et bien grosse déception de la fusion
la quicksort gagne la coupe
pas de beaucoup certes (l'ecart est de 0.01) ,et cela à chaque fois
donc 0.01 secondes de différence pour 10 000 items à trier
entre un code simple( la quicksort) et un code imbuvable (la fusion) mon choix sera vite fait
voila c’était les nouvelles du jour
je pense donc adapter la quicksort dans ma classe dictionary