ive been trying to the problem and have become stuck. The specification of the problem is a as follows
Median of k numbers is defined as the (k/2)th
smallest number if k is even; and the ((k+1)/2)th
smallest number if k is
odd. For example, median of the 4 numbers: 2 1 8 7 is the 2nd smallest number i.e. 2, and the median of the 5
numbers: 2 1 8 7 6 is the 3rd smallest number i.e. 6.
In this problem, you'll be given N numbers. Let the kth
median or m(k) be defined as the median of the first k
numbers (1<=k<=N). i.e. the 5th
median or m(5) is the median of the first 5 numbers, the 8th
median or m(8) is the
median of the first 8 numbers, etc. In other words, let Ai
denote the ith
number, then the kth
median or m(k) is
defined as the median of the numbers A1, A2, …, Ak.
Your task is to find m(1) + m(2) + m(3) + ...+ m(n), output the sum modulo 100000
so basically you have to read in numbers, first number is stored in the variable N and dictates how many numbers to be read in after that point is. (this is always 5). Then you must iterate through the reading in of the numbers, storing them in array, then sorting them and then finding the median of the median and then store the value in the and repeating until all numbers have been read in, sorted and median found.
I have managed to read the numbers in fine and i am able to sort them to some degree but my sorting algorithm, sorts them highest values first and smallest values last and in order to get the program to run properly to get the desired output i need it to be the other way round and i cant work out how.
The numbers read in will be like so
5
10
5
1
2
15
and the answer would be 27.
This is my code
Any help on this problem would be amazing because im just going round in cirles, btw the System.out.println(myIntArray [4]) etc is just a tracer to see how the sorting is taking place
You seem to be sorting the entire array each time through. You need to sort from 0 to i (exclusive) at each iteration. Also, for odd length, you need parentheses when computing the subscript: myIntArray[(i+1)/2] instead of myIntArray[i+1/2]. Because of operator precedence, Java will evaluate the latter as myIntArray[i+(1/2)], which is just myIntArray[i], since 1/2 is 0 in integer division.
Related
I was attempting to do practice questions and came across a solution I do not understand the reasoning behind.
The question can be found here, finding the number of even sum subarrays.
https://www.geeksforgeeks.org/find-number-subarrays-even-sum/
Questions related have been asked, but I am asking specifically about the use of the handshaking lemma at the end of the solution.
I understand that we build a count of the even and odd sum subarrays, but do not get why we use the hand shaking lemma to compute the number of even sum subarrays. If we get a count of even and odd cumulative sums, how does the handshaking lemma exactly play into this? Clearly, an even sum subarray is made of either odd + odd, even + even, or a lone even value, so I would just like to know how exactly all cases are being accounted for in this specific scenario. Thanks for your help!
First we have an array of numbers, for example:
[1,3,5,2,10,7]
So, how to count the number of subarray with even sum?
Let's convert it into another array called sum, which the value at index ith is the sum of subarray from 0 to ith index
[1,4,9,11,21,28]
Clearly, we can see that for a subarray from range a to b, the sum of this subarray is even if and only if sum[b] - sum[a - 1] is even.
Now, let imagine that a graph connecting between odd and odd entry in sum and even and even in sum -> the number of edges in this graph is the answer for this problem.
So, from the handshake lemma, 2*E = sum of all vertexes degree
The degree of each odd vertex is number of odd vertex - 1
The degree of each even vertex is number of even vertex - 1
=> so
2*E = odd*(odd - 1) + even*(even - 1) => E = odd*(odd - 1)/ 2 + even*(even - 1)/2
Another way to understand this is for odd entries, the number of ways to choose odd - odd pairs is C(odd, 2) = odd*(odd - 1)/2 with C is the combination
For a given odd number n I want to efficiently compute 3 primes whose sum is equal to n. If there are multiple solutions then I want the one with the smallest primes (I want 2+2+17=21 instead of 3+5+13=21)
This is always possible forn>5.
My current approach is to reduce the problem to computing 2 primes whose sum is equal to n-3 and then I simply output the 2 computed primes and 3 since they obviously sum up to n. I choose 3 since it is the smallest odd prime and when I subtract it from n I get an even number, therefore it should be part of every solution I'm looking for. I'm using this to compute the sum of 2 primes, it works if n is even which it is in my case (since I subtracted 3 from an odd n).
My approach doesn't work since there are solutions without a 3 as a summand (41=2+2+37).
Is there a straightforward approach which I'm missing?
First test whether n-4 is prime. If so, your answer is {2, 2, n-4}. Otherwise, your original approach will work. You'll never use just one 2 because your sum would be even.
I already know how to calculate the median, mean, mode from an array in Java. But is there actually a way to do the reverse like creating an array from the median, mode, mean, given the range and the number of numbers in the array ?
The numbers in the array can be created by randomness as long as it satisfies the condition above. It can stop when successfully find the first array with that condition. And plus the range can be from 0 to 10 or 0 to 100, not so much.
Yes / No
When you do an array to mmm, you are applying a lossy algorithm, you are losing the original data.
There can be literally an infinite number of array combinations that would result in the same mmm.
Some naive ideas
Median: for example your array have 2n+1 elements, put n elements which are less than your median, n elements which are greater than median;
Mean: say your array have m elements, Sum = m * Mean, generate m elements by partitioning Sum;
Mode: count the frequency of the numbers you put into the array, make sure Mode has the highest frequency;
I came across this question in a recent interview.
Given an array find the maximum product that can be obtained multiplying any 3 numbers in the array.
The solution I came up with is,
Sort the array
Multiply the 3 largest number.
This is O(nlogn)
Is there a O(n) solution to the problem?
Instead of sorting all the values, you can retain the top three, which is O(3n) which is O(n)
Doing this in a single pass is likely to be more efficient than three passes.
One way of doing this is to do an insertion sort into an array of 3, discarding the lowest value each time. (you can start at the lowest value in the array)
You can also implement this using a series of if/else comparison to update 3 variables.
How about negatives?
The only complication is if you can have negative values e.g. 5 * -4 * -4 > 5 * 5 * 3
For this reason it would makes sense to search for the three largest and the two most negative. You can check whether the largest * the next two largest or largest * the two most negative is bigger.
what if they are all negative?
In this case, you also need the three smallest negative values as well to get the product closest to positive infinity.
You can do it in O(n) as follows:
Find the largest number in O(n); remove the number from the array (make it zero)
Find the largest number among the remaining numbers in O(n); make it zero as well
Find the largest number among the remaining numbers, again in O(n)
You repeat the same O(n) loop three times, so it's O(3*n), which is the same as O(n) because constants are ignored.
This won't cater to negatives
It is relatively easy to modify this algorithm to work with negative numbers. Each pass through the array needs to find the largest and the smallest negative value, so at the end you would have three large positive numbers P0, P1, P2 and thee large negative numbers N0, N1, N2, in ascending order by magnitude. Now you need to compare P0*P1*P2 vs. N1*N2*P2, and pick the larger one.
There are O(n)-time complexity solutions to this problem, but these will only occur depending on the input of your array, as you can read in this article
You can perform this in 1 pass by storing largest elements from array A to to array of 3 say B.
For each element n in array A if n is greater than any element in array B then replace array B element with array A element.
Finally multiply the 3 elements in resulting array. This is constant time. This may still be 3n since you are checking against array of 3 as well.
For negative it would be additional 2 elements which contain the smallest. So it may be 5n but still constant time
I have two list of numbers, for every member of the second one I must tell if it's obtainable using all the numbers of the first one and placing '+' or '*' and as many '(' ')' I want.
I can't change the order .
List1 can contain a max of 20 elements beetween 1 and 100.
List2 can contain max 5 elements beetween 1 and 20'000.
EX:
List1=[2 4 3 5]
List2=[19 15 24]
19-> 2+(4*3)+5 YES
15 NO
24->2*(4+3+5) YES
With brute force it takes ages to handle inputs with List1 larger than 10.
edit: numbers are always positive.
edit:
I find the max and min numbers that are obtainable from the list and then I discard all the possibilities that have the target outside this range, then I try all the remaining ones.
MAX=n1*n2*n3*....*ni if there are 1 thei r added to their smallest neighbour
MIN=n1+n2+....+ni 1 excluded
Still it's not fast enough when input are big (List1 longer than 10 or numbers in List2 bigger than 10000)
For each sublist of List1, compute the numbers between 1 and 20,000 that can be made with that sublist. The resulting DP bears resemblance to CYK.
I'm being somewhat vague here because this is almost certainly a programming contest problem.
#u mad is correct, but I'll give a little more detail.
Suppose that n = size of list 1. For each 0 <= i < j < n you need to compute all of the distinct values in the range (1..20_000) that can be made from the numbers in the interval [i, j-1]. You can do this with recursion and memoization.
Once you've done this then the problem is easy.
You could try a smart brute force which discards sets of equations by chunks.