I have an array list with some integer values, and I need to find only the five smallest element from the list. Is it efficient to use bubble sort than using any other sorting algorithm? or what is the best algorithm for this?
The common approach is to use a binary heap to track the n smallest elements while scanning from one end to the other.
However, for five elements, it might be just as efficient to track the five smallest seen so far in a simple array. For each new element you inspect, if it's smaller than all the elements in the array, replace the largest with the new element.
Related
I want to test time complexity of quickSort but I dont know how to generate arrays for testing best case. My version of quickSort takes as pivot the last element of the array.
Assuming all the array elements are different, you get the worst case obviously if you always pick either the smallest or largest element. That will give you the worst recursion depth and maximum number of comparisons.
But for the worst case, you will also want many exchanges. Examine how many elements your implementation of quicksort moves when the last element is the smallest, or when it is the largest element in the array. Decide what's worst. Then arrange the numbers in your array so that the last element in each subarray is always the worst case.
What is the different between the insertion sort algorithm and bubble sort algorithm?
I have searched everywhere but I didn't find the exact answer
Insertion Sort divides your array in two parts, a sorted one and an unsorted one. The algorithm takes the first element of the unsorted part and inserts it in the correct place in the sorted part. Because it tries to place each element as they occur, the sorted part is possibly very often rewritten, which is rather costly.
Bubble Sort in contrast iterates over the array and compares two values at a time. The bigger (or smaller [depending on your implementation]) value gets pushed to the end of the array (it bubbles up) and then it looks at the next two values (the one it just bubbled up and the next one). When the algorithm worked through the array the biggest (or smallest) value is the last value in the array. It repeats this procedure (leaving sorted values at the end of the array untouched) until the array is sorted. If you don't swap the values each time, but just mark the biggest value, you can implement this with one swap each iteration.
Background
std::deque uses subarrays to store its elements. It has an additional book keeping data structure to keep track of its subarrays. This way, compared to std::vector, std::deque can grow faster from the back (O(1) compared to amortized O(1)), and much faster in the front (O(1) compared to O(n)). This is due to the fact that std::deque can just add a subarray at either end and only have to modify its book keeping data structure.
Question
What I don't understand is why the subarrays have their sizes fixed as explained here:
typical implementations use a sequence of individually allocated fixed-size arrays
There are quite a few advantages of not having fix sized subarrays. For example, since the subarrays are fixed in size, any insertion in the middle will have to be O(n) complexity where n is the number of the elements to the closest end. However, if the subarrays are free to grow, insertion in the middle will be O(k) where k is the number of elements in the subarray which is much faster especially if the std::deque has a lot of subarrays. It's the same for deletion from the middle.
Is it because std::deque wants to keep its subarrays balanced? This can easily be mitigated by enabling subarrays to split or merge if they get too large/small. The complexity will just be O(k) where k is the size of the largest subarray. (Or the combined sizes of the smallest subarray and it's smaller neighbor)
Is it because fixed sized subarrays makes random iterating faster? For example if you want the nth element, you have to go through the book keeping data structure and add the sizes of all the previous subarrays making the complexity O(k) where k is the size of the book keeping
data structure. But this is not a huge deal either since std::deque is advertised to be a doubly linked list with better caching anyways.
EDIT: std::deque is just a middle man between linked list implementation and array implementation. I guess my question has lost its original meaning and is just suggesting that it should behave more like a linked list than a vector
What I don't understand is why the subarrays have their sizes fixed
Because that allows constant complexity random access which is required by the standard, as pointed out in the comments.
But this is not a huge deal
I disagree, and presumably so would the standard committee.
since std::deque is advertised to be a doubly linked list ...
It's not advertised as such.
As far as i know, the only possible way to find largest number and lowest number if they array is not sorted by using linear search.
is there any other option for this one? just want to know tho
Since the value of a particular element in an unsorted collection tells you nothing about the value of adjacent elements, you need to inspect every value.
And doing that is O(N).
Nope, there is none. Complexity of finding largest/smallest element of an unsorted sequence is always O(N) comparisons.
There is no other way. You have to inspect each and every element. The complexity of algorithm always will be O(n)
How to efficiently compare two vectors in C++, whose content can't be meaningfully sorted?
I read many posts but most talk about first sorting the two vectors and then comparing
the elements. But in my case I can't sort the vectors in a meaningful way that can
help the comparison. That means I will have to do an O(N^2) operation rather than O(N),
I will have to compare each element from the first vector and try to find a unique match
for it in the second vector. So I will have to match up all the elements and if I can
find a unique match for each then the vectors are equal.
Is there an efficient and simple way to do this? Will I have to code it myself?
Edit: by meaningful sorting I mean a way to sort them so that later you can
compare them in linear fashion.
Thank you
If the elements can be hashed in some meaningful way, you can get expected O(n) performance by using a hashmap: Insert all elements from list A into the hashmap, and for each element in list B, check if it exists in the hashmap.
In C++, I believe that unordered_map is the standard hashmap implementation (though I haven't used it myself).
Put all elements of vector A into a hash table, where the element is the key, and the value is a counter of how many times you’ve added the element. [O(n) expected]
Iterate over vector B and decrease the counters in the hash table for each element. [O(n) expected]
Iterate over the hash table and check that each counter is 0. [O(n) expected]
= O(n) expected runtime.
No reason to use a map, since there's no values to associate with, just keys (the elements themselves). In this case you should look at using a set or an unordered_set. Put all elements from A into a new set, and then loop through B. For each element, if( set.find(element) == set.end() ) return false;
If you're set on sorting the array against some arbitrary value, you might want to look at C++11's hash, which returns a size_t. Using this you can write a comparator which hashes the two objects and compares them, which you can use with std::sort to perform a O(n log n) sort on it.
If you really can't sort the vectors you could try this. C++ gurus please free to point out flaws, obvious failures to exploit STL and other libraries, failures to comprehend previous answers, etc, etc :) Apologies in advance as necessary.
Have a vector of ints, 0..n, called C. These ints are the indices of each element in vector B. For each element in vector A compare it against elements in B according to the B indices that are in C. If you find a match remove that index from C. C is now one shorter. For the next A you're again searching B according to indices in C, which being one shorter, takes less time. And if you get lucky it will be quite quick.
Or you could build up a vector of B indices that you have already checked so that you ignore those B's next time round the loop. Saves building a complete C first.