We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.

In the description of this problem, it says "If Lena wins the contest, her luck balance will decrease by L; if she loses it, her luck balance will increase by L." I added all the "luck" to total assuming she loses all in the beginning. Winning those games should not only NOT "increase by L" (-luckToFlip to make it even), it should also "decrease by L" (-luckToFlip again).

import java.util.*;
This is the solution came up with, the formatting might be a little easier to understand.

public class Solution {
public static void main(String[] args) {
Scanner in = new Scanner(System.in);
int numContests = in.nextInt();
int maxLosses = in.nextInt();
ArrayList<Integer>contestLucks = new ArrayList<Integer>();
int totalLuck = 0;
for(int i = 0;i<numContests;i++){
int currContestLuck = in.nextInt();
int temp = in.nextInt();
if(temp ==0)totalLuck+=currContestLuck;
else contestLucks.add(currContestLuck);
}
Collections.sort(contestLucks);
for(int i = 0;i<contestLucks.size();i++){
if(i<contestLucks.size()-maxLosses)totalLuck-=contestLucks.get(i);
else totalLuck +=contestLucks.get(i);
}
System.out.println(totalLuck);
}
}

Unfortunately, the "Collections.sort" method degrades the performance to O(N*log(N)). Besides, the "ArrayList" collection uses an additional O(N) amount of memory. An optiomal solution should run in O(N*log(K)) time and use O(K) space.

In terms I can even understand: Essentially he got the total luck, (all positive), then you remove the luck from winning contests (neutral) but you actually LOSE luck from winning contests, so you need to go negative (take it away again).

Multiplying with 2 as we have already calculated the luck in total luck so if we are losing the competition instead of gaining X point we are losing the X point so luck =
(total - 2 * X)

Unfortunately, the "Collections.sort" method degrades the performance to O(n*log(n)). Besides, the "List" collection uses an additional O(n) amount of memory. An optiomal solution should run in O(n*log(k)) time and use O(k) space.

Some performance add-ons would be to just add the zero luck values directly to the resultant luck. The new array would only contain the must win.

Sort the array(O(k * log(k)) where k is the number of 1s).

Finally, Iterate the 1s array and where for each n:
if(k <= 0) => result = result - n;
else => result = result + n; k--;

Basically, accumulate all the luck you can until you run out of k, once k is zero, start reducing your luck (you will be spending least luck value for reduction)

cause a problem, Since Arraylist size is less than n, the variable mustWinImprCount will be initialized with negative value causing the for loop to cease in the beginning?

Why not use a heap (PriorityQueue in Java) to remove the need for the O(nlog(n)) operation of sorting the array. Adding to a heap is O(log(n)) in worst-case, but O(1) in the average case. Since that happens n times, it should be faster on average. See my implementation:

// Complete the luckBalance function below.staticintluckBalance(intk,int[][]contests){intnumLuck=0;inttotalImportant=0;PriorityQueue<Integer>minHeap=newPriorityQueue<Integer>(newComparator<Integer>(){@Overridepublicintcompare(Integerobj1,Integerobj2){returnobj1-obj2;}});for(int[]contest:contests){numLuck+=contest[0];if(contest[1]==1){minHeap.offer(contest[0]);totalImportant++;}}for(inti=0;i<totalImportant-k;i++){numLuck-=2*minHeap.poll();}returnnumLuck;}

You will be adding n elements to your heap. For each insert it is logn and therefore for n elements, it would be n * log n. No difference is performance. Since there won't be anymore addition/deletion after the sort, it would not make any difference to choose heap over list.

As mentioned elsewhere, the heap should be kept at k. Average case, insertion is O(1), so the average case complexity of the overall luck balance algorithm in O(n). Worst case is O(nlogk). Therefore, only in the worst case scenario, and also when k=n, does the algorithm implementing the heap perform the same as the sort. In all other cases, the heap outperforms.

## Luck Balance

You are viewing a single comment's thread. Return to all comments →

This is the same problem I have done in Week Of Code 21. I copied my solution in Java:

very nice and elegant solution

in the statement int result = total - 2*luckToFlip; why have you put 2*luckToFlip insted of just luckToFlip?

In the description of this problem, it says "If Lena wins the contest, her luck balance will decrease by L; if she loses it, her luck balance will increase by L." I added all the "luck" to total assuming she loses all in the beginning. Winning those games should not only NOT "increase by L" (-luckToFlip to make it even), it should also "decrease by L" (-luckToFlip again).

I don't understand your explanation

import java.util.*; This is the solution came up with, the formatting might be a little easier to understand.

Unfortunately, the "Collections.sort" method degrades the performance to O(N*log(N)). Besides, the "ArrayList" collection uses an additional O(N) amount of memory. An optiomal solution should run in O(N*log(K)) time and use O(K) space.

In terms I can even understand: Essentially he got the total luck, (all positive), then you remove the luck from winning contests (neutral) but you actually LOSE luck from winning contests, so you need to go negative (take it away again).

Multiplying with 2 as we have already calculated the luck in total luck so if we are losing the competition instead of gaining X point we are losing the X point so luck = (total - 2 * X)

because he has added that luck also which is need to be deleted so he deleted that twice.

very nice solution

Unfortunately, the "Collections.sort" method degrades the performance to O(n*log(n)). Besides, the "List" collection uses an additional O(n) amount of memory. An optiomal solution should run in O(n*log(k)) time and use O(k) space.

exactly same as mine.

Very nice! Based on this i wrote it in c#

Some performance add-ons would be to just add the zero luck values directly to the resultant luck. The new array would only contain the must win.

Sort the array(O(k * log(k)) where k is the number of 1s).

Finally, Iterate the 1s array and where for each n: if(k <= 0) => result = result - n; else => result = result + n; k--;

Basically, accumulate all the luck you can until you run out of k, once k is zero, start reducing your luck (you will be spending least luck value for reduction)

there is my code, works

Hi. Nice solution. For a challenge, try using quickselect to improve runtime like in this O(n) average runtime solution.

HackerRank solutions.

thanks man

would it improve the performance if we replace the last part with

?

for a test case n == k wont the line

cause a problem, Since Arraylist size is less than n, the variable mustWinImprCount will be initialized with negative value causing the for loop to cease in the beginning?

Why not use a heap (PriorityQueue in Java) to remove the need for the O(nlog(n)) operation of sorting the array. Adding to a heap is O(log(n)) in worst-case, but O(1) in the average case. Since that happens n times, it should be faster on average. See my implementation:

You will be adding n elements to your heap. For each insert it is logn and therefore for n elements, it would be n * log n. No difference is performance. Since there won't be anymore addition/deletion after the sort, it would not make any difference to choose heap over list.

Instead of letting the heap grow, keep it at size k. Now, each insert is logk instead of logn, and the total complexity is therefore nlogk.

As mentioned elsewhere, the heap should be kept at k. Average case, insertion is O(1), so the average case complexity of the overall luck balance algorithm in O(n).

Worst caseis O(nlogk). Therefore, only in the worst case scenario, and also when k=n, does the algorithm implementing the heap performthe sameas the sort. In all other cases, the heap outperforms.Just completed this problem and this solution is eerily similar to mine:

Great minds think alike? haha