2010-08-21 24 views
30

¿Por qué quicksort (o introsort), o cualquier algoritmo de clasificación basado en comparación es más común que radix-sort? Especialmente para ordenar números.¿Por qué el quicksort es más popular que radix-sort?

Radix-sort no se basa en la comparación, por lo tanto, puede ser más rápido que O (n logn). De hecho, es O (k n), donde k es el número de bits utilizados para representar cada elemento. Y la sobrecarga de la memoria no es crítica, ya que puede elegir la cantidad de cubos que se utilizarán y la memoria requerida puede ser menor que los requisitos de mergesort.

¿Tiene que ver con el almacenamiento en caché? ¿O tal vez acceder a bytes aleatorios de enteros en la matriz?

Respuesta

18

dos argumentos vienen a la mente:

  1. ordenación rápida/Introsort es más flexible:

    ordenación rápida y Introsort trabajar bien con todo tipo de datos. Todo lo que necesita para ordenar es la posibilidad de comparar artículos. Esto es trivial con los números pero también puedes ordenar otros datos.

    Por otro lado, el ordenamiento de radix solo ordena las cosas por su representación binaria. Nunca compara elementos uno contra el otro.

  2. La ordenación por coordenadas necesita más memoria.

    Todas las implementaciones de clasificación de radix que he visto utilizan un buffer secundario para almacenar resultados parciales de clasificación. Esto aumenta los requisitos de memoria del algoritmo de clasificación. Puede que no sea un problema si solo ordena un par de kilobytes, pero si entra en el rango de gigabytes, hace una gran diferencia.

    Si mal no recuerdo, existe un algoritmo de ordenamiento de radix en el papel.

+6

El segundo argumento es medio incorrecto. Es cierto que la ordenación de radix necesita más memoria, pero la memoria requerida depende de la cantidad de bits que utilice en cada pasada (cantidad de segmentos). Por lo tanto, la memoria requerida puede ser menor que los requisitos de mergesort, por ejemplo. – Daniyar

+0

El primer argumento es cierto, pero estoy más interesado por el hecho de que los algoritmos de clasificación predeterminados para los números se implementan usando quicksort. Especialmente las implementaciones en bibliotecas. Y el hecho de que el ordenamiento de radix nunca compare elementos entre sí es algo bueno, ya que de lo contrario su complejidad estaría limitada O (n * logn). – Daniyar

+2

Es posible realizar una operación de particionamiento bidireccional estable en el tiempo de lgN con espacio constante. Por lo tanto, uno podría hacer un ordenamiento de radix en el lugar en el espacio constante con el tiempo bNlgN, donde 'b' es el número de bits de radix. – supercat

9

Una respuesta obvia es que puede ordenar tipos arbitrarios usando quicksort (es decir, cualquier cosa que sea comparable), mientras que está restringido a números solo con radix. Y el quicksort de IMO es mucho más intuitivo.

+17

IMO Bubble Sort es más intuitivo que Quicksort. –

+2

@Justin De hecho, pero es mucho más lento. – NullUserException

+1

Es cierto, pero estoy más interesado por el hecho de que los algoritmos de clasificación predeterminados para los números se implementan usando quicksort. Especialmente las implementaciones en bibliotecas, ya que la intuitividad no es de gran importancia, si la implementación de la función sort() está bajo el capó. – Daniyar

5

La clasificación de radix es más lenta para (la mayoría) casos de uso en el mundo real.

Una razón es la complejidad del algoritmo:

Si los artículos son únicos, k> = log (n). Incluso con elementos duplicados, el conjunto de problemas donde k < log (n) es pequeño.

Otra es la puesta en práctica:

El requisito de memoria adicional (que en sí mismo es una desventaja), afecta negativamente el rendimiento de caché.

Creo que es seguro decir que muchas bibliotecas, como la biblioteca estándar, usan Quicksort porque funciona mejor en la mayoría de los casos. No creo que la "implementación difícil" o "menos intuitiva" sean factores importantes.

+3

En realidad, si lee el último párrafo de la sección Eficiencia, verá que la complejidad dada es incorrecta. – Daniyar

+1

-1 por citar una fuente que es bastante claramente de calidad cuestionable. – stakx

+0

@Daniyar Agregaste un ejemplo teórico válido en la primera sección que agregaste a wikipedia. Sin embargo, si necesita soluciones eficientes para conjuntos de datos no generales, probablemente no lo encontrará en la mayoría de las bibliotecas. El ordenamiento del cubo sería más eficiente que el ordenamiento de radix en este ejemplo. El segundo ejemplo es aún más teórico y produce algo que está solo parcialmente ordenado. Quicksort es común porque es más eficiente en (la mayoría) de los casos de uso en el mundo real. – Plow

3

Como se ha mencionado en Wikipedia

El tema de la eficiencia de Radix sort en comparación con otros algoritmos de clasificación es un tanto complicado y sujeto a un buen montón de malentendidos.Si el tipo de radix es igual de eficiente, menos eficiente o más eficiente que los mejores algoritmos basados ​​en la comparación depende de los detalles de las suposiciones realizadas. La eficiencia de clasificación de radix es O (d · n) para n teclas que tienen d o menos dígitos. A veces d se presenta como una constante, lo que haría que radix se clasifique mejor (para n suficientemente grande) que los mejores algoritmos de clasificación basados ​​en la comparación, que son todos O (n · log (n)) número de comparaciones necesarias. Sin embargo, en general, d no se puede considerar una constante. En particular, bajo la suposición común (aunque a veces implícita) de que todas las claves son distintas, entonces d debe ser al menos del orden de log (n), que da como máximo (con claves densamente empaquetadas) una complejidad de tiempo O (n · Log (n)). Eso parecería hacer que la ordenación de radix sea igual de eficiente que las mejores ordenaciones basadas en la comparación (y peor si las claves son mucho más largas que log (n)).

El argumento del contador es que los algoritmos basados ​​en la comparación se miden en el número de comparaciones, no en la complejidad del tiempo real. Según algunas suposiciones, las comparaciones serán un tiempo constante en promedio, mientras que otras no lo harán. Las comparaciones de claves generadas aleatoriamente toman un tiempo constante en promedio, ya que las claves difieren en el primer bit en la mitad de los casos, y difieren en el segundo bit en la mitad restante, y así sucesivamente, lo que da como resultado un promedio de dos bits que necesita ser comparado En un algoritmo de clasificación, las primeras comparaciones realizadas satisfacen la condición de aleatoriedad, pero a medida que avanza la clasificación, las claves comparadas ya no se eligen al azar. Por ejemplo, considere un tipo de combinación ascendente. El primer pase comparará pares de claves aleatorias, pero el último pase comparará las claves que están muy cerca en el orden de clasificación.

El factor decisivo es cómo se distribuyen las claves. El mejor caso para ordenar radix es que se toman como patrones de bits consecutivos. Esto hará que las claves sean lo más cortas posible, sin dejar de asumir que son distintas. Esto hace que radix ordene O (n · log (n)), pero los géneros basados ​​en la comparación no serán tan eficientes, ya que las comparaciones no serán constantes bajo este supuesto. Si, en cambio, suponemos que las claves son patrones de bits de longitud k · log (n) para una constante k> 1 y base 2 log, y que son uniformemente aleatorios, entonces la ordenación de radix seguirá siendo O (n · log (n)), pero también lo harán las clases basadas en la comparación, ya que la longitud "adicional" hace que incluso las claves que son consecutivas en el resultado ordenado difieran lo suficiente como para que las comparaciones sean de tiempo constante en promedio. Si las claves son más largas que O (log (n)), pero al azar, la ordenación de radix será inferior. Hay muchas otras suposiciones que también se pueden hacer, y la mayoría requiere un estudio cuidadoso para hacer una comparación correcta.

0

Puntos hechas en otras respuestas son válidas, pero por lo que la preocupación de los suyos menciona en varios comentarios

... el hecho de que el valor por defecto algoritmos de ordenación para los números se implementan utilizando la clasificación rápida. Especialmente las implementaciones en bibliotecas ...

Quicksort es la opción 'segura'. El tiempo de ejecución potencial de una ordenación de radix basada en un tipo de recuento es muy atractivo, sí, pero la ordenación de radix es susceptible de tener un mal rendimiento en conjuntos de datos maliciosos/desafortunados. Si el número de dígitos de las claves que se ordenan se acerca al número de claves que se ordenan, la ordenación de radix se realiza en n^2 junto con una complejidad de espacio no despreciable, y tiende a tener constantes de tiempo de ejecución compiladas bastante elevadas distintas de las del número de los dígitos de las claves que se ordenan
Mergesort es atractivo porque su comportamiento es, en cierto modo, análogo a un quicksort que elige un pivote óptimo en cada oportunidad (la mediana). Sin embargo, viene con una complejidad de espacio apreciable. No es tan susceptible a datos maliciosos/desafortunados como radix, pero tampoco ofrece el atractivo tiempo de ejecución posible. Un quicksort básico funciona muy bien en la mayoría de los conjuntos de datos, excepto casi (o completamente) clasificados, y viene con una pequeña complejidad de espacio.
La vulnerabilidad de Quicksort se resuelve fácilmente convirtiéndola en una colección rápida aleatorizada. La vulnerabilidad de Radix sort se resuelve colocando restricciones en las claves que se ordenan, lo que limitaría inherentemente a los usuarios de la biblioteca. Quicksort es más eficiente que fusionarse en pequeños conjuntos de datos, y tiene un rendimiento razonable cuando la fusión puede ser más rápida.
Al implementar una biblioteca, desea que sea genéricamente útil. Tome estos ejemplos, una aplicación web y un dispositivo pequeño con un microcontrolador extremadamente restringido. Las aplicaciones web necesitan tratar con datos maliciosos de forma regular y también tienen una gran variedad de necesidades. Es menos probable que una biblioteca con restricciones preacondicionadas sea útil. En el caso del microcontrolador, puede estar restringido de forma restrictiva en el espacio y no puede renunciar al menor bit donde se puede guardar. Quicksort ahorra espacio, y se completará solo más lentamente con un multiplicador constante SI surge la situación de que es más lento.
En suma -
1.) Las bibliotecas a menudo se codifican por tanto la facilidad de uso genérico posible
2.) Un buen rendimiento todo es aceptable, especialmente si es en muchos casos, el mejor rendimiento
3.) Espacio no siempre es un problema principal, pero cuando lo es, a menudo es explícitamente restrictivo así que

-2

Eficiencia de clasificación de Radix = O (cn) donde c = número más alto de dígitos entre la clave de entrada establecida. n = número de teclas en el conjunto de teclas de entrada.

Mejor caso de ordenación rápida = O (n. Log n) donde n = número de teclas en la configuración de la clave de entrada.

Suponga 16 números que ser resuelto con 6 dígitos cada uno:

Radix unidades sort = 16 * 6 = 96 tiempo. Clasificación rápida = 16 * 4 = 64 unidades de tiempo.

Lección: Cuando 'c' es menor, Radix sí gana. Cuando es alto, pierde. La ordenación rápida es independiente del número de dígitos en una clave y eso lo hace un poco mejor y más prácticamente aceptable

+0

Quicksort requiere O (n log n) ** comparaciones ** (también es importante que este sea el caso promedio, no el peor de los casos). Esto es importante porque significa que la ordenación rápida * * no * "es independiente del número de dígitos en una tecla". Significa que estás comparando manzanas con naranjas. Si desea comparar me gusta, significa que debe contabilizar el costo de ejecutar la función de comparación. Para enteros de tamaño de palabra es constante, pero ese es * no * el caso general. –

Cuestiones relacionadas