CHANOQ [Unofficial Editorial] (Chef And Odd queries) FEB LONG

can you please explain this part a bit more : “Now, since we have carried forward from our previously processed segment, then say for a query q1 if we haven’t pushed this current segment no and the previous segment no was pushed, it implies that the change in the no of points while shifting l and r pointers was even, which in turn implies that the current segment also contains odd+even= “odd” no of points in q1. On the other hand if current segment number is pushed, it implies that the points are now odd+odd= “even”.”

Thank you!

How do find the bound on \sum_{i=1}^{q} ans[i].size() ? How do you make sure that we will always be able to store these many numbers in the memory (considering allowed memory is \leq 512 MB) ?

Dear contributors,
Can anyone make a video editorial on CHANOQ .? It is difficult for many users to understand the editorial (including me). Big thanks if anyone can post a video on it.

Hey, thanks for the editorial, I understood your clever solution, but when I tried to implement it, I am getting segmentation fault for some reason, if it’s not too much trouble can you look into the code once? CodeChef: Practical coding for everyone thanks in advance.
Edit: I got it, I had done a trivial mistake. Thanks for the editorial.

Really Good editorial @kaushal101. (A bit late to review, I am i guess).

1 Like

Assume a scenario where
1.For each query sort the points that gives O(mlogm)
2.For Each Interval do a binary search over that gives overall O(Nlogm)
3.Total Runtime is O((m+n)logm))
Please correct my analysis if i am wrong

This approach gave TLE why??
Thanks in Advance
code:
https://www.codechef.com/viewsolution/17249574

@kaushal101 can you please explain how the last part of your code is calculating the answer for each query? "Then it implies that for segment nos 1 to 3,the count was odd. At seg 4, count switched to even,so from seg no 4 to 5,count was even. The count again switched to odd at 6, so from 6 to 10, the count will stay odd. Since we have to only find the odd count, we sum the difference between every two alternate segment nos. As of here, the count is : (4-1)+(10-6) . We do this for each query, ans[i] will hold the list of seg nos for a query."

I read it many times but still I’m confused!

on what i learnt from Mo’s algorithm,i implemented this… getting SIGSEGV and TLE …
Surely something is wrong with my approach… Could anyone care to point it out…
my solution -CodeChef: Practical coding for everyone

Post it Here : Feedback Of February Challenge 2018 - general - CodeChef Discuss

1 Like

Ohk i think u didnt caught my solution.

Here it is: CodeChef: Practical coding for everyone

It passed as i think there were some weak test cases (but not very weak)

Say there are queries , q1-> (1,2,3,5) and q2-> (1,4,5)
And say there are two segments 1-3 and 1-5. While processing the first segment, q1 contains points 1,2,3 and q2 contains 1, so both are odd, as a result; we will push segment no. 1 in both q1 and q2.
Now while processing the next segment, we only process the points (4,5) as (1,2,3) is already processed. … (contd.)

2 Likes

…(contd.) For this q1 contains (5) and q2 contains (4,5); Since q1 contains odd,we push seg no 2 in q1. Since segment no. 1 was also pushed, it implies that, now the no of points contained in seg2 for q1 has become even (odd + odd=even) [ (1,2,3) was odd and (5) was also odd but the total (1,2,3,5) has become even ]. And for q2, since nothing is pushed, it implies that no of points is still odd [ (1) was odd , (4,5) was even , so (1,4,5) is still odd] . Hope its clear :slight_smile:

2 Likes

Last time please! Here we have segments like (1, 3) and (1, 5). But what if they were partially overlapping?

Glad you liked it :slight_smile:

1 Like

ans[i] actually holds the no of flips from even to odd and vice versa for the query i. Since there are N segments , one can argue that there can be N flips in the worst case, thus making ans[i].size=N.
But, the sum of all points over all queries is at max 10^6.And in the average case (atleast for all the cases I could think of), it won’t be very big. Still plz do post cases where it wont run, it would be appreciated :slight_smile:

1 Like

This editorial, I think must be clear enough. Just go through the MO’s article once.

1 Like

Doesn’t matter still. Say u had segments (1,3) and (2,5). First u will process points 1,2 and 3. Then for the next segment, using MO’s, we will just process the points (1,4,5) [1 is the excluded point, and (4,5) are included]. It still gives the correct result.

1 Like

@piyush_97

The thing about video editorials is, that It takes a lot of time to get everything right, and usually suited for General data structures and/or Algorithms which have a wider audience, rather than a problem. Still great of those fellows who make problem specific video editorials for specific problems, you should learn to rely on textual editorials as most of the time you’ll come across textual one. I know video editorials are comfortable, but it’s all about coming out of your comfort zone to improve.

You are doing binary search for each query over each segment. That makes it O(NQlog(m)). Hence TLE :frowning:

1 Like

First of all, ur comp () fn is wrong:
It must be:

bool comp(node a,node b)
{

if(a.block<b.block)
    return true;  

else if (a.block>b.block) // u havent added this  

    return false;  

else
    return (a.right<b.right);

}

Doing this runs the 1st subtask. Now, u are applying MO’s for each query qhich is giving TLE. Preprocess all the query points, and apply MO’s only once.