# | User | Rating |
---|---|---|
1 | tourist | 3985 |
2 | jiangly | 3814 |
3 | jqdai0815 | 3682 |
4 | Benq | 3529 |
5 | orzdevinwang | 3526 |
6 | ksun48 | 3517 |
7 | Radewoosh | 3410 |
8 | hos.lyric | 3399 |
9 | ecnerwala | 3392 |
9 | Um_nik | 3392 |
# | User | Contrib. |
---|---|---|
1 | cry | 169 |
2 | maomao90 | 162 |
2 | Um_nik | 162 |
4 | atcoder_official | 161 |
5 | djm03178 | 158 |
6 | -is-this-fft- | 157 |
7 | adamant | 155 |
8 | awoo | 154 |
8 | Dominater069 | 154 |
10 | luogu_official | 150 |
Name |
---|
How to solve D with centroid decomposition?
Never mind, I understood. You can maintain dynamic diameter and greedily take it :)
Btw if you thought about that greedy, there is a much better way to solve it. By the algorithm, one end of diameter is always in a solution. And the connected subgraph with $$$2k$$$ leaves can be covered with $$$k$$$ paths. Thus you can root the tree and find the $$$2k-1$$$ leaves. It can be done with same greedy (with much easier segtree) or even simpler greedy in linear time.
Good point! So, just a bit more thinking could have saved me a lot of implementation trouble :)
By the way, well done getting the Voronoi problem accepted, you clearly don't shy away from implementation trouble!
For problem F, I'm not really sure why you needed both persistence and a 2D data structure; I just statically built up a 2D data structure representing the pre-flip rectangles, and then used its nodes as my graph nodes. For the 2D DS, I recommend static (offline) segtree of segtrees. For each outer segtree node, gather the set of all inner coordinates which will be updated/queried at this node and then coordinate compress to build an appropriately sized inner segtree. It uses O(n log n) memory and has O(log^2 n) query time, and also lets you just use segtree book code if you want. The static outer segtree is also easier to use than persistence.
I guess I didn't know a 2D data structure that supports both range updates and range queries. When I thought about a segtree of segtrees, I was not sure how to handle the following case: when one of the rectangles is very narrow, it will only be handled very deep inside the outer segtree, and then when the query is very wide, it will be handled at the top of the outer segtree and thus we won't notice the intersection?
In general, it's hard to do 2D range update/range query, lazy propagation in particular doesn't work. For this problem, we only care about whether two rectangles intersect, not the size/amount/location of intersection, so we can use this trick:
Two 1D ranges [a,b) and [c,d) intersect, iff either a is in [c, d) or c is in [a, b). In 1D, we can these solve with a point-query/range-update segtree and a range-query/point-update segtree. In the 2D case, we can take either choice for x and either choice for y, so there are 4 possibilities, and we solve it using 4 2D seg trees. One of these seg trees is point-in-rectangle queries, another is rectangle-contains-point queries, and two are horizontal/vertical line intersection queries.
For E, I did expected implementation trouble in the beginning, but in the end it turned out to be rather straightforward. If you take the Voronoi cells with half-plane intersection, the rectangular boundary doesn't make the problem harder, you just put all adjacent vertices in Delaunay triangulation with four more halfplanes. Then you can get a polygonal representation which transforms the problem into pure graph problem (although with some real-number hassle)
what do you do with machine of 64GB of RAM ?
open 1k tabs in google chrome
This (well, almost) but unironically
https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
the problem is that he uses windows 10.
Thanks for that!