Which of the following statements about insertion and selection sort is correct?
a) insertion-sort runs in omega(n^2)
b) the insert operation (for one element) in selection sort takes omega(n^2) time.
c) insertion-sort runs in O(n) time
d) the removeMin operation in selection-sort takes omega(n) time.
(Not a homework question, just doing things for final practice).
As for A, wouldn't the omega be O(N)? (looking at old questions on the website)
For B, wouldn't inserting take O(N)? Comparing 1 element vs. a whole array and if O(n) then omega can't be n^2.
For C, Insertion Sort's worse case is O(n^2)...
For D, wouldn't the best case of removing the Min be O(1)?
All of these seem wrong to me.
Edit: To anyone who says this is a homework question or something in that sense, please read the question before even assuming that. I'm wondering which one is right because they all seem wrong. Yes, I have a textbook. Yes, I can read Wikipedia.Yes, I have notes. However, if I came here it is not because I want an easy answer, rather to know why my reasoning is wrong. So, if you're not bothered to look at the entirety of the question, don't answer at all.
Related
This is definitely a stupid, and simple question. But for some reason this is bugging me. This is not a homework question--insofar, as I am not solving a homework question for my own work. I am a mathematician, who's helping his friend with some of his math homework for his CS degree. And I am pretty certain I have the correct solution, but ChatGPT gives a different solution. And he wants to follow ChatGPT's solution, when I'm pretty sure it is wrong.
The pseudo code is simple
l=0
while n >= 1 do
for j=1, n, do
l = l+2
od
n = n/3
od
ChatGPT has said that this is O(n^2 log(n)), and that just doesn't make sense to me. It's explanation is also kind of nonsense. But my friend seems to be leaning toward ChatGPT, which I think is bull shit. I believe the correct bound is O(nlog(n)), and I've supplied the following reasoning.
The operation:
while n >= 1 do
n = n/3
od
grows likes O(log(n). The act of adding a for loop, as the one I used, looks like:
Sum_{j=1}^{log(n)} O(n/3^j)
This entire sum of operations, just becomes O(nlog(n))...
I'm pretty confident ChatGPT is wrong in this scenario, but I'd appreciate someone more well versed in this kind of stuff. I don't translate code to O notation at all in my work. If I'm wrong that's fine, but I'd appreciate a well thought out answer. For god's sakes, this program has me checking my sanity!
Update
I realize I may have spoken too soon to say whether O(n * log n) is the right answer. It's certainly a lot closer to a right answer than O(n² * log n).
Original answer
You are right. ChatGPT is wrong. Your logic is sound. You've got an O(n) operation nested inside an O(log n) operation, which comes out to O(n * log n).
This should not come as a surprise: ChatGPT is designed to write prose, and has a consistent track record of making a very convincing case for "facts" and solutions that are simply wrong. Your friend should get out of the habit of relying on ChatGPT for their homework answers for this reason, even if they're ignoring the ethics of the matter.
This question was answered by #moreON but I will present the answer properly, as I see it. Thank you #StriplingWarrior, you definitely quenched my fears that I was so off. I knew it was at least O(n log(n)), but the correct answer is O(n). Which you identified before me, after #moreON's comments.
The program f which takes n and gives l is given as:
l = 0
while n >=1 do
for k=1, k <= n, do
l = l+2
od
n = n/3
od
The time it takes to run this program, if we treat each single operation as O(1)--looks exactly like the equation:
sum_{i=1}^{log_3(n)} n/3^i
When we consider the growth in n. This comes about from the while loop doing about log_3(n) loops. From here, we do a while loop for at least 1 <= m = n/3. This does, for each term in the log_3(n) list, a larger division by three, n/3^i. We can write the growth in cpu time to evaluate n of f
sum_{i=1}^{log_3(n)} n/3^i = n O(1)
As a mathematician I should've seen this. But even if I did, I'd doubt that it's that easy. Or as simple as that. Just a bound on a relatively simple sum. I thought, at best we can rough bound it with O(nlog n). But, we can prove that the solution to our problem is:
f(n) = O(n)
I want to thank #moreON and #StriplingWarrior. You guys were right... I apologize for being a jack ass.
I've recently finished two tests for a data a structures class and I've got a question related to O(n) vs O(n^2) wrong twice. I was wondering if I could get help understanding the problem. The problem is:
Suppose that Algorithm A has runtime O(n^2) and Algorithm B has runtime O(n). What can we say about the runtime of these two algorithms when n=17?
a) We cannot say anything about the specific runtimes when n=17
b) Algorithm A will run much FASTER than Algorithm B
c) Algorithm A will run much SLOWER than Algorithm B
For both tests I answered C based on: https://en.wikipedia.org/wiki/Big_O_notation#Orders_of_common_functions. I knew B made no sense based on the link provided. Now I am starting to think that its A. I'm guessing its A because n is small. If that is the cases I am wondering when is n sufficiently larger enough that C would true.
There are actually two issues here.
The first is the one you mentioned. Orders of growth are asymptotic. They just say that there exists some n0 for which, for any n > n0, the function is bounded in some way. They say nothing about specific values of n, only "large enough" ones.
The second problem (which you did not mention), is that O is just an upper bound (as opposed to Θ), and so even for large enough n you can't compare the two. So if A = √n and B = n, then obviously B grows faster than A. However, A and B still fit the question, as √ n = O(n2) and n = O(n).
The answer is A.
Big Oh order of a function f(x) is g(x) if f(x)<=K*g(x) forall x>some real number
Big Oh of 3*n+2 and n is O(n) since 4*n is greater than both functions for all x>2 . since both the Big oh notation of the functions are same we cannot say that they run in the same time for some value.For example at n=0 the value of first function is 2 and the second one is 0
So we cannot exactly relate the running times of two functions for some value.
The answer is a): You can't really say anything for any specific number just given the big O notation.
Counter-example for c: B has a runtime of 1000*n (= O(n)), A has a runtime of n^2.
When doing algorithm analysis, specifically Big Oh, you should really only think about input sizes tending towards infinity. With such a small size (tens vs. thousands vs. millions), there is not a significant difference between the two. However, in general O(n) should run faster than O(n^2), even if it the difference is less than few milliseconds. I suspect the key word in that question is much.
My answer is based on my experience in competitive programming, which require a basic understanding of the O or called Big O.
When you talk about which one is faster and which one is slower, of course, basic calculation is done that. O(n) is faster than O(n^2), big oh is used based on worst case scenario.
Now when exactly that happen? Well, in competitive programming, we used 10^8 thumb rule. It's mean if an algorithm complexity is O(n) and then there is around n = 10^8 with time limit around 1 second, the algorithm can solve the problem.
But what if the algorithm complexity is O(n^2)? No, then, it will need around (10^8)^2 which is more than 1 second. (1-second computer can process around 10^8 operation).
So, for 1 second time, the max bound for O(n^2) is around 10^4 meanwhile for O(n) can do up to 10^8. This is where we can clearly see the different between the two complexity in 1 second time pass on a computer.
Does every algorithm has a 'best case' and 'worst case' , this was a question raised by someone who answered it with no ! I thought that every algorithm has a case depending on its input so that one algorithm finds that a particular set of input are the best case but other algorithms consider it the worst case.
so which answer is correct and if there are algorithms that doesn't have a best case can you give an example ?
Thank You :)
No, not every algorithm has a best and worst case. An example of that is the linear search to find the max/min element in an unsorted array: it always checks all items in the array no matter what. It's time complexity is therefore Theta(N) and it's independent of the particular input.
Best Case input is the casein which your code would take the least number of procedure calls. eg. You have an if in your code and in that, you iterate for every element and no such functionality in else part. So, any input in which the code does not enter if block will be the best case input and conversely, any input in which code enters this if will be worst case for this algorithm.
If, for any algorithm, branching or recursion or looping causes a difference in complexity factor for that algorithm, it will have a possible best case or possible worst case scenario. Otherwise, you can say that it does not or that it has similar complexity for best case or worst case.
Talking about sorting algorithms, lets take example of merge and quick sorts. (I believe you know them well, and their complexities for that matter).
In merge sort every time, array is divided into two equal parts thus taking log n factor in splitting while in recombining, it takes O(n) time (for every split, of course). So, total complexity is always O(n log n) and it does not depend on the input. So, you can either say merge sort has no best/worst case conditions or its complexity is same for best/worst cases.
On the other hand, if quick sort (not randomized, pivot always the 1st element) is given a random input, it will always divide the array in two parts, (may or may not be equal, doesn't matter) and if it does this, log factor of its complexity comes into picture (though base won't always be 2). But, if the input is sorted already (ascending or descending) it will always split it into 1 element + rest of array, so will take n-1 iterations to split the array, which changes its O(log n) factor to O(n) thereby changing complexity to O(n^2). So, quick sort will have best and worst cases with different time complexities.
Well, I believe every algorithm has a best and worst case though there's no guarantee that they will differ. For example, the algorithm to return the first element in an array has an O(1) best, worst and average case.
Contrived, I know, but what I'm saying is that it depends entirely on the algorithm what their best and worst cases are, but the cases will exist, even if they're the same, or unbounded at the top end.
I think its reasonable to say that most algorithms have a best and a worst case. If you think about algorithms in terms of Asymptotic Analysis you can say that a O(n) search algorithm will perform worse than a O(log n) algorithm. However if you provide the O(n) algorithm with data where the search item is early on in the data set and the O(log n) algorithm with data where the search item is in the last node to be found the O(n) will perform faster than the O(log n).
However an algorithm that has to examine each of the inputs every time such as an Average algorithm won't have a best/worst as the processing time would be the same no matter the data.
If you are unfamiliar with Asymptotic Analysis (AKA big O) I suggest you learn about it to get a better understanding of what you are asking.
I need help on just wording this problem. I have the right idea but I need more to make sure I understand the solution.
Lets say your friend claims he invented a super fast comparison based priority queue. He claims insertion and extraction are O(sqrt(logn))
Why is he wrong?
If I were to prove by contradiction. He's claiming that an insert and extraction of 1 item is sqrt(logn).
Therefore n items would take nsqrt(logn). If you used the queue to sort, he's claiming it would take the above time.
However we know that the lower bound for comparison based sorting is O(nlogn) which is why your friend must be wrong.
When I try to explain this, I'm told, your friend isn't claiming that he's sorting. Just that he's inserting and extracting in that small of a time.
When I try to explain this, I'm told, your friend isn't claiming that he's sorting. Just that he's inserting and extracting in that small of a time.
Then, assuming these are worst-case bounds, your friend is wrong. You just demonstrated how this can be used to sort and you've derived a contradiction; the only thing you'd need to show is how the sort works and that it indeed takes O(n sqrt(lg n)) time.
This is a very simple question but I'm struggling too much to understand the concept completely.
I'm trying to understand the difference between the following statements:
There exists an algorithm which sorts an array of n numbers in O(n) in the best case.
Every algorithm sorts an array of n numbers in O(n) in the best case.
There exists an algorithm which sorts an array of n numbers in Omega(n) in the best case.
Every algorithm sorts an array of n numbers in Omega(n) in the best case.
I will first explain what is driving me crazy. I'm not sure regarding 1 and 3 - but I know that for one of them the answer is correct just by specifying one case and for the other one the answer is correct by examining all the possible inputs. Therefore I know one of them must be true just by specifying that the array is already sorted but I can't tell which.
My teacher always told me to think about it like we are examining who's the heighest guy in the class and again by one of these options(1,3) it's enough to say that he is and there is no reason to examine all the class.
I do know that if we were to examine the worst case then none of these statements could be true because the best sorting algorithm without any assumptions or additional memory is Omega(nlogn).
IMPORTANT NOTE: I'm not looking for a solution (an algorithm which is able to do the matching sort) - only trying to understand the concept a little better.
Thank you!
For 1+3 ask yourself - do you know an algorithm that can sort an array at best case in Theta(n) - if the answer is true, then both 1+3 are true - since Theta(n) is O(n) [intersection] Omega(n), and thus if you do have such an algorithm (that runs in Theta(n) best case) - both 1+3 are correct.
Hint: optimized bubble sort.
For 2: ask yourself - does EVERY algorithm sorts an array of numbers in O(n) best case? Do you know an algorithm that have a worst case and best case identical time complexity? What happens to the mentioned bubble sort if you take all optimizations off?
For 4: ask yourself - do you need to read all elements in order to ensure the array is sorted? If you do - Omega(n) is a definite lower bound, you cannot go better then it.
Good Luck!
The difference, obviously, is in terms "O" and "Omega". One says "rising not faster than", second says "rising not slower than".
Make sure that you understand the difference between those terms, and you'll see the difference in the sentences.
1 and 3 both state completely different things, just as 2 and 4 are.
Look at those (those are NOT the same!):
1~ there exists an algorithm that for 10 items doesn't take more than 30 in the best case.
3~ there exists an algorithm that for 10 items doesn't take less than 30 in the best case.
2~ every algorithm that for 10 items takes not more than 30 in the best case.
4~ every algorithm that for 10 items takes not less than 30 in the best case.
Do you sense the difference now? With O/Omega the difference is similar, but the subject of investigation differs. The examples above say about different performance in some point/case, while O/Omega notation tell you about the performance, related to the size of data, but only if the data "is large enough", be it three items or milions, and it drops constant factors:
function 1000000*n is O(n)
function 0.00000*n*n is O(n^2)
For small amounts data, second one is obviously very very better than first. But as the quantity of data rises, soon the first starts to be much better!
Rewriting the above examples into "more proper" terms, that are more similar to your original sentences:
1~ there exists an algorithm that, for more than N items, doesn't take more than X*N in the best case.
3~ there exists an algorithm that, for more than N items, doesn't take less than X*n in the best case.
2~ every algorithm that, for more than N items, takes not more than X*N in the best case.
4~ every algorithm that, for more than N items, takes not less than X*N in the best case.
I hope that this helps you with "seeing"/"feeling" the difference!