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.
Very neat little problem! I'll try to give a few hints without giving too much away. Btw, I used a somewhat different approach to the editorial - so there're definitely more than 1 way to tackle this.
1) There's a definite DP feeling to this problem (Editorial talks about this explicitly). I started by formulating a very straighforward O(N^2) approach.
2) Next step was to take O(N^2) to something better. It quickly became apparent that if I could find points on the plant faster than O(N), say O(LogN) - I'd resepectively improve the overall asymptotic.
3) Luckly I was already faimilar with KD-trees, Oct-trees and the like.
I chose Quad-tree for this problem due to the following (hints):
a) Simple and compact implementation
b) LogN updates..This is what swayed the decision.
c) LogN quries. This is shared with other "binary" data structures and is not what swayed the decision.
4) Whilst quad-tree is LogN update/query, often enought we need to ask quesitons about all points. If done naively that degenerates to O(N) even with quad tree.
However, if we keep track of the desired propeties in every tree node - and only recurse when we need to - this becomes desired LogN again.
5) Last step was needed only to pass the last test (I saw someone else in the discussion also getting 63 points and not 70 due to timeouts).
Whilst the bound on q-tree is LogN - there're just too many of those quries. We can improve on 4) by only recursing when we know the recursive call might be able to improve the result. This aggressively culls useless branches from the quadtree ontop of the already good LogN time.
Cookie support is required to access HackerRank
Seems like cookies are disabled on this browser, please enable them to open this website
Maximizing Mission Points
You are viewing a single comment's thread. Return to all comments →
Very neat little problem! I'll try to give a few hints without giving too much away. Btw, I used a somewhat different approach to the editorial - so there're definitely more than 1 way to tackle this.
1) There's a definite DP feeling to this problem (Editorial talks about this explicitly). I started by formulating a very straighforward O(N^2) approach.
2) Next step was to take O(N^2) to something better. It quickly became apparent that if I could find points on the plant faster than O(N), say O(LogN) - I'd resepectively improve the overall asymptotic.
3) Luckly I was already faimilar with KD-trees, Oct-trees and the like. I chose Quad-tree for this problem due to the following (hints): a) Simple and compact implementation b) LogN updates..This is what swayed the decision. c) LogN quries. This is shared with other "binary" data structures and is not what swayed the decision.
4) Whilst quad-tree is LogN update/query, often enought we need to ask quesitons about all points. If done naively that degenerates to O(N) even with quad tree. However, if we keep track of the desired propeties in every tree node - and only recurse when we need to - this becomes desired LogN again.
5) Last step was needed only to pass the last test (I saw someone else in the discussion also getting 63 points and not 70 due to timeouts). Whilst the bound on q-tree is LogN - there're just too many of those quries. We can improve on 4) by only recursing when we know the recursive call might be able to improve the result. This aggressively culls useless branches from the quadtree ontop of the already good LogN time.