If you're interested in learning more about CPU hardware details and how they affect program performance, read my blog post here on how memory latency impacts binary search and causes an $$$O(\sqrt[3]{n})$$$ runtime.
Enjoy!
# | User | Rating |
---|---|---|
1 | tourist | 4009 |
2 | jiangly | 3823 |
3 | Benq | 3738 |
4 | Radewoosh | 3633 |
5 | jqdai0815 | 3620 |
6 | orzdevinwang | 3529 |
7 | ecnerwala | 3446 |
8 | Um_nik | 3396 |
9 | ksun48 | 3390 |
10 | gamegame | 3386 |
# | User | Contrib. |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
3 | maomao90 | 162 |
3 | atcoder_official | 162 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 157 |
8 | TheScrasse | 154 |
9 | Dominater069 | 153 |
9 | nor | 153 |
If you're interested in learning more about CPU hardware details and how they affect program performance, read my blog post here on how memory latency impacts binary search and causes an $$$O(\sqrt[3]{n})$$$ runtime.
Enjoy!
I recently wrote an article about Schonhage-Strassen on my personal blog here. It is an algorithm to multiply two N bit integers in time. If you want additional background on the signal processing stuff mentioned in the article, read the first part of the post here.
I doubt this will be useful for competitive programming because Schonhage-Strassen has a pretty high constant factor and is pretty tedious to implement--in general floating point FFT-based solutions are fine for competitive programming size inputs and NTT-based stuff like this is overkill. Hopefully some of you will still find it interesting though!
Here's a technique to do C — New Year and Curling in time with segment tree. Brute force n2 is of course fast enough, but I think speeding it up was interesting.
Suppose we are about to place disk i at xi. The relevant x range we should look for disks is [xi - 2r, xi + 2r] because things outside of this range are too far away to intersect with this disc. Say we find j such that j < i, xj is in the needed range, and yj is maximized. We can find such j with a basic segment tree in time. The intuition behind the approach is that is a good lower bound for yi. Specifically, yi < yi' + 2r as shown by the diagram:
In this worst case scenario we find that disk j corresponds to the left disk. However, another disk is centered at (xi, yj - ε). So yi' in this case is yj but the true answer is yj + 2r - ε. If we could find the second-highest circle with our segment tree, we'd get the answer right in this case. We can do this by first querying [xi - 2r, xi + 2r] and getting back a result xq1. Assume xq1 < xi (the other case is symmetric); we next query (xq1, xi + 2r]. Say this second query result is xq2 with xq2 > xi (again other case is symmetric); we next query (xq, xq2) to get the third-highest circle. If we do this just a few times we're guaranteed to get the right answer.
The reasoning behind this is that a constant number of circles fit in the "relevant area," regardless of what n or r are. The relevant area is a 4r x 2r rectangle horizontally centered at xi and with the top y value yq1. It's the black box in the diagram above. If a disk's center is horizontally outside this range, the disk won't intersect the query disk. If the disk is below the relevant area, it's too low to matter (yi' is higher). And no disk can be above this area because of how yq1 is defined. The relevant box has area 8r2, and any circle centered in it must occupy at least π r2 / 4 area, so at most 10 circles inside of the box. So, if we do our procedure 10 times (so 10 segment tree queries), we're guaranteed to get the answer. 10 is a pretty loose bound and I got AC with 4.
Name |
---|