Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Before contest

Codeforces Round #492 (Div. 1) [Thanks, uDebug!]

02:03:37

Register now »

Codeforces Round #492 (Div. 1) [Thanks, uDebug!]

02:03:37

Register now »

*has extra registration

Before contest

Codeforces Round #492 (Div. 2) [Thanks, uDebug!]

02:03:37

Register now »

Codeforces Round #492 (Div. 2) [Thanks, uDebug!]

02:03:37

Register now »

*has extra registration

# | User | Rating |
---|---|---|

1 | tourist | 3434 |

2 | Petr | 3353 |

3 | OO0OOO00O0OOO0O0…O | 3314 |

4 | fateice | 3306 |

5 | Um_nik | 3286 |

6 | Syloviaely | 3274 |

7 | dotorya | 3145 |

8 | LHiC | 3114 |

9 | Radewoosh | 3098 |

10 | mnbvmar | 3096 |

# | User | Contrib. |
---|---|---|

1 | tourist | 178 |

2 | rng_58 | 165 |

3 | Petr | 155 |

3 | csacademy | 155 |

5 | Swistakk | 149 |

5 | lewin | 149 |

7 | Um_nik | 142 |

8 | Errichto | 140 |

9 | Vovuh | 138 |

9 | matthew99 | 138 |

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial is loading...

Tutorial of Educational Codeforces Round 32

↑

↓

Codeforces (c) Copyright 2010-2018 Mike Mirzayanov

The only programming contests Web 2.0 platform

Server time: Jun/24/2018 17:31:23 (d2).

Desktop version, switch to mobile version.

User lists

Name |
---|

I liked this round. Generally, the idea of educational rounds is very good. That one in particular expanded my horizons. Usually, when you learn MST, you think: "Why should I bother with Prim's or Boruvka's algo? Just learn Kruskal and forget about the rest". Task G reminds us that every algorithm is important and can have its own unique application.

Before this round, I didn't even know about the existence of Boruvka's algorithm.

Neither did I.

Educational Rounds always teach us about some cool new algorithm or an application of an old algorithm that is not quite popular. :-)

FWIW, you can solve this by starting with Kruskal's algorithm too. If you only look at the highest bit at

b= 29, and split your vertex set into two halvesV_{0}andV_{1}(one with all vertices where bitbis turned on, the other all the vertices where this bit is turned off). It follows that internal edges in eitherV_{0}orV_{1}will have bitbturned off, but edges between the two components will have this bit turned on. Thus, if you were to run Kruskal's algorithm you would first enumerate all internal edges inV_{0}andV_{1}before considering edges between the two components. It follows that Kruskal's algorithm would first connect all ofV_{0}into a single tree (V_{1}respectively), and then find a single connecting edge between the two components.This gives you a simple recursive algorithm: Split on the highest order bit

b, solve these two halves recursively (only considering bits <b), and then find the weight of the single connecting edge, i.e. given two sequences of values, find the pair of values with minimal exclusive-or. This last problem can be solved using a very similar recursion.Code: 32170476

Hey guys! Here are some of my thoughts on the meet-in-the-middle techniques on problem E: http://robezhang.blogspot.com/2017/11/meet-in-middle-technique-on-educational.html Feel free to ask questions and give suggestions!

It is a similar problem but makes it easier to understand this technique.

Here is another problem that is kind of similar: https://www.codechef.com/MAY17/problems/CHEFCODE

Wow cool! It is also a good problem!

Did you remove the post ?

Oh, I've just changed my url for my personal website. You can check this: https://robezh.blogspot.com/2017/11/meet-in-middle-technique-on-educational.html, I hope this is helpful to you.

Hey ! Finally had time to look through your post ! I did find it helpful ... But, you explained how to solve finding four integers who's sum is 0. I wish you explained something about this problem as it's quite challenging compared to that problem. However, I was able to understand your code. :)

Why don't you put your implemented codes with the tutorial?I think it will be helpful for many of us :)

For problem C can someone explain this part:

" Write down lengths of segments between two consecutive occurrences of this character, from the first occurrence to the start of the string and from the last to the end of the string."

Let k be the maximal length such that there exists segment of length k that doesn't include character c. You can take all the occurrences of character c and check where this segment can fit. Thus maximal distance between those occurrences and ends of the string will get you maximal k.

how the bitmask solution look like for Probelm E?

i think the bitmask is for easy iteration over all possible subsets. Suppose there are n elements then iterate over 0 to 2^n for all possible subset generation.

Look at my codes for the problem F. I wrote a solution using an algorithm Boruvki but unfortunately it got TLE. Even though my realization is not good as author might have expected to see, I think 2 seconds for the problem which has complexity of is (very) tight

Try first sorting numbers. I have no idea why it works, but I also had time limit with same solution and sorting the numbers mad code at least 2x faster.

Doesn't the Boruvka's algorithm work for graphs with distinct edge weights only? In the case of problem G, how is that guaranteed?

It is not guaranteed, hence the warning.

`but we should be careful to avoid adding edges that form cycles in MST`

Can you please elaborate how is the repetition avoided ??

The problem is with duplicates. Instead of dealing with just weights of edges, consider the pair (w, i) for each edge, where w is its weight and i is the edge index. Now no two pairs are same as each edge has a different index and you can run Boruvka's algorithm as usual.

Code

Got it , thank you.

Can anybody elaborate D? for m, 0<=m<=k, pi != i. isn't this a derangement? How can there be nCm ways to do this?

If I understand correctly, the editorial claims that the answer for B is always n — dx — dy. Can someone prove it mathematically? How about an intuitive proof?

Was just trying to figure out how I can come up with such ideas myself in the future. This sounds like a genius idea to me but I am not sure why it works.

You start at (0,0) so if you end up at some (dx,dy) it means you have gone atleast dx in the x axis in the same direction and dy in y axis in the same direction. so it means if you come back dx and dy steps in the respetive directions you will be back at (0,0). For example consider this case 6 LLRRRR

you are at 0,0 initially now you go l l so you are at (-2,0), then you go r r r r so you are at (2,0) which is 2 places right of the place you need to be(ie (0,0)) so you subtract that from 6 and you get 4 which is the answer. Hope this helps

Is it possible to solve G using prim's algorithm with 2sec time limit? cause i'm getting time limit error and was wondering if it's my coding problem or algorithm with O(ElogV) time complexity.

Problem G can be simply solved by trie with 2 keys 0 or 1.

Complexity = O(n * (30 or max(log ai))

Why there is a

two pointerstag on Problem C?Why is the time limit so strict for G? I'm almost using same solution as Editorial, and it takes ~2300MS to pass all test cases, but time limit on CF is 2000MS.