|
|
It's very strange but it seems that even long double precision doesn't enough for this problem. I had function get_x(polyline, y), that calculates x coordinate of polyline on coordinate y. I implemented it through binary searching and then calculating by formula, but that resulted in WA23. Then I made an optimisation: if polyline has integer point with coordinate y: (x, y), I instantly return x. Edited by author 03.01.2024 20:12 My algorithm is linear, except the quicksort procedure. It gets TLE at Test #24. What happened? I have checked the program multiple times. Thanks. It's very weird - almost happened to me too (0.934 sec, dunno which test). After that I switched to 'int' and kept 'double' only for boundaries - it became 0.5 sec. Then I precalculated 1.0/(y[i+1]-y[i]) - timing didn't change. Then I suspected it was some anti-qsort case, tried to random-shuffle, even tried heapsort - no matter, still 0.5 sec. Then I've noticed that I am submitting it as GCC instead of VisualC (was testing another problem before on GCC/clang) - got 0.171 sec with same code :) GCC suxx. Dunno if it's input or sorting or what. I was using scanf/printf (cin/cout are slower in VisualC even with iostream::sync_with_stdio(false)). How to treat cameras, located on the starting and/or finish line? Do racers interact with them? My AC solution treats those cameras as if they interact with the racers. 2 0 0 0 2 2 2 0 2 2 1 1 -1 -> 2 (not 1) cin/cout with cin.sync_with_stdio(false) is 0.25 s, while scanf/printf 0.375 s. use my own code..... my id: 151799QY The last time I submitted code, is my own code.... Edited by author 21.11.2013 21:17 Is it correct? almost linear algo gets TL! ID: 5285869, line: 108: what happens if statment under "if" will be true? :) Sh..t, thanks, added 2 lines and AC =( +1 to stupid mistakes that spoiled the whole contest =( BTW, the contest was cool, thanks! Edited by author 27.10.2013 01:41 |
|
|