精确的输入大小和时间复杂度
在谈论时间复杂度时,我们通常使用 n 作为输入,这并不是实际输入大小的精确度量。我无法证明,当使用特定大小的输入(s)时,算法仍处于相同的复杂性类别中。
例如,采用简单的顺序搜索算法。在最坏的情况下,需要 W(n) 时间。如果我们应用特定的输入大小(以 2 为基数),则顺序应为 W(lg L),其中 L 是最大整数。
如何表明顺序搜索或任何算法保持相同的复杂性类别(在本例中为线性时间)?我知道需要进行某种替换,但我很不稳定关于如何得出结论。
编辑
我想我可能已经找到了我正在寻找的东西,但我不完全确定。
如果将最坏情况时间复杂度定义为 W(s),即输入大小为 s 的算法完成的最大步骤数,则根据输入大小的定义,s = lg n,其中 n是输入。那么n = 2^s,得出时间复杂度为W(2^s),指数复杂度。因此,二进制编码的算法性能是指数级的,而不是线性的,因为它的大小是线性的。
When talking about time complexity we usually use n as input, which is not a precise measure of the actual input size. I am having trouble showing that, when using specific size for input (s) an algorithm remains in the same complexity class.
For instance, take a simple Sequential Search algorithm. In its worst case it takes W(n) time. If we apply specific input size (in base 2), the order should be W(lg L), where L is the largest integer.
How do I show that Sequential Search, or any algorithm, remains the same complexity class, in this case linear time? I understand that there is some sort of substitution that needs to take place, but I am shaky on how to come to the conclusion.
EDIT
I think I may have found what I was looking for, but I'm not entirely sure.
If you define worst case time complexity as W(s), the maximum number of steps done by an algorithm for an input size of s, then by definition of input size, s = lg n, where n is the input. Then, n = 2^s, leading to the conclusion that the time complexity is W(2^s), an exponential complexity. Therefore, the algorithm's performance with binary encoding is exponential, not linear as it is in terms of magnitude.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
L是表示最大整数的变量。
n 是一个变量,表示输入的大小。
L 不再是 n 的具体值。
当您应用特定值时,您不再讨论复杂性类,而是讨论该类的实例。
假设您正在搜索包含 500 个整数的列表。换句话说,n = 500
顺序搜索的最坏情况复杂度等级为 O(n)
复杂度为 n
具体实例最坏情况的复杂度是 500
编辑:
您的值在编码每个值所需的位数方面将是统一的。如果输入是 32 位整数的列表,则 c = 32,即每个整数的位数。复杂度为 32*n =>在)。
就L而言,如果L是最大值,lg L 是对L进行编码所需的位数,则lg L 是常数c。以位计算的复杂度为 O(n) = c*n,其中 c = lg L 是恒定的特定输入大小。
L is a variable that represents the largest integer.
n is a variable that represents the size of the input.
L is not a specific value anymore than n is.
When you apply a specific value, you aren't talking about a complexity class anymore, you are talking about an instance of that class.
Let's say you are searching a list of 500 integers. In other words, n = 500
The worst-case complexity class of Sequential Search is O(n)
The complexity is n
The specific instance of worst-case complexity is 500
Edit:
Your values will be uniform in the number of bits required to encode each value. If the input is a list of 32bit integers, then c = 32, the number of bits per integer. Complexity would be 32*n => O(n).
In terms of L, if L is the largest value, and lg L is the number of bits required to encode L, then lg L is the constant c. Your complexity in terms of bits is O(n) = c*n, where c = lg L is the constant specific input size.
这根本不是真的。顺序搜索完成的最大步骤数为 c*n,其中 n 是列表中的项目数,c 是某个常数。这是最坏的情况。没有 n^2 分量或对数分量。
例如,一个简单的顺序搜索将是:
使用该算法,如果您搜索每个项目,则一半的搜索将需要少于
NumItems/2
次迭代,一半的搜索将需要NumItems/2
或更多迭代。如果您搜索的项目不在列表中,则需要NumItems
迭代来确定。最坏情况下的运行时间是NumItems
次迭代。平均情况是NumItems/2
次迭代。实际执行的操作数是某个常数
C
乘以迭代次数。平均为C*NumItems/2
。That's not true at all. The maximum number of steps done by a sequential search is going to be c*n, where n is the number of items in the list and c is some constant. That's the worst case. There is no n^2 component or logarithmic component.
For example, a simple sequential search would be:
With that algorithm, if you search for each item, then half of the searches will require fewer than
NumItems/2
iterations and half of the searches will requireNumItems/2
or more iterations. If an item you search for isn't in the list, it will requireNumItems
iterations to determine that. The worst case running time isNumItems
iterations. The average case isNumItems/2
iterations.The actual number of operations performed is some constant,
C
, multiplied by the number of iterations. On average it'sC*NumItems/2
.正如 Lucia Moura 所说:“除了一元编码之外,所有其他编码都是自然编码
数字的长度是多项式相关的”
这里< /a> 是来源。
As Lucia Moura states: "Except for the unary encoding, all the other encodings for natural
numbers have lengths that are polynomially related"
Here is the source. Take a look at page 19.