This contest was held on October 22nd, but no solutions have been posted. Any ideas for FGH?
# | 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 | 151 |
This contest was held on October 22nd, but no solutions have been posted. Any ideas for FGH?
Name |
---|
Why the fuck are you minusing this post? It is a NP-Hard problem to understand CF Community. LOL.
http://codeforces.net/blog/entry/55503 this similar blog gets +20 while this got -4...
To be honest, much more than the community itself, I'm sick of people complaining about it...
I am sick about people complaining about people complaining about it.
I am sick about people complaining about people complaining about people complaining about it.
Ahhh... Not this again :/
For problem G (the complexity is , not sure if it fits the time limit):
The x and y coordinates are completely independent, therefore we just have to solve the same problem twice.
To process the queries we use Mo's algorithm. At each step of the algorithm we keep a balanced tree of the values currently in the range (the balanced tree must also keep the sum on a subtree) (a treap seems perfect).
When we add (or delete) a new value to the balanced tree , we also update the answer accordingly. Indeed the new answer differs from the previous one by s - 2p - (t - 2c)v (where v is the new value, p is the prefix sum, s is the total sum, c is the position in the balanced tree, t is the total number of elements in the tree).
I tried doing something like that here, but I think it's too slow.
Compressing coordinates and using a Fenwick tree instead of a treap might speed it up a lot.
Ideas for F:
The coloring always exists and is always unique.
Assume for now that no line is vertical. Let be the number of lines below a point p. Then the color of p is given by .
Hence we want to compute the number of lines below a query point. This can be done with the Bentley-Ottmann sweepline algorithm. As the algorithm maintains the relative position of the lines in a BST, we can do a binary search to count the number of lines below the point. The time complexity is .
To improve the runtime, split the lines into k blocks of size . Run the above algorithm for each block. This takes time, which is for .
In order to account for vertical lines, add to the color of each point where is the number of lines to the left of p. can be computed easily in .
Ideas for H:
For each segment, consider the line thought the segment and for each endpoint of the segment the line thought that point perpendicular to the segment. Construct the arrangement of the lines. This takes Θ(n2) time and space.
For every segment, look at the arrangement-edges from it's line and mark all edges that are part of the segment. (By construction all edges are either part of the segment or contain no common interior with the segment). For every edge not marked this way, connect the two faces sharing this edge. Then sum over all faces that are not connected to the infinite face. The total runtime is Θ(n2), as the arrangement has size Θ(n2) and every line gets split into edges.
There might also be a solution based on random sampling, as the required precision is quite low.