Eu o uso o tempo todo, na verdade mais do que tipos baseados em comparação, mas sou reconhecidamente um excêntrico que trabalha mais com números do que qualquer outra coisa (quase nunca trabalho com cordas, e elas geralmente são internadas nesse caso, nesse ponto a classificação pode ser útil novamente para filtrar duplicatas e calcular interseções de conjuntos; eu praticamente nunca faço comparações lexicográficas).
Um exemplo básico são os pontos de classificação de base por uma determinada dimensão, como parte de uma pesquisa ou divisão mediana ou uma maneira rápida de detectar pontos coincidentes, fragmentos de classificação em profundidade ou classificação de uma matriz de índices usados em vários loops para fornecer um acesso mais fácil ao cache padrões (não indo e voltando na memória apenas para voltar e recarregar a mesma memória em uma linha de cache). Há um aplicativo muito amplo, pelo menos no meu domínio (computação gráfica), apenas para classificação em chaves numéricas de tamanho fixo de 32 e 64 bits.
Uma coisa que eu queria dizer é que o tipo de raiz pode funcionar com números de ponto flutuante e negativos, embora seja difícil escrever uma versão FP o mais portátil possível. Além disso, embora seja O (n * K), K apenas deve ser o número de bytes do tamanho da chave (por exemplo: um milhão de inteiros de 32 bits geralmente leva 4 passos do tamanho de byte se houver 2 ^ 8 entradas no bucket ) O padrão de acesso à memória também tende a ser muito mais amigável ao cache do que o quicksort, embora precise de uma matriz paralela e uma matriz de bucket pequena normalmente (a segunda geralmente pode se encaixar perfeitamente na pilha). O QS pode fazer 50 milhões de swaps para classificar uma matriz de um milhão de números inteiros com padrões de acesso aleatório esporádicos. A classificação radix pode fazer isso em 4 passagens lineares e amigáveis ao cache sobre os dados.
No entanto, a falta de consciência de poder fazer isso com um K pequeno, em números negativos junto com ponto flutuante, pode muito bem contribuir significativamente para a falta de popularidade dos tipos de raiz.
Quanto à minha opinião sobre por que as pessoas não o usam com mais frequência, isso pode ter a ver com muitos domínios que geralmente não precisam classificar números ou usá-los como chaves de pesquisa. No entanto, apenas com base na minha experiência pessoal, muitos dos meus ex-colegas também não o usaram nos casos em que era perfeitamente adequado, e em parte porque não sabiam que isso poderia ser feito para trabalhar com PF e negativos. Portanto, além de trabalhar apenas com tipos numéricos, geralmente é ainda menos aplicável do que realmente é. Eu também não teria tanta utilidade se pensasse que não funcionava em números de ponto flutuante e números inteiros negativos.
Alguns benchmarks:
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 isso é apenas com minha implementação ingênua ( mt_sort_inttambém é uma classificação de radix, mas com um ramo de código mais rápido, já que ele pode assumir que a chave é um número inteiro). Imagine a rapidez com que uma implementação padrão escrita por especialistas pode ser.
O único caso em que achei que a classificação radix se saiu pior do que a comparação muito rápida do C ++ std::sortfoi para um número muito pequeno de elementos, digamos 32, quando acredito que std::sortcomeça a usar classificações mais adequadas para o menor número de elementos, como heapsorts ou tipos de inserção, embora nesse momento minha implementação apenas use std::sort.