My code is running in O(nlogn) but still getting TLE…only hardware level optimisation required.I am wasting my time to optimise it for more 0.5 sec…so please increase its Time limit by 0.5 sec because in java object takes more time than struct in cpp.
Why so strict Time limit O(n^2) solution won’t even run in 10 sec?
I agree with you . My solution without fast IO could not pass the 2nd subtask. However you have a double time limit in java right? So are you using fast IO or not because i think it should solve the problem.
Although I agree with you I would suggest you write this request in in the comment section of the problem rather posting in the forum
Also it’s better if you don’t reveal your time complexity during the contest
Heavy-Light decomposition on the tree. This can be done in O(n) time.
Using what I call a merge tree on the heavy segments. That is, for each Segment Tree mode keep a sorted array of elements in that range, binary search for the location of the most expensive magic edge, and use prefix xor sums for finding their xor. This takes O(nlogn) space and uses O(logn) time to answer a query per heavy chain, which comes out to O(log^2n) time per query.
Using fast IO.
So java can pass with O(nlogn) space and O(nlogn + qlog^2n) time solution. Use a better implementation next time.
@ureino, I used the exact same concept as you just mentioned but did in c++, no matter how I try to optimize it I was getting TLE for the 5th test case, in the end had to use a different technique altogether to get it to work. It’s insane that, if I had tried the same code in java, I would’ve gotten AC but the same code in c++ gives TLE.
Solved using DFS order property and Segment trees. Initially I used cin and cout for I/O but it gave only 30 points. Then instead of cin and cout I used scanf and printf which gave full 100 points and maximum time taken for test case was only 0.63 seconds.
Here is a different approach for an online solution - (solved in Java btw):
Needed info:
persistent segment tree
“sparse” segment tree - if an interval has no value > 0 then the no need for the subtrees
reuse the memory allocated in previous tests
So basically keep a persistent “sparse” segment tree of numbers 0 … 10^9 to keep track of all the numbers present from the root to the specific node. When a query is done we just have to ask in the persistent seg tree of the node the xor value for the interval [0, K].
The query time is O(log(M)) where M is the 10^9.
First implementation gave TLE and after some debugging I’ve noticed that queries where “peanuts” compared to the build of the date structure. As we all know Java is “good” that you do not have to handle the memory but unfortunately the allocation and GC internally could be a pain in the ass.
So the thing done in order to pass was to allocated from the beginning the maximum nodes that can be used for a test case = O(Nlog(M)* which is at most - 30 * 100 000 → 3 * 10^6.
Also in the following tests will reuse the same nodes.
Hope this will save to others the time I’ve lost investigating.