Je l'utilise tout le temps, en fait plus que des sortes basées sur des comparaisons, mais je suis certes une bizarrerie qui fonctionne plus avec des nombres qu'autre chose (je ne travaille presque jamais avec des chaînes, et elles sont généralement internées si c'est le cas à quel moment radix le tri peut être utile à nouveau pour filtrer les doublons et calculer les intersections d'ensembles; je ne fais pratiquement jamais de comparaisons lexicographiques).
Un exemple de base est les points de tri radix selon une dimension donnée dans le cadre d'une recherche ou d'un fractionnement médian ou un moyen rapide de détecter des points coïncidents, des fragments de tri en profondeur ou le tri radix d'un tableau d'index utilisé dans plusieurs boucles pour fournir un accès plus compatible avec le cache modèles (ne pas aller et venir en mémoire uniquement pour revenir en arrière et recharger la même mémoire dans une ligne de cache). Il y a une application très large au moins dans mon domaine (infographie) juste pour trier sur des touches numériques de taille fixe 32 bits et 64 bits.
Une chose que je voulais dire et dire, c'est que le tri radix peut fonctionner sur les nombres à virgule flottante et les négatifs, bien qu'il soit difficile d'écrire une version FP aussi portable que possible. De plus, alors qu'il s'agit de O (n * K), K doit simplement être le nombre d'octets de la taille de la clé (ex: un million d'entiers 32 bits prendrait généralement 4 passes de la taille d'un octet s'il y a 2 ^ 8 entrées dans le compartiment ). Le modèle d'accès à la mémoire a également tendance à être beaucoup plus convivial pour le cache que les triages rapides, même s'il a généralement besoin d'une matrice parallèle et d'une petite baie (le second peut généralement s'adapter parfaitement à la pile). QS pourrait effectuer 50 millions de swaps pour trier un tableau d'un million d'entiers avec des modèles d'accès aléatoire sporadiques. Le tri radix peut le faire en 4 passages linéaires compatibles avec le cache sur les données.
Cependant, le manque de conscience de pouvoir le faire avec un petit K, sur des nombres négatifs et en virgule flottante, pourrait très bien contribuer de manière significative au manque de popularité des sortes de radix.
Quant à mon opinion sur les raisons pour lesquelles les gens ne l'utilisent pas plus souvent, cela peut être dû à de nombreux domaines n'ayant généralement pas besoin de trier les numéros ou de les utiliser comme clés de recherche. Cependant, juste sur la base de mon expérience personnelle, beaucoup de mes anciens collègues ne l'ont pas non plus utilisé dans des cas où il convenait parfaitement, et en partie parce qu'ils ne savaient pas qu'il pouvait être fait pour fonctionner sur la PF et les négatifs. Donc, à part qu'il ne fonctionne que sur des types numériques, il est souvent considéré comme encore moins applicable qu'il ne l'est réellement. Je ne l'aurais pas autant utilisé non plus si je pensais que cela ne fonctionnait pas sur les nombres à virgule flottante et les entiers négatifs.
Quelques repères:
Sorting 10000000 elements 3 times...
mt_sort_int: {0.135 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
mt_radix_sort: {0.228 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
std::sort: {1.697 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
qsort: {2.610 secs}
-- small result: [ 12 17 17 22 52 55 67 73 75 87 ]
Et c'est juste avec mon implémentation naïve ( mt_sort_intc'est aussi un tri radix mais avec une branche de code plus rapide étant donné qu'il peut supposer que la clé est un entier). Imaginez à quelle vitesse une implémentation standard écrite par des experts pourrait être.
Le seul cas où j'ai trouvé que le type de base est moins bon que la comparaison très rapide basée sur C ++ std::sortétait pour un très petit nombre d'éléments, disons 32, auquel moment je crois std::sortcommencer à utiliser des types mieux adaptés au plus petit nombre d'éléments comme les tas ou l'insertion trie, bien qu'à ce stade mon implémentation utilise simplement std::sort.