/*
* Returns true if this and other are rankings of the same
* set of strings; otherwise, returns false. Throws a
* NullPointerException if other is null. Must run in O(n)
* time, where n is the number of elements in this (or other).
*/
public boolean sameNames(Ranking other)
{
ArrayList<String> str1 = new ArrayList<String>();
ArrayList<String> str2 = new ArrayList<String>();
for(int i = 0; i < this.getNumItems(); i++){
str1.add(this.getStringOfRank(i));
}
for(int i = 0; i < other.getNumItems(); i++){
str2.add(other.getStringOfRank(i));
}
Collections.sort(str1);
Collections.sort(str2);
if(str1.size() == str2.size())
return str1.containsAll(str2);
else
return false;
}
Ok so in the code above, using str1.containsAll(str2) destroys my O(n) time complexity, as I believe it is O(n^2) in this case. My question how can I compare the contents of two arrays/arrayLists without using O(n^2). All I can think of is nested for loop, which of course is O(n^2).
/*
* Returns the rank of name. Throws an IllegalArgumentException
* if name is not present in the ranking. Must run in O(log n)
* time, where n = this.getNumItems().
*/
public int getRankOfString(String name)
{
Cities[] nameTest = new Cities[city.length];
int min = 0;
int max = city.length;
System.arraycopy(city, 0, nameTest, 0, city.length);
Arrays.sort(nameTest, Cities.BY_NAME);
while(max >= min){
int mid = (min + max)/2;
if(nameTest[mid].getName().equals(name))
return nameTest[mid].getRank();
else if(nameTest[mid].getName().compareTo(name) < 0)
min = mid + 1;
else
max = mid-1;
}
throw new IllegalArgumentException();
}
And this one, this has to be O(log n). So I used a binary search, however it only works on sorted arrays, so I have to call Arrays.sort(), BUT I can't mess with the order of the actual array so I have to copy the array using System.arraycopy(). This is most likely O(n + (n log n) + log n), which is not log n. I don't know what other way I can search for something, it seems like log n is the best, but that is binary search and would force me to sort array first, which just adds time...
P.S. I am not allowed to use Maps or Sets... :(
Any help would be awesome.
Sorry, a ranking object contains an array of city names that can be called and an array of rankings (just ints) for each city that can be called. sameNames() is simply testing two ranking objects possess the same cities, getRankofString() has a set name entered, it then checks to see if that name is in the ranking object, if it is, it returns its corresponding rank. Hope that cleared it up
And yeah, cannot use hash anything. We are basically limited to messing around with arrays and arrayLists and stuff.
Let's count the occurrences of each string. It's a bit similar to the counting sort.
Create a hash table t with hashing function f(), where keys are strings and values are integers (initially 0).
Iterate through the first strings, for each string do t[f(string)]++.
Iterate through the second strings, for each string do t[f(string)]++.
Iterate through the non-zero values in t, if all are even - return true. Otherwise - false.
Linear time complexity.
The first method has complexity at least O(n^2), given by 2*O(n*f(n)) + 2*O(n log n) + O(n^2). The O(n log n) is given by the Collections.sort() calls which will also 'destroys your O(n)' complexity as you put it.
Since both array lists are already sorted and of equal length when you try containsAll, that call is equivalent with some sort of equals (first element in one list should be equal to the first element in the second one, etc). You can easily compare the two lists manually (can't think of any build-in function that does this).
Hence, the overall complexity of the first piece of code can be reduced to O(n log n), if you can keep the complexity of getStringOfRank() under O(log n) (but that function is not shown in your post).
The second function (which isn't related to the first piece of code) has the complexity O(n log n) as pointed out by your computations. If you already copy, then sort the city array, the binary search is pointless. Don't copy, don't sort, just compare each city in the array, putting the entire complexity of this function to O(n). Alternatively, just keep a sorted copy of the city array and use binary search on that.
Either way, creating a copy of an array, sorting that copy for each function call is highly ineffective - if you want to call this function inside a loop, like you used getStringOfRank() above, construct the sorted copy before the loop and use it as an argument:
private boolean getRankOfString(String name, Cities[] sortedCities) {
// only binary search code needed here
}
Off-topic:
Based on the second function, you have something like Cities[] city declared in somewhere your code. If it were to follow conventions, it should be more like City[] cities (class name singular, array name should be the one using the plural)
So the first one just needs to compare if the two have the exact same names and nothing else?
How about this
public static boolean compare(List<String> l1, List<String> l2) {
if (l1.size() != l2.size()) return false;
long hash1 = 0;
long hash2 = 0;
for (int i = 0 ; i < l1.size() ; i++) {
hash1 += l1.get(i).hashCode();
hash2 += l2.get(i).hashCode();
}
return hash1 == hash2;
}
In theory, you could get a hash collision I suppose.
Related
I am trying to understand the time complexity while using backtracking. The problem is
Given a set of unique integers, return all possible subsets.
Eg. Input [1,2,3] would return [[],[1],[2],[1,2],[3],[1,3],[2,3],[1,2,3]]
I am solving it using backtracking as this:
private List<List<Integer>> result = new ArrayList<>();
public List<List<Integer>> getSubsets(int[] nums) {
for (int length = 1; length <= nums.length; length++) { //O(n)
backtrack(nums, 0, new ArrayList<>(), length);
}
result.add(new ArrayList<>());
return result;
}
private void backtrack(int[] nums, int index, List<Integer> listSoFar, int length) {
if (length == 0) {
result.add(listSoFar);
return;
}
for (int i = index; i < nums.length; i++) { // O(n)
List<Integer> temp = new ArrayList<>();
temp.addAll(listSoFar); // O(2^n)
temp.add(nums[i]);
backtrack(nums, i + 1, temp, length - 1);
}
}
The code works fine, but I am having trouble understanding the time/space complexity.
What I am thinking is here the recursive method is called n times. In each call, it generates the sublist that may contain max 2^n elements. So time and space, both will be O(n x 2^n), is that right?
Is that right? If not, can any one elaborate?
Note that I saw some answers here, like this but unable to understand. When recursion comes into the picture, I am finding it a bit hard to wrap my head around it.
You're exactly right about space complexity. The total space of the final output is O(n*2^n), and this dominates the total space used by the program. The analysis of the time complexity is slightly off though. Optimally, time complexity would, in this case, be the same as the space complexity, but there are a couple inefficiencies here (one of which is that you're not actually backtracking) such that the time complexity is actually O(n^2*2^n) at best.
It can definitely be useful to analyze a recursive algorithm's time complexity in terms of how many times the recursive method is called times how much work each call does. But be careful about saying backtrack is only called n times: it is called n times at the top level, but this is ignoring all the subsequent recursive calls. Also every call at the top level, backtrack(nums, 0, new ArrayList<>(), length); is responsible for generating all subsets sized length, of which there are n Choose length. That is, no single top-level call will ever produce 2^n subsets; it's instead that the sum of n Choose length for lengths from 0 to n is 2^n:
Knowing that across all recursive calls, you generate 2^n subsets, you might then want to ask how much work is done in generating each subset in order to determine the overall complexity. Optimally, this would be O(n), because each subset varies in length from 0 to n, with the average length being n/2, so the overall algorithm might be O(n/2*2^n) = O(n*2^n), but you can't just assume the subsets are generated optimally and that no significant extra work is done.
In your case, you're building subsets through the listSoFar variable until it reaches the appropriate length, at which point it is appended to the result. However, listSoFar gets copied to a temp list in O(n) time for each of its O(n) characters, so the complexity of generating each subset is O(n^2), which brings the overall complexity to O(n^2*2^n). Also, some listSoFar subsets are created which never figure into the final output (you never check to see that there are enough numbers remaining in nums to fill listSoFar out to the desired length before recursing), so you end up doing unnecessary work in building subsets and making recursive calls which will never reach the base case to get appended to result, which might also worsen the asymptotic complexity. You can address the first of these inefficiencies with back-tracking, and the second with a simple break statement. I wrote these changes into a JavaScript program, leaving most of the logic the same but re-naming/re-organizing a little bit:
function getSubsets(nums) {
let subsets = [];
for (let length = 0; length <= nums.length; length++) {
// refactored "backtrack" function:
genSubsetsByLength(length); // O(length*(n Choose length))
}
return subsets;
function genSubsetsByLength(length, i=0, partialSubset=[]) {
if (length === 0) {
subsets.push(partialSubset.slice()); // O(n): copy partial and push to result
return;
}
while (i < nums.length) {
if (nums.length - i < length) break; // don't build partial results that can't finish
partialSubset.push(nums[i]); // O(1)
genSubsetsByLength(length - 1, ++i, partialSubset);
partialSubset.pop(); // O(1): this is the back-tracking part
}
}
}
for (let subset of getSubsets([1, 2, 3])) console.log(`[`, ...subset, ']');
The key difference is using back-tracking to avoid making copies of the partial subset every time you add a new element to it, such that each is built in O(length) = O(n) time rather than O(n^2) time, because there is now only O(1) work done per element added. Popping off the last character added to the partial result after each recursive call allows you to re-use the same array across recursive calls, thus avoiding the O(n) overhead of making temp copies for each call. This, along with the fact that only subsets which appear in the final output are built, allows you to analyze the total time complexity in terms of the total number of elements across all subsets in the output: O(n*2^n).
Your code works not efficiently.
Like first solution in the link, you only think about the number will be included or not. (like getting combination)
It means, you don't have to iterate in getSubsets and backtrack function.
"backtrack" function could iterate "nums" array with parameter
private List<List<Integer>> result = new ArrayList<>();
public List<List<Integer>> getSubsets(int[] nums) {
backtrack(nums, 0, new ArrayList<>(), new ArrayList<>());
return result;
}
private void backtrack(int[] nums, int index, List<Integer> listSoFar)
// This function time complexity 2^N, because will search all cases when the number included or not
{
if (index == nums.length) {
result.add(listSoFar);
return;
}
// exclude num[index] in the subset
backtrack(nums, index+1, listSoFar)
// include num[index] in the subset
backtrack(nums, index+1, listSoFar.add(nums[index]))
}
MAIN QUESTION: When keeping track of comparisons, what actually counts as a comparison? Should I only count comparisons between array items since that's what the algorithm is meant for or is it more widely accepted to count every single comparison?
Currently, I am trying to wrap my head around the fact that I'm told that the theoretical number of comparisons for the worst case bubble sort algorithm is as follows:
Amount of comparisons:
(N-1) + (N-2) + (N-3) + ... + 2 + 1 = (N*(N-1))/2 = (N^2-N)/2 < N^2
So according to the formula (N^2-N)/2, with an input size (N) of 10, I would get a total of 45 comparisons. However, it is mentioned that this calculation only applies to the comparison operation in the inner loop of this pseudo code:
for i:=1 to N-1 do
{
for j:=0 to N-i do
{
if A[j] > A[j+1] // This is the comparison that's counted.
{
temp := A[j]
A[j] := A[j+1]
A[j+1] := temp
}
}
}
Now in Java, my code looks like this:
public int[] bubble(int[] array)
{
int comparisons = 0;
int exchanges = 0;
int temp;
int numberOfItems = array.length;
boolean cont = true;
comparisons++; // When pass == numberOfItems, a comparison will be made by the for loop that wouldn't otherwise be counted.
for (int pass=1; pass != numberOfItems; pass++)
{
comparisons = comparisons + 2; // Counts both the outer for loop comparison and the if statement comparison.
if (cont) // If any exchanges have taken place, cont will be true.
{
cont = false;
comparisons++; // Counts the inner for loop comparison
for (int index = 0; index != (numberOfItems - pass); index++)
{
comparisons++; // Counts the if statement comparison.
if (array[index] > array[index+1])
{
temp = array[index];
array[index] = array[index+1];
array[index+1] = temp;
cont = true;
exchanges++;
} // end inner if
} // end inner for
}
else
{
break; // end outer if
}
}
System.out.println("Comparisons = " + comparisons + "\tExchanges = " + exchanges);
return array;
}
After performing the worst case scenario on my code (using an array with 10 elements that are in the reverse order), I have gotten a total of 73 comparisons. This seems like a crazy high overshoot of the theoretical result which was 45 comparisons. This feels right to me though since I've accounted for all for loops and if statements.
Any help is greatly appreciated!
EDIT: I have noticed an error in my total comparison count for my inner loop. I wound up counting the inner loop twice before, but now it is fixed. Instead of getting 118 comparisons, I now get 73. However, the question still stands.
When measuring the number of comparisons in a sort, you only count comparisons between the array items. You count them whether or not they're actually in the array when you compare them.
The idea is that, instead of simple integers, the array might contain things that take a long time to compare. An array of of strings, for example, can be bubble-sorted using N(N-1)/2 string comparions, even though a single string comparison might require many other operations, including many comparisons of individual characters.
Measuring the performance of a sorting algorithm in terms of the number of comparisons makes the measurement independent of the type of things being sorted.
In evaluating sorting algorithms, it is common to count all comparisons between array elements as having equivalent cost, while ignoring comparisons between things like array indices. The basic concept is that in order for sorting operations to remain distinctly different from radix partitioning, the size of the items being sorted would need to increase as the number of them increased. Suppose, for example, one had an array of 1,000,000,000 char values and wanted to sort them. While one could use Quicksort, bubble sort, or something else, a faster approach would simply be to use an int[65536] and count how many of each value there are. Even if one needed to sort items which had char keys, the best way to do that would be to determine where to place the last item with a key of 0 (the number of items with a key of zero, minus one), where to place the last item with a key of 1 (number of items with keys of 0 or 1, minus one), etc. All such operations would take time proportional to the number of items plus the number of possible key values, without any lg(N) factor.
Note that if one ignores "bookkeeping" costs, algorithms like Quicksort aren't quite optimal. A sorting algorithm which is designed to maximize the amount of information gained from each comparison may do slightly fewer comparisons. Unless comparisons are very expensive, however, such a sorting algorithm would likely waste more time being "smart" than it would have spent being "stupid".
One issue I haven't seen discussed much, though I would think it could offer significant benefit in many real-world cases, would be optimizing sequences of comparisons between items that are known to be in a narrow range. If while performing a Quicksort on a series of thousand-character path names, one is processing a partition whose entries are all known to between two names that share the first 950 characters, there would be no need to examine the first 950 characters of any names in that partition. Such optimizations would not likely be meaningful in big-O terms unless key length was a parameter, but in the real world I would expect it could sometimes have an order-of-magnitude impact.
the comparison variable should only be incremented after the if statement has been reached in the execution of the code. The if statement is only reached if the condition stated in the outer and inner for loop have been met therefore the code should be like this.
Also dont forget to change the condition in the for loops from using != to <= The new java code:
public int[] bubble(int[] array)
{
int comparisons = 0;
int exchanges = 0;
int temp;
int numberOfItems = array.length;
boolean cont = true;
for (int pass=1; pass <= numberOfItems; pass++)
{
if (cont) // If any exchanges have taken place, cont will be true.
{
cont = false;
for (int index = 0; index <= (numberOfItems - pass); index++)
{
if (array[index] > array[index+1])
{ comparison++;
temp = array[index];
array[index] = array[index+1];
array[index+1] = temp;
cont = true;
exchanges++;
} // end inner if
} // end inner for
}
}
comparison++; // here you increment by one because you must also count the comparison that failed
System.out.println("Comparisons = " + comparisons + "\tExchanges = " + exchanges);
return array;
}
I have wrote the following 'segmented sieve' program in Java. It take a range of numbers to sieve, crosses out composite numbers using the 'sieving primes' (primes arraylist variable) then returns the prime numbers that have not been crossed out. Here is the code:
public ArrayList<Integer> sieveWorker(int start, int last, ArrayList<Integer> primes) {
System.out.println("Thread started for range: " + start + "-" + last);
ArrayList<Integer> nonPrimes = new ArrayList<Integer>();
ArrayList<Integer> primeNumbers = new ArrayList<Integer>();
ArrayList<Integer> numbers = new ArrayList<Integer>();
//numbers to be sieved
for (int i = start; i <= last; i += 2) {
numbers.add(i);
}
//identifies composites of the sieving primes, then stores them in an arraylist
for (int i = 0; i < primes.size(); i++) {
int head = primes.get(i);
if ((head * head) <= last) {
if ((head * head) >= start) {
for (int j = head * head; j <= last; j += head * 2) {
nonPrimes.add(j);
}
} else {
int k = Math.round((start - head * head) / (2 * head));
for (int j = (head * head) + (2 * k * head); j <= last; j += head * 2) {
nonPrimes.add(j);
}
}
}
}
numbers.removeAll(nonPrimes);
System.out.println("Primes: " + numbers);
return numbers;
}
My problem is that it's very slow and performing at a time complexity of o(n^3) instead of the expected time of complexity of o(n log log n). I need suggestions on optimisation and correcting its time complexity.
The culprit is the numbers.removeAll(nonPrimes) call which for each number in numbers (and there are O(n) of them) searches through all of nonPrimes potentially (and there are O(n log log last) of them) to check the membership (and nonPrimes is non-sorted, too). n is the length of numbers, n = last - start.
So instead of O(1) marking of each non-prime you have an O(n log log last) actual removal of it, for each of the O(n) of them. Hence the above O(n^2) operations overall.
One way to overcome this is to use simple arrays, and mark the non-primes. Removal destroys the direct address capability. If use it at all, the operations must be on-line, with close to O(1) operations per number. This can be achieved by making the non-primes be a sorted list, then to remove them from numbers iterate along both in linear fashion. Both tasks easiest done with arrays, again.
Explanation
numbers.removeAll(nonPrimes);
must find elements. That's basically contains and contains on ArrayList is slow, O(n).
It iterates the whole list from left to right and removes the matching elements. And it does this for every element in your nonPrimes collection. So you will get a complexity of O(n * |nonPrimes|) just for the removeAll part.
Solution
There is an easy fix, exchange your data-structure. Structures like HashSet where made for O(1) contains queries. Since you only need to add and removeAll on numbers, consider using a HashSet instead, which runs both in O(1) (ammortized).
Only change in code:
Set<Integer> numbers = new HashSet<>();
Another possibility is to do some algorithmic changes. You can avoid the removeAll in the end by marking the elements while you collect them. The advantage is that you could use arrays then. The big advantage then is that you avoid the boxed Integer class and directly run on the primitives int which are faster and don't consume as much space. Check the answer of #Will_Ness for details on this approach.
Note
Your primeNumbers variable is never used in your method. Consider removing it.
This is a common interview question.
You have a stream of numbers coming in (let's say more than a million). The numbers are between [0-999]).
Implement a class which supports three methods in O(1)
* insert(int i);
* getMean();
* getMedian();
This is my code.
public class FindAverage {
private int[] store;
private long size;
private long total;
private int highestIndex;
private int lowestIndex;
public FindAverage() {
store = new int[1000];
size = 0;
total = 0;
highestIndex = Integer.MIN_VALUE;
lowestIndex = Integer.MAX_VALUE;
}
public void insert(int item) throws OutOfRangeException {
if(item < 0 || item > 999){
throw new OutOfRangeException();
}
store[item] ++;
size ++;
total += item;
highestIndex = Integer.max(highestIndex, item);
lowestIndex = Integer.min(lowestIndex, item);
}
public float getMean(){
return (float)total/size;
}
public float getMedian(){
}
}
I can't seem to think of a way to get the median in O(1) time.
Any help appreciated.
You have already done all the heavy lifting, by building the store counters. Together with the size value, it's easy enough.
You simply start iterating the store, summing up the counts until you reach half of size. That is your median value, if size is odd. For even size, you'll grab the two surrounding values and get their average.
Performance is O(1000/2) on average, which means O(1), since it doesn't depend on n, i.e. performance is unchanged even if n reaches into the billions.
Remember, O(1) doesn't mean instant, or even fast. As Wikipedia says it:
An algorithm is said to be constant time (also written as O(1) time) if the value of T(n) is bounded by a value that does not depend on the size of the input.
In your case, that bound is 1000.
The possible values that you can read are quite limited - just 1000. So you can think of implementing something like a counting sort - each time a number is input you increase the counter for that value.
To implement the median in constant time, you will need two numbers - the median index(i.e. the value of the median) and the number of values you've read and that are on the left(or right) of the median. I will just stop here hoping you will be able to figure out how to continue on your own.
EDIT(as pointed out in the comments): you already have the array with the sorted elements(stored) and you know the number of elements to the left of the median(size/2). You only need to glue the logic together. I would like to point out that if you use linear additional memory you won't need to iterate over the whole array on each insert.
For the general case, where range of elements is unlimited, such data structure does not exist based on any comparisons based algorithm, as it will allow O(n) sorting.
Proof: Assume such DS exist, let it be D.
Let A be input array for sorting. (Assume A.size() is even for simplicity, that can be relaxed pretty easily by adding a garbage element and discarding it later).
sort(A):
ds = new D()
for each x in A:
ds.add(x)
m1 = min(A) - 1
m2 = max(A) + 1
for (i=0; i < A.size(); i++):
ds.add(m1)
# at this point, ds.median() is smallest element in A
for (i = 0; i < A.size(); i++):
yield ds.median()
# Each two insertions advances median by 1
ds.add(m2)
ds.add(m2)
Claim 1: This algorithm runs in O(n).
Proof: Since we have constant operations of add() and median(), each of them is O(1) per iteration, and the number of iterations is linear - the complexity is linear.
Claim 2: The output is sorted(A).
Proof (guidelines): After inserting n times m1, the median is the smallest element in A. Each two insertions after it advances the median by one item, and since the advance is sorted, the total output is sorted.
Since the above algorithm sorts in O(n), and not possible under comparisons model, such DS does not exist.
QED.
I need to write a method public int subList (CharList list)
that gets a list and returns how many times this list exist.
For example:
my list is a b c d a b g e
parameter list ita b it will return 2.
my list is b b b b
parameter list is b b it will return 3.
The method should be as efficient as possible.
Currently my problem is I don't know what do they mean when they say as efficient as possible, If I loop through the list n times, and everytime I find the same character I loop on both list and go back to where I was it will be O(n^2)? is there a better way to make is O(n) or below?
This is in effective searching string in a string, which is O(n) complexity
http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm
and as you find first occurrence you can just keep looking for next occurrence in remaining list so it's still O(n) to find all occurrence
Why O(n^2)? It is O(n) because the you need to iterate only once through the list.
Lets do this with a char[] to simplify the explanation.
The simple approach is as follows:
public int countSublists (char[] list, char[] sublist)
int count = 0;
for (i = 0; i < list.length; i++) {
for (j = 0; j <= sublist.length; j++) {
if (j = sublist.length) {
count++;
} else if (i + j > list.length || list[i + j] != sublist[j]) {
break;
}
}
}
return count;
}
This has worst-case complexity of O(N*M) where N is the length of list and M is the length of sublist. And best-case complexity of O(N) ... when there are no instances of the first character of sublist in list.
There are various other algorithms that give better performance ... down to (I think) O(N/M) best-case. The general idea is that you use the value of the character at list[i + j] when there is a mismatch to allow you to skip some characters.
You can find details of various advanced search algorithms are linked from the Wikipedia page on String Searching algorithms ... which also includes a summary of the respective algorithm complexity.
But the thing to note is that the advanced search algorithms all involve some precompution steps, whose complexity is some function of M. If N is small enough, the cost of the precomputation may outweigh the saving at search time. (On the other hand, if you are repeatedly counting the same sublist in different lists, and you can reuse the precomputed tables, then you can amortize the precomputation cost ...)