Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I need to propose an algorithm for the following: let us assume that we have an array consisting of zeros and ones. The array is filled with zeros from the beginning of the array to the index m, and all remaining indexes are filled with ones. I need to find this index m in O(logm) time. Here is what i thought: I think this is like binary search, first i look at the middle element of the array, if that is zero, then i forget about the left part of the array and do the same for the right part, and continue like this until i encounter a one. If the middle element is one, then i forget about the right part and do the same for left part of the array. Is this a correct O(logm) solution? Thanks
It is not "like" a binary search - it is a binary search. Unfortunately, it is O(logN), not O(logM).
To find the borderline in O(logM), start from the other end: try positions {1, 2, 4, 8, 16, ... 2^i} and so on, until you hit a 1. Then do a binary search on the interval between 2^i and 2^(i+1), where 2^i+1 is the first position where you discovered a 1.
Finding the first 1 takes O(logM), because the index is doubled on each iteration. After that, the binary search takes another O(logM), because the length of the interval 2^i..2^(i+1) is less than M as well.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
A question has arisen on an old exam paper used for revision which asks about a type of sorting that I cannot find the name of anywhere. Hopefully somebody here can help, please?
b. Produce an algorithm which will sort an array so that the largest
items are on the ends and the smallest in the middle. For example:
[2,6,5,9,12] might become [12,6,2,5,9]
Make one pass through the sequence to find the largest value, the second largest value, and the smallest value. Swap the largest to one end, the second largest to the other end, and the smallest to the middle. Voila: largest items are on the ends and the smallest is in the middle. Calling this a "sort" is silly.
I guess the point is to create the algo yourself:
Just an idea:
biggest = value of first element
smallest= value of first element
For all elements of the array do:
If value of current element > biggest
biggest = value of current element
Add biggest as last element of the array
If value of current element < smallest
smallest = value of current element
End of for loop
Move last element of the the array at first position
#now the biggest is the first element, the second bigger number is the last one
Put smallest at middle position of the array [idx max / 2 rounded up]
# now the smallest is in the middle
I hope it helps.
Thomas
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
In terms of Big - O notation the linear search is a x^n, but what is the binary search? I am not 100% that the linear search is correct.
Linear search means that you will have to iterate through the list of elements until you find the element that you were looking for.
For instance, if you have a list with elements [1, 3, 5, 7, 9, 11] and you are looking for 11 you will start by the first element, then the second element, and so on, which in this case will take 6 iterations.
Generally, we could say that in the worst case you will have to traverse the whole list; so it will take n iterations, where n is the number of elements on the list.
So we say that the linear search algorithm is O(n).
In the case of binary search, you start on the middle element of the list:
Case 1: the number we are searching is the same as the number on the middle element: we are done!
Case 2: the number we are searching is smaller: we will only search the elements that precedes the middle element.
Case 3: the number we are searching is bigger: we will only search on the subsequent elements.
In our example, the number we are searching is 11 and the middle element is 5; since 11 > 5, we will only search on the sublist of the elements bigger than 5, namely [7, 9, 11].
Now, we will keep doing the same until we find the element that we are searching, in this case it takes only three iterations to get to the last element.
In general this approach takes log(n) iterations; therefore, the algorithm is O(log(n)).
Note that the latter only works for sorted lists.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Wondering if anyone have worked on similar problem before? And my question is, why {8, 6} are peaks? I think 8 is peak, but since 6 is smaller than 8, it should not be a peak? Thanks.
In an array of integers, a "peak" is an element which is greater than or equal to the adjacent integers and a "valley" us an element which is less than or equal to the adjacent integers. For example, in the array {5,8,6,2,3,4,6} {8,6} are peaks and {5,2} are valleys. Given an array of integers, sort the array into an alternating sequence of peaks and valleys.
Example,
Input: {5,3,1,2,3}
Output: {5,1,3,2,3}
thanks in advance,
Lin
The 6 referred to is the 2nd 6 at the end of the sequence. This fits the description well (if not made very clear) and is backed up by 5 being a valley.
An alternating sequence of peaks and valleys is a sequence such that either all of the elements in odd-numbered positions are peaks and those in even-numbered positions are valleys, or vice-versa. The output sequence in the example demonstrates the elements of the input sequence sorted in such a way.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Imagine you are given a matrix of positive integer numbers (maximum 25*15, value of number does not exceed 3000000). When you do column sums and pick the smallest and the largest one, the difference between them must be the smallest possible.
You can swap numbers in every row (permute rows), not in column, how many times you want.
How would you solve this task?
I'm not asking for your code but your ideas.
Thanks in advance
I would make an attempt to solve the problem using Simulated Annealing. Here is a sketch of the plan:
Let the distance to optimize the difference between the max and min column sums.
Set the goal to be 0 (i.e., try to reach as close as possible to a matrix with no difference between sums)
Initialize the problem by calculating the array of sums of all columns to their current value.
Let a neighbor of the current matrix be the matrix that results from swapping two entries in the same row of the matrix.
Represent neighbors by their row index and two swapping column indexes.
When accepting a neighbor, do not compute all sums again. Just adjust the array of sums in the columns that have been swapped and by the difference of the swap (which you can deduce from the swapped row index)
Step 6 is essential for the sake of performance (large matrices).
The bad news is that this problem without the limits is NP-hard, and exact dynamic programming at scale seems out of the question. I think that my first approach would be large-neighborhood local search: repeatedly choose a random submatrix (rows and columns) small enough to be amenable to brute force and choose the optimal permutations while leaving the rest of the matrix undisturbed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Call every subunitary ratio with its denominator a power of 2 a perplex.
Number 1 can be written in many ways as a sum of perplexes.
Call every sum of perplexes a zeta.
Two zetas are distinct if and only if one of the zeta has as least one perplex that the other does not have. In the image shown above, the last two zetas are considered to be the same.
Find all the numbers of ways 1 can be written as a zeta with N perplexes. Because this number can be big, calculate it modulo 100003.
Please don't post the code, but rather the algorithm. Be as precise as you can.
This problem was given at a contest and the official solution, written in the Romanian language, has been uploaded at https://www.dropbox.com/s/ulvp9of5b3bfgm0/1112_descr_P2_fractii2.docx?dl=0 , as a docx file. (you can use google translate)
I do not understand what the author of the solution meant to say there.
Well, this reminds me of BFS algorithms(Breadth first search), where you radiate out from a single point to find multiple solutions w/ different permutations.
Here you can use recursion, and set the base case as when N perplexes have been reached in that 1 call stack of the recursive function.
So you can say:
function(int N <-- perplexes, ArrayList<Double> currentNumbers, double dividedNum)
if N == 0, then you're done - enter the currentNumbers array into a hashtable
clone the currentNumbers ArrayList as cloneNumbers
remove dividedNum from cloneNumbers and add 2 dividedNum/2
iterate through index of cloneNumbers
for every number x in cloneNumbers, call function(N--, cloneNumbers, x)
This is a rough, very inefficient but short way to do it. There's obviously a lot of ways you can prune the algorithm(reduce the amount of duplicates going into the hashtable, prevent cloning as much as possible, etc), but because this shows the absolute permutation of every number, and then enters that sequence into a hashtable, the hashtable will use its equals() comparison to see that the sequence already exists(such as your last 2 zetas), and reject the duplicate. That way, you'll be left with the answer you want.
The efficiency of the current algorithm: O(|E|^(N)), where |E| is the absolute number of numbers you can have inside of the array at the end of all insertions, and N is the number of insertions(or as you said, # of perplexes). Obviously this isn't the most optimal speed, but it does definitely work.
Hope this helps!