| № | Пользователь | Рейтинг |
|---|---|---|
| 1 | tourist | 3757 |
| 2 | jiangly | 3647 |
| 3 | Benq | 3581 |
| 4 | orzdevinwang | 3570 |
| 5 | Geothermal | 3569 |
| 5 | cnnfls_csy | 3569 |
| 7 | Radewoosh | 3509 |
| 8 | ecnerwala | 3486 |
| 9 | jqdai0815 | 3474 |
| 10 | gyh20 | 3447 |
| Страны | Города | Организации | Всё → |
| № | Пользователь | Вклад |
|---|---|---|
| 1 | maomao90 | 171 |
| 2 | awoo | 165 |
| 3 | adamant | 163 |
| 4 | TheScrasse | 159 |
| 5 | maroonrk | 155 |
| 6 | nor | 154 |
| 7 | -is-this-fft- | 152 |
| 8 | Petr | 147 |
| 9 | orz | 146 |
| 10 | pajenegod | 145 |
Hi!
I started a blog recently, and one of my recent discussions on FFT led me to post a new blog post at https://nor-blog.codeberg.page/posts/2024-06-01-implementing-fft/ exploring some FFT algorithms — more specifically, alternate (potentially better) implementations that not many people are aware of. The contents of this post might be a bit well-known to people who write their own FFT templates, but having a good understanding of FFT should help others too.
When submitting to 1923E - Count Paths, I noticed that 248189683 takes 124ms and 248191037 takes 420ms.
Both of these are the same code (can be confirmed via diff), and there is no indeterminate behaviour like randomness involved in the submissions. It looks like it points to some issue with the judging machines (maybe one judging server is just slower than the other or the server load was high).
Pinging MikeMirzayanov for increasing chances of this getting fixed. Thanks!
I am a logic gate. Ask me anything.
