oh, it's actually my favorite song =)) still can't believe that there is an artist (in Viet Nam) dare to make it.

actually this is friendlier :) https://www.youtube.com/watch?v=qPpvKcNCMjY

Yeah, we planned for a contest long ago, but various things have happened in the last 5 months.

Problem : Give a string formed by the words "Mike" and "Mirzayanov", is it possible to have only "MikeMirzayanov" by removing characters from the front or back only?

# Sample 1:

Input: MikeMirzayanovMike

Output: YES

# Sample 2:

Input: MirzayanovMikeMike

Output: NO

# Sample 3:

Input: MikeMikeMikeMirzayanovMirzayanovMirzayanov

Output: YES

:D

siromaru is that you? :o

BMS/ToneSphere/Cytus/SUPERBEATXONiC/Chunithm/SDVX/GrooveCoaster/TsumaMia/Synchronica/Taiko/maimai/Rhythmsia/Deemo/Arcaea/Dance Rail/Tapsonic Top/Muse Dash/ONGEKI/PiU/TAKT-RHYTHM/WACCA/SEVEN'S CODE Any other missed bus stop(s)? XD

Maybe we can made Grievous Lady and Fracture Ray be the FINAL Problems ：D

Then next comes Cytus I, Deemo, VOEZ, Dynamix, Lanota, Hachi Hachi, Tone Sphere, Zyon

I wonder if anyone has the guts to make a round themed on Bandori, iDOLM@STER, or LLSIF. That'll be hilarious to see XD

I'm not sure if I could create a SDVX themed contest anytime soon...
Anyway, the song is quite popular in many rhythm games so I guess it ain't a poor choice.

Rest easy friend, there is no irrelevant picture in the problem statements.

Fortunately, anime is not present in this announcement

Problem D is too HARD.

People say he's still at the Black Market...

orz Itst Rhythm Game Master!

Unfortunately, I have a piano session with Alice at that time.

Weeb is love

Then Chinese will kill you.

It ain't that bad when you get the hang of the interactive mechanism. ;)

ConneR txdy!(The NO.1 in the world)

How does one give the contest?

will be out 3 seconds before the contest as usual :D

Atcoder then Codeforces :) what a fulfiled Sunday

Thanks, will include this in editorial after system test.

Start by putting 0 on one edge, and notice that it is pointless tu put 1 on an edge that is not consecutive to it, then you put 2 on an edge consecutive to 1 or 0, and so on, in short you form a path. Thus you can do a quadratic dp with state u,v where u and v are the ends of an already built path where you need to add the next number, adding it let's say to an edge that leads fro u to pu, will increase the solution by size(u->pu)*size(u->v) where size(a->b) is the size of all the tree but the subtree from b that contains the path to a so you try for each edge next to u and for each edge next to v (except the ones you already took) to add the edge, and see which gives you the best score

No. It isn't correct even for a simple path with more than 2 edges.

Not diameter, but DP for each path. We can extend a path with length $$$x$$$ (containing $$$[0,x-1]$$$) to length $$$x+1$$$ by adding $$$x$$$ to one edge adjacent to it.

you just need to worry when the column 1 connects to column 2. so, every step you have to see if it connects or disconnects, then add or discount the number of connections. If the number of connections is 0, the answer is yes

Maintain a counter of all blocked_passages in your grid.

Now, if the counter is 0. Then only a path is possible. Else, it is not possible. As there always be a way that is blocked so you can't reach your destination.

Now for each query, there are only a few cases possible that passage is blocked.

Case 1: Left Cross( i.e if you are in upper cell currently and in the previous column, down cell is blocked.You increase your counter).

Case 2: Same column

Case 3: Right Cross.

Now you can similarly decrease counter if you are turning off the lava cell.

AC submission

Hope you understood!

Can you solve this with 2D DP?

DP[a][b] being the current mex sum from node a to node b, DP[a][b] = max(DP[c][b] + sz[a] * sz[b], DP[a][c] + sz[a] * sz[b]) where c is the node in the tree that brings a & b closer to one another?

EDIT: I was like 10 characters away from this solution :( I calculated sz[a] and sz[b] incorrectly because I'm stupid.

I observed this one but didn't find any way to give weights that'll maximize the total sum. can you give some more hint?

At least for me (69143650), that part was obvious, but writing the DP to calculate the optimal answer was hard. DP on pairs (edge, direction) is very tricky and unusual.

Why the greedy doesn't work?

I check each leaf-to-leaf path. let $$$a[..]$$$ be array of size of sub-tree of that path.

pick max_i $$$a[i] * (n-a[i])$$$, then expand left/right by greedy compare which $$$a[l]*(n-a[r])$$$ is greater. sum it up.

everything in this problem is <= 10^16, long long goes up to ~10^19, you probabilly had some other bug

lower_bound(eil.begin(), eil.end(), i) might return eil.end(), and it is undefined behaviour to dereference the end iterator.

if vector doesn't contain element x, lower_bound return vector.end(). if u try to get the element of vector.end(), u got rubbish or RE(

I recommend using set<int> or map<int, int> instead of vector<int>, since all you really need to know is whether a given floor is closed or not. Beyond that your solution seems to be too slow. If I'm not mistaken, the loop for (int j = 1; j < store[0]; ++j) is $$$\mathcal{O}(n)$$$, which is too slow.

I managed to waste my time on stupid bugs, but generating a compressed tree seems pretty fast even when I'm map-ing exponent sequences to ints (extra slow log factor), probably because I'm removing trailing zeros, which are very common.

The number of points can be atmost 55. So, compute the points. Points will be sorted. Then go to i th point (for all i) from source point, and check how many points you will be able to get if you go to points on the left, and on the right. Take maximum between them. Just do this for all i.

Problem A and D were both pseudo-brute force that relied on the solution set being extremely limited (2000 points to check in A, and at most 55 in D). C was also a straightforward problem with emphasis on implementation, as in A and D.

all edge weights have to be distinct

Don't say that, at least I'm more stupid than you.

I assume block counts connected components. If so, it's strange that it could increment/decrement by $$$3$$$ each query. Maybe I'm not seeing your thought process, sorry.

I have WA on 132 :(

EDIT : Its indeed 1e17 * 100 overflow thing. changed limits to 2e16 and it passes :/

Many of the solutions failed due to overflow.

Here's a trick to avoid overflow. Say you set your limit to $$$10^{17}$$$, so when either coordinate gets that high, you stop. This means that you'll stop when $$$coord * a_x > 10^{17}$$$, ignoring $$$a_y$$$ because it's the same. If you instead change this condition to $$$coord > 10^{17} / a_x$$$, then overflow will not be an issue, and the inaccuracy of integer division will not be a problem if your limit is high enough. This is also nice because you don't have to worry at all about your limit being too high :)

I'm not disagreeing with you, $$$10^{16}$$$ was probably unnecessary, but this trick is still good to know in case the bounds are $$$10^{18}$$$ or something annoying in the future.