Sorting 为什么快速排序比基数排序更受欢迎？

为什么快速排序（或introsort）或任何基于比较的排序算法比基数排序更常见？特别是对数字进行排序

基数排序不是基于比较的，因此可能比O（nlogn）更快。事实上，它是O（kn），其中k是用于表示每个项目的位数。内存开销并不重要，因为您可以选择要使用的存储桶的数量，并且所需的内存可能小于mergesort的要求

---

这与缓存有关吗？或者访问数组中的随机整数字节？

一个明显的答案是，您可以使用快速排序（即任何可比较的）对任意类型进行排序，而您只能使用基数进行数字排序。IMO快速排序更直观。

我想到了两个论点：

快速排序/内部排序更灵活：

Quicksort和Introsort适用于所有类型的数据。排序所需的只是比较项目的可能性。这对于数字来说微不足道，但您也可以对其他数据进行排序

另一方面，基数排序只是根据二进制表示对事物进行排序。它从不将项目相互比较

基数排序需要更多内存

我见过的所有基数排序实现都使用辅助缓冲区来存储部分排序结果。这增加了排序算法的内存需求。如果只对几千字节进行排序，这可能不是问题，但如果进入千兆字节范围，则会产生巨大的差异

如果我没记错的话，纸上有一个就地基数排序算法

对于（大多数）真实世界用例，基数排序速度较慢

一个原因是算法的复杂性：

如果项目是唯一的，则k>=log（n）。即使是重复项，k 另一个是实施：

额外的内存需求（这本身就是一个缺点）会对缓存性能产生负面影响

我认为可以肯定地说，许多库（如标准库）都使用快速排序，因为它在大多数情况下性能更好。 我不认为“难以实现”或“不够直观”是主要因素。

如上所述

与其他排序算法相比，基数排序的效率这一主题有些棘手，并且容易引起很多误解。与基于比较的最佳算法相比，基数排序是否同样有效、效率更低或效率更高取决于所做假设的细节。对于数字为d或更少的n个键，基数排序效率为O（d·n）。有时，d被表示为一个常数，这将使基数排序（对于足够大的n）比基于比较的最佳排序算法更好，因为这些算法都需要O（n·log（n））个比较数。然而，一般来说，d不能被视为常数特别是，在所有键都是不同的常见（但有时是隐式）假设下，则d必须至少为log（n）的顺序，这最多（对于密集的键）会给出时间复杂度O（n·log（n））。这似乎使基数排序与基于比较的最佳排序效率相当（如果键比log（n）长得多，则更糟）

相反的论点是，基于比较的算法是以比较的数量来衡量的，而不是实际的时间复杂度。在某些假设下，比较平均为恒定时间，而在其他假设下则不是。随机生成的密钥的比较平均需要恒定的时间，因为在一半的情况下，密钥在第一位上不同，在剩余一半的情况下，密钥在第二位上不同，依此类推，导致需要比较的平均两位。在排序算法中，所做的第一次比较满足随机性条件，但随着排序的进行，所比较的键显然不再是随机选择的。例如，考虑自底向上的合并排序。第一个过程将比较随机键对，但最后一个过程将比较排序顺序非常接近的键

决定因素是密钥的分配方式。基数排序的最佳情况是将它们作为连续的位模式。这将使键尽可能短，但仍假定它们是不同的。这使得基数排序为O（n·log（n）），但是基于比较的排序将没有那么有效，因为在这种假设下，比较将不是常数时间。相反，如果我们假设密钥是长度为k·log（n）的位模式（对于常数k>1和基2 log），并且它们是一致随机的，则基数排序仍然是O（n·log（n）），但基于比较的排序也是如此，因为“额外”长度使得排序结果中连续的键之间的差异足够大，因此平均而言，比较时间是恒定的如果键的长度大于O（log（n）），但是是随机的，则基数排序将较差。也可以做出许多其他假设，大多数都需要仔细研究以进行正确的比较

---

其他答案中的观点是正确的，但就你在几条评论中提到的问题而言

…数字的默认排序算法是使用快速排序实现的。特别是在库中的实现

快速排序是“安全”的选择。 基于计数排序的基数排序的潜在运行时非常吸引人，是的，但是基数排序在恶意/不幸的数据集上表现不佳是不可接受的。如果正在排序的键的位数接近正在排序的键的位数，则基数排序将在n^2上执行，同时具有不可忽略的空间复杂度，并且它往往具有相当高的内置运行时常数，而不是正在排序的键的位数。
Mergesort之所以有吸引力，是因为它的行为在某种程度上对