Lo uso sempre, in realtà più di una sorta di confronto, ma devo ammettere che è una strana palla che funziona più con i numeri che con qualsiasi altra cosa (a malapena lavoro con le stringhe, e in genere sono internati se sì, a quel punto radix l'ordinamento può essere di nuovo utile per filtrare i duplicati e calcolare le intersezioni impostate; praticamente non faccio mai confronti lessicografici).
Un esempio di base sono i punti di ordinamento radix per una data dimensione come parte di una ricerca o divisione mediana o un modo rapido per rilevare punti coincidenti, frammenti di ordinamento di profondità o ordinamento radicale di una matrice di indici utilizzati in più loop per fornire un accesso più intuitivo alla cache pattern (non andare avanti e indietro in memoria solo per tornare indietro e ricaricare la stessa memoria in una riga della cache). Esiste un'applicazione molto ampia almeno nel mio dominio (computer grafica) solo per l'ordinamento su chiavi numeriche a 32 e 64 bit di dimensioni fisse.
Una cosa che volevo presentare e dire è che l'ordinamento radix può funzionare su numeri e negativi in virgola mobile, anche se è difficile scrivere una versione FP il più portatile possibile. Inoltre, mentre è O (n * K), K deve essere solo il numero di byte della dimensione della chiave (es: un milione di numeri interi a 32 bit richiederebbe generalmente 4 byte di dimensione se ci sono 2 ^ 8 voci nel bucket ). Il modello di accesso alla memoria tende inoltre ad essere molto più compatibile con la cache rispetto agli quicksorts anche se in genere ha bisogno di un array parallelo e di un piccolo array bucket (il secondo può in genere adattarsi perfettamente allo stack). QS potrebbe eseguire 50 milioni di swap per ordinare un array di un milione di numeri interi con schemi di accesso casuale sporadici. L'ordinamento radix può farlo in 4 passaggi lineari e compatibili con la cache sui dati.
Tuttavia, la mancanza di consapevolezza di poterlo fare con una piccola K, su numeri negativi insieme a virgola mobile, potrebbe benissimo contribuire significativamente alla mancanza di popolarità dei tipi di radix.
Per quanto riguarda la mia opinione sul perché le persone non lo usano più spesso, potrebbe avere a che fare con molti domini che generalmente non hanno la necessità di ordinare i numeri o usarli come chiavi di ricerca. Tuttavia, basandomi solo sulla mia esperienza personale, molti dei miei ex colleghi non l'hanno utilizzata nemmeno nei casi in cui era perfettamente adatto, e in parte perché non erano consapevoli che potesse essere fatto funzionare su FP e negativi. Quindi, a parte il fatto che funziona solo su tipi numerici, si pensa spesso che sia persino meno generalmente applicabile di quanto non sia in realtà. Non lo userei quasi nemmeno se pensassi che non funzionasse su numeri in virgola mobile e numeri interi negativi.
Alcuni parametri di riferimento:
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 ]
E questo è solo con la mia ingenua implementazione ( mt_sort_intè anche l'ordinamento radix ma con un ramo di codice più veloce dato che può assumere che la chiave sia un numero intero). Immagina quanto potrebbe essere veloce un'implementazione standard scritta da esperti.
L'unico caso in cui ho trovato che l'ordinamento radix è peggiore di quello basato sul confronto veramente veloce di C ++ è std::sortstato per un numero molto piccolo di elementi, diciamo 32, a quel punto credo che std::sortinizi a usare tipi più adatti al numero più piccolo di elementi come heapsorts o specie di inserzione, anche se a quel punto la mia implementazione usa solo std::sort.