谷歌采访中提到我没有得到答案。更糟糕的是没有得到问题。
在讨论排序算法时,我们讨论已经排序的文件的行为。为什么我们感兴趣的是对已经排序的文件进行排序需要多长时间?简要解释一下你的答案?
答案 0 :(得分:3)
问题基本上是:
为什么我们关心排序算法对已经排序的输入的行为?
长话短说,文件往往排序的概率高于"预期" 1/n!
假设文件被随机置换 1 。
以下是两个用例,如果数组/文件已经排序,我们非常关心算法的性能:
API(API)的用户在使用API并再次对其进行排序之前,不会检查他们的文件是否已经排序,并且因为它已经排序的可能性不是很小(因为有人已经在某个时候对它进行了排序),这种最坏的情况并不是不可能发生的。这将使我们的"与我们关心它的竞争对手相比,API速度较慢。
如果我们知道它在排序文件上是如何工作的,那么它几乎可能在几乎排序的文件上表现得相似,并且再次 - 这种输入更有可能。假设用户有一个文件,向它添加一些条目,然后再将它发送到排序算法 - 文件几乎已经排序,并且性能将非常接近排序的那个。
脚注:
(1)由于增量处理的性质,它是一个经验事实,数学支持是:随机生成的文件的概率为1 / n!已经排序了。假设自上次更新以来文件已被排序的概率p
。这意味着它被排序的概率不是1 / n!它已经p + (1-p)1/n!
了。假设p>0
,表示文件已经排序的概率高于其他文件的概率。
答案 1 :(得分:3)
假设问题是关于已经排序的输入的行为(不一定是文件),不同的排序算法在接收已经排序的输入时表现不同:
O(n)
O(n^2)
)这两个简单的例子表明,您必须在算法分析中已经排序的输入中包含排序算法的行为。
主要原因是在实际应用中,用户的输入倾向于排序或几乎排序的形式,例如:
另见:
答案 2 :(得分:1)
大多数真实世界的数据并非均匀随机分布,而是通常几乎都是分类的。如果排序算法总是采用O(nlog(n)),即使数据几乎已经排序,那么它对现实世界数据的表现也不会很好。
例如,根据日志中的日期时间条目对日志文件进行排序。当事件发生时创建日志条目时,大多数日志条目将接近它们应该的位置,只有少数日志条目由于并发写入而不合适。日志文件可能非常大,大约为千兆字节或更多,因此不利用日志文件的近分类状态的排序算法效率不高。
日志文件的另一种情况,在分布式系统中,多个系统可以同时生成日志条目。单个日志文件本身已排序(或接近排序),但您希望将多个日志文件合并为一个包含所有系统中所有事件的线性日志文件。您可以只连接所有日志,如果排序算法识别出大多数数据具有已经排序的条目的宽范围,它可以执行更高效的O(n)合并操作而不是O(nlog(n))排序
答案 3 :(得分:0)
我将再举一个例子。大多数银行交易几乎都是分类的,因为人们喜欢按照支票号码的顺序收到银行对账单。人们按支票号码按顺序写支票,交易员相应地兑现。因此,转换事务排序时间的问题再次是对总是排序的输入进行排序的示例。
最广泛使用的排序技术之一是quicksort。但是,当输入排序时,quicksort执行得非常差。当输入数据被排序时,它接近 O(n ^ 2)的时间复杂度。这不好,所以我们去随机化。我们随机排列数据元素或随机选择一个轴(中位数为三)。这样做是为了使输入数据集无关紧要。输入数据没有错误的排序。当然,如果你的随机化导致输入数据集被排序,那么你只是运气不好。 这种随机快速排序算法的运行时间现在与输入排序无关。随机快速排序的预期运行时间为 O(nlogn)。