我不时浏览网页，寻找有趣的算法和数据结构，放入我的技巧。一年前，我遇到了Soft Heap数据结构，并了解了近似排序。
这背后的想法是，如果您可以接受排序算法作弊的事实，则可以打破基于比较的排序的O（n log n）障碍。你得到一个几乎排序的列表，但你也必须忍受一些错误。
我在测试环境中使用了算法，但从未找到它们的用途。
所以问题：有没有人在实践中使用过近排序？如果是这样的应用程序？你能想到一个近距离排序是正确的用例吗？
答案 0 :(得分：9)
这是一个完全的飞行猜测，但鉴于在对搜索结果进行排序时“相关性”度量的固有主观性，我冒昧地认为它们是否完美排序并不重要。对于建议也可以这样说。如果你能以某种方式安排你的算法的每个其他部分都是O（n）那么你可能会避免排序。
另请注意，在最糟糕的情况下，您的“近乎排序”的数据不会满足一个可能的“近乎排序”的直观概念，即它只有少量的反转。这样做的原因只是如果您的数据只有O（n）反转，那么您可以使用插入排序或鸡尾酒排序（即双向冒泡排序）在O（n）时间内完成排序。因此，在O（n）时间内（使用比较），你不可能从完全未排序到达这一点。因此，您正在寻找应用程序，其中大多数数据子集被排序，其余部分被分散，不用于要求每个元素都接近其正确位置的应用程序。
答案 1 :(得分：4)
这里只是推测，但我想到的一件事是数据库查询优化。
必须将声明性语言（如SQL）中的数据库查询转换为称为“执行计划”的逐步程序。一个SQL查询通常可以转换为许多此类执行计划，这些计划都会产生相同的结果，但性能可能会有很大差异。查询优化器必须找到最快的，或至少一个相当快的。
基于成本的查询优化器具有“成本函数”，用于估计给定计划的执行时间。详尽的优化程序会经历所有可能的计划（对于“所有可能”的某些值）并选择最快的计划。对于复杂的查询，可能的计划数量可能非常大，导致优化时间过长（甚至在您开始在数据库中搜索之前！），因此也有非详尽的优化器。他们只看一些计划，或许在选择哪些计划时有随机因素。这是有效的，因为通常会有大量的“好”计划，找到绝对最好的计划可能并不那么重要 - 最好选择5秒计划而不是最佳的2秒计划，如果需要几分钟的优化才能找到2秒计划。
一些优化算法使用“有希望的”（部分）计划的排序队列。如果你找到绝对最好的计划并不重要，也许你可以使用几乎排序的队列？
另一个想法（我还在猜测）是时间共享系统中进程或线程的调度程序，如果某个进程或线程比严格的情况晚几毫秒获得其时隙可能并不重要按优先顺序排序。
答案 2 :(得分：4)
有许多“贪婪”的启发式方法，您可以定期选择一组最小值。贪婪的启发式并不完美，所以即使你选择了最低限度，也无法保证获得最佳答案。事实上，GRASP元启发式，你故意引入随机错误，以便获得多个最终解决方案并选择最佳解决方案。在这种情况下，在您的排序例程中引入一些错误以换取速度将是一个很好的权衡。
答案 3 :(得分：2)
近距离排序的一个常见应用是当一个人进行成对比较时，你不想要问他们那么多问题。
假设您有很多项目，您希望通过成对比较对人类进行排序。如果您愿意接受订购不准确，您可以大大减少您需要他们做的比较次数。例如，您可能不关心相邻的项目是否已被交换，因为首选项目位于顶部。
答案 4 :(得分：1)
任何地方
你可以使用它。 “不那么严格”的基于规则的优先级队列怎么样？那会有用吗？也许是线程/进程/资源调度。在线程/进程调度中，你真的没有希望任何一个线程可以进入第一，第二或最后，但通常你想给每个人一些机会。你可能想强制执行松散的规则，因此它是先发制人的，优先的，blabla ..
资源计划示例将响应披萨交付或向人们发送书籍等等。您无法在预期确定性结果的地方使用它，但在现实生活中有很多例子，事情不是那么确定/可预测的。
答案 5 :(得分：-1)
O（n log n）已经非常快了。我认为任何人都不会使用近似排序算法开始。您可以从完全排序的代码开始（因为您选择的编程语言可能提供sort函数而不是nearsort函数），并且当您从经验上发现排序也是如此很久，你会开始质疑你的数据真的是否需要完全排序，并考虑使用近似排序。
基本上，你甚至不会考虑使用近似排序，除非你第一次发现排序是你程序中的一个严重瓶颈。