| Show all threads Hide all threads Show all messages Hide all messages |
| If one of players is waiting, meeting still takes place | bidzilya | 2105. Alice and Bob are on Bikes | 7 Aug 2026 22:15 | 1 |
Test case is mentioned in other topic 10 10 10 10 1 1 0 10 Answer is 10 |
| some tests | __Andrewy__ | 1905. Travel in Time | 5 Aug 2026 10:30 | 3 |
1) 4 4 1 2 9 15 1 4 0 8 2 3 20 30 3 1 31 0 1 4 9 30 -> 4 1 3 4 2 2) 2 3 1 2 0 5 1 1 110 80 1 1 90 0 1 2 100 6 -> 3 2 3 1 3) 3 6 1 2 50 55 2 1 55 40 1 2 0 1 1 3 41 80 3 2 80 12 2 1 15 0 1 2 49 7 -> 6 1 2 4 5 6 3 n= ; k= ; m=n*k <=100000 ------------------------ n m 1 2 1 1 1 2 2 2 ....... 1 2 k k 2 3 1 1 2 3 2 2 ....... 2 3 k k ....... ....... ....... n 1 1 0 n 1 2 1 n 1 3 2 ....... n 1 k k-1 1 1 k 0 --------------------------- for n=3, k=2 Ans. 2 4 6 1 3 5 Thanks, 3rd test helped to find a bug (I didn't register start/end times, so would output just 1 2 4 5) |
| Poor centipede :-D | Brooklyn | 1876. Centipede's Morning | 5 Aug 2026 09:52 | 3 |
One of the cutest problems in its statement :) |
| Understanding the solution | MARAZ MIA | 1876. Centipede's Morning | 5 Aug 2026 09:49 | 4 |
After so many calculation and math I have solved the problem..... Here we can have two worst cases... Case 1: having all the right shoes first.so here needed time is 2*b and we have now all the left shoes remaining...so total time is 2*b+40... Case 2: we may have 39 right shoes so time needed here is (39*2=78)...then we have only one right foot left but we may encounter all the left shoes and here needed time is 40+2*(a-40)....> 40 for the first 40 shoes and 2*(a-40) is for the remaining shoes as they needed to be thrown away...then we have the only one right foot left and it need 1 second... so total time = 78+40+2*(a-40)+1 = 119+2*a-80 = 2*a-39 ans=max(Case 1,Case 2) Edited by author 22.02.2020 03:07 But it's given that both a,b>=40.....so how 39 right shoes can be there? mistake in case 2: 119+2*a-80 = 2*a+39 everything else is correct Edited by author 11.01.2021 22:56 It can be solved with simple DP on number-of-left-picked-slippers x number-of-right-picked-slippers |
| Limitation of 64 Kb to source code size | Oleg Vasilenko (Chelyabinsk) | | 4 Aug 2026 13:27 | 1 |
Please, extend the limit for the size of submitted solution at least to 128 Kb. It is too hard to compress huge difficult solutions in 64 Kb without code obfuscation. There are some problems in this site that can require big source code (not pre-generated array of answers, but really huge algorithmic approach, like Voronoy diagram in 1369 or Sokoban/Ships) |
| WA3 | Solver | 2140. BitMazeCraft | 4 Aug 2026 12:25 | 1 |
WA3 Solver 4 Aug 2026 12:25 Forgot to check that cell above the start is empty when jumping |
| Test 15, something strange | diver_ru (free) | 1341. Device | 4 Aug 2026 11:15 | 4 |
I send program with such procedure: void moveNorth(double dist) { w += dist / rEarth * 180 / pi; if (w > 91.0) n = (n - n) / n; } And got crash 15, but when i send void moveNorth(double dist) { w += dist / rEarth * 180 / pi; } i got accepted. So, i think device can reach north pole with test 15 input data, but it's impossible. In this test the device flies too close to north pole. I got AC instead WA#15 when I changed PI from 3.14159265 to 3.141592653589. And I searched for a numerical mistake for 1 hour :) Ha-ha! Edited by author 03.03.2011 23:16 acos(-1) for the most precise value of PI, but still had WA15 with this code int rlat = (int)round(lat * 180 * 1000 / pi); int rlon = (int)round(lon * 180 * 1000 / pi); while (rlon <= -180 * 1000) rlon += 360 * 1000; while (rlon > 180 * 1000) rlon -= 360 * 1000; printf("%s%d.%.3d\n", rlat < 0 ? "-" : "", abs(rlat) / 1000, abs(rlat) % 1000); printf("%s%d.%.3d\n", rlon < 0 ? "-" : "", abs(rlon) / 1000, abs(rlon) % 1000); Then got AC with this code lat *= 180 / pi; lon *= 180 / pi; while (lon <= -180) lon += 360; while (lon > 180) lon -= 360; printf("%.3lf\n%.3lf\n", lat, lon); So I guess there is something like "-0.000" expected by checker Edited by author 03.08.2026 11:20 P.S: Checked with asserts for "-0.000" and "-180.000" results - it didn't fire. Maybe that stuff with 'round' is wrong way to do it with integers (I actually did that precisely to avoid fiddling with such outputs) |
| whats wrong with test 15? | Alias aka Alexander Prudaev | 1341. Device | 3 Aug 2026 11:21 | 3 |
Test 15 was incorrect, now it is fixed. 5 authors got AC. It is still not precisely correct, see the other thread |
| WA3 | Solver | 1341. Device | 3 Aug 2026 11:06 | 1 |
WA3 Solver 3 Aug 2026 11:06 -0.001 -0.002 0 my integer-based output omitted "-" sign in that case |
| WA #12 | 👨🏻💻 Spatarel Dan Constantin | 1540. Battle for the Ring | 2 Aug 2026 11:50 | 2 |
WA #12 👨🏻💻 Spatarel Dan Constantin 31 Oct 2014 06:15 The following test helped me: Input: 17 84 47 44 99 60 43 14 91 8 39 26 15 41 70 90 41 72 48 20 59 3 68 15 21 78 95 5 22 60 61 88 43 59 84 94 19 26 7 61 85 97 86 51 89 55 40 29 78 39 100 89 41 19 3 62 97 98 18 70 9 79 57 51 37 92 96 55 17 55 67 54 3 52 4 92 59 44 20 36 34 72 24 27 90 79 88 38 28 57 7 36 35 16 38 24 7 34 30 76 88 97 29 90 100 32 33 58 27 5 46 61 76 69 87 65 99 26 3 26 34 61 13 69 76 51 92 83 36 73 10 23 69 38 64 69 21 49 78 100 53 23 12 28 92 50 44 42 27 98 20 60 59 32 28 34 82 71 68 17 96 77 91 64 66 7 84 87 55 62 86 59 84 49 86 27 98 29 69 24 27 88 83 37 19 63 22 53 85 90 21 80 18 64 44 84 70 79 22 76 40 59 34 24 7 71 2 4 51 70 27 29 9 61 65 80 23 87 84 8 28 4 87 45 67 82 80 88 61 53 15 100 11 100 75 69 70 77 24 73 98 50 1 59 63 18 38 85 4 73 92 83 76 31 79 95 64 59 34 24 63 49 76 26 100 2 94 70 30 18 42 80 19 94 38 81 11 27 18 14 99 61 48 26 91 27 72 55 37 6 30 99 6 57 24 5 11 18 26 92 87 19 71 57 13 60 38 23 38 55 89 88 15 36 66 58 62 37 64 98 42 45 97 99 54 72 56 64 41 81 55 27 100 78 36 64 37 73 86 27 79 26 14 45 62 79 54 75 16 17 25 9 62 73 60 67 44 15 30 85 47 36 63 98 13 50 61 2 22 99 28 52 24 93 49 37 72 2 12 39 19 36 99 32 8 10 98 3 24 79 39 23 14 54 20 27 3 81 80 77 79 7 80 2 99 28 39 22 30 2 12 100 89 11 31 48 20 80 50 96 58 41 18 23 94 37 1 48 69 80 76 47 38 56 1 89 83 91 10 12 44 22 11 32 84 93 79 55 24 80 50 81 20 19 4 65 56 56 65 76 36 40 75 73 95 75 61 30 17 23 93 60 44 56 43 79 48 73 33 72 52 35 4 24 53 59 40 60 15 4 36 2 96 10 74 42 36 87 71 4 9 64 15 4 19 57 34 18 29 66 41 32 52 45 55 5 55 47 16 69 50 3 70 97 64 96 39 99 34 9 54 42 24 68 97 94 24 30 12 4 47 4 36 99 48 90 55 55 36 70 75 38 25 45 86 88 92 24 39 25 85 92 18 60 60 66 54 35 47 17 39 93 20 26 43 20 15 49 74 3 71 48 92 95 44 29 82 35 53 20 11 89 12 80 48 23 45 53 57 91 69 47 36 89 72 30 8 39 79 33 93 49 80 36 95 24 64 76 10 68 96 73 56 59 52 56 81 49 8 89 91 29 88 78 17 59 8 76 49 38 8 41 38 39 76 32 62 40 7 24 59 54 96 15 12 47 22 44 47 81 85 38 9 72 15 77 30 22 4 79 11 63 71 48 2 99 79 15 90 38 38 48 43 33 62 7 32 35 50 78 16 86 67 76 57 82 5 39 55 8 17 66 71 39 65 72 37 96 86 26 33 76 74 27 8 87 33 91 74 35 21 89 20 87 16 77 68 20 15 23 28 83 40 50 73 4 73 10 99 58 87 83 85 60 10 93 99 94 35 72 28 55 12 48 42 27 76 61 99 42 35 78 24 74 27 96 30 99 57 80 8 44 15 93 55 24 37 53 17 71 76 97 78 39 96 71 18 71 31 16 12 66 93 87 91 71 34 72 69 91 52 76 86 66 20 40 41 56 45 9 79 72 5 56 11 100 26 80 70 8 47 33 73 39 71 16 9 5 87 29 47 38 56 84 55 76 23 95 31 19 4 61 43 8 68 5 60 93 84 29 Output: G 1 67 Thanks, found a typo (my wrong output was 1 59 here) - scanned from 'zero' instaed of 'first' of a segment. Though I struggled with WA6 on that one. |
| is operations of int64(pascal) slower than long long(c++)? | frost | 1518. Jedi Riddle 3 | 1 Aug 2026 23:00 | 15 |
is operations of int64(pascal) slower than long long(c++)? I really optimized my prog to got AC(I write at Pascal). Please say how you did that on Pascal my algo O(N^3*logX) It work fast on my computer, but not on Timus :( Me and my friend had exactly the same algorithm and optomization but my program needs 1.7 and his needs 0.3secs (we both use C++) It is very hard to solve it in Pascal, so use C++ :) or rewrite program several times. It appeared, that FreePascal 2.0.4 compiler, which is used on Timus Online Judge, is extremely slow at arithmetical operations, especially on Int64-operands. "Mod" and "*" operations on Int64 are very slow. We did not expect such a thing, and we are sorry. Anyway, the jury HAS correct Pascal solution, which passes the timelimit (2 seconds), so it is a question of justice only, not of jury mistakes, problem incorrectness and so on. Now the timelimit is 3 seconds, and it is more than enough to solve this problem on Pascal without special optimization trick. My straightforward solution works exactly 2 second: http://acm.timus.ru/status.aspx?space=1&num=1518&pos=1383115 The problem will be rejudged soon. The performance of FreePascal 2.0.4 compiler in comparison with Delphi 7 compiler (dcc32 15.0) is under inverstigation. If Delphi appears to be faster (and it seems to be true), it would be added on Timus Online Judge. If you know the fastest Pascal compiler, please, tell us. It will be fair for Pascal programmers, because the fastest Intel C++ Compiler is used for C++. Edited by author 19.12.2006 21:43FreePascal generates very bad code for int64 multiplicatons. I use Delphi 7.0 and on my computer (AthlonXP 2200) my prog works 0.9 sec in worst case, but on Timus the same prog works 2.093 sec. I got AC in 1.261 sec with rewritng multiplication on Assembler. 19 authors get AC instead of TLE. 7 of them increase their score by 1 problem! My algo is also N^3*log(X), but not accepted in C++. how to solve it? Time limit in test case 13. anyone helps me ? Edited by author 20.12.2006 01:17 My solution is also O(logX*N^3) but my program written on Java works so slowly... for example, It works about 6 seconds on test 100 268435455 268435455 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I can't even imagine how to solve it without rewriting solution using another language... Edited by author 08.01.2007 19:20 Since the matrix consists of only zeroes and ones, you can perform half of multiplications using just +, - and >= via 32bit types. Perform only squaring via __int64 and %. This helped to make my 2.9 sec C++ solution running at 1.5 sec. - [BSU] nzamulov 15 Jun 2026 17:01 Edited by author 15.06.2026 17:02 Correct answer for the test 100 268435455 268435455 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 is 94769974, btw Actually performing "fast" multuplication via if (m[k][j] && (cv += cm[cur][i][k]) >= y) cv -= y; performed slower then than the general case (0.062sec vs 0.046sec) The actual trick here is that 2^28*2^28*100 fits in 63 bits, so you have to apply expensive %mod operation only once for every cell (i.e. n^2 mod operations per matrix multiplication) |
| WA 2 | Combatcook [YarSU] 🐸 | 2106. Deserialization | 1 Aug 2026 22:23 | 4 |
WA 2 Combatcook [YarSU] 🐸 12 Dec 2016 01:57 Does anyone know some tests to overcome WA 2? Re: WA 2 Jane Soboleva (SumNU) 12 Dec 2016 07:23 Fixed mine after realizing that FFFFFFFF won't fit properly into a signed type. Re: WA 2 Combatcook [YarSU] 🐸 12 Dec 2016 16:36 Thanks, Jane, the same problem - forgot to replace longint on int64 before submit :) |
| WA23 | andreyDagger`~ | 1990. Podracing | 1 Aug 2026 21:07 | 2 |
WA23 andreyDagger`~ 3 Jan 2024 20:12 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 Did everything with double/integers - AC. Though had WA22 due to (lx[cl + 1] - lx[cl]) * (y - ly[cl]) overflowing int32 before it was multiplied by double coefficient for 'y' :) |
| which answer are correct | RainAir | 1345. HTML | 1 Aug 2026 17:26 | 3 |
Input: _123 My first solution output: _<span class=number>123</span> My second solution output: _123 But all passed. So which answer are correct? Task description says: "The correct source of a program in Pascal is given" Your input is definitely not correct source _123 should be correct - you eat up identifier all along |
| I hate this problem | Keworker `~ | 1191. Catch the thief! | 1 Aug 2026 11:55 | 2 |
Statement is unclear. If you want to solve it you must try all possible interpretations of this statement 'till find the one that the author intended. trams are leaving at times k*1, k*2, k*3, ... if cop gets to the station the moment thief boards, it's not a catch yet Edited by author 01.08.2026 17:51 |
| Good problem! | wangbicheng1 | 1162. Currency Exchange | 28 Jul 2026 12:07 | 2 |
You need to have a deep understanding of the bellman-ford algorithm, especially THE RELAXING OPERATION Edited by author 29.07.2026 11:46 |
| Some review | Igor Parfenov | 1464. Light | 28 Jul 2026 11:13 | 2 |
The idea of problem is pretty interesting. But for me it was implementation hell. Made it with almost 1st submit, so I'll describe my way of avoiding "implementation hell". First of all obvious things: x[i] -= x0, y[i] -= y0, so origin is at zero. x[n]=x[0], y[n]=y[0] to reduce amount of 'if's. Second, all that we love with precision maths. I.e. a == b --- fabs(a-b)<eps a > b --- a > b + eps a >= b --- a > b - eps eps=1e-8 is enough here, but I did it without trigonometry The main idea is that every segment covers some range of angles [a1;a2], so we have a set of "control points" of the form "angle;seg-i-start", "angle;set-i-end". So when you have this set of control points, segments will not change their relative order between two consecutive control points which can be checked by intersecting a ray and checking square of distance. Now on how to avoid trigonometry in these and other problems like convex hull - just store vectors (segment endpoints). When comparing them for an "angle", first check the side. Let side=0 be the [0;pi) range - that is 'dy>0 || dy==0 && dx>0', then side=1 goes for [pi;2pi) range. Then you just compare sides, and if side is the same, check the sign of cross product for comparison. You will also need a special record for 2pi (side=2), I coded it as dx=0,dy=0, but be careful to treat it as (1,0) when raycasting later. Now, ignore segments which contain origin in negative subplane (or on zero, i.e. no control points for them). Then the only thing to be dealt with is crossing 2pi-0 boundary. Criteria here is 'y[i]<0 && y[i+1]==0' - then it starts at (x[i];y[i]) and ends at (0;0). Or 'y[i]<0 && y[i+1]>0' then it starts at (x[i];y[i]), ends at (0;0), then starts at (1;0) and ends at (x[i+1];y[i+1]). These are just for 'angular' sorting of control points. After that you will have first control point at (1;0) (angle=0) and last control point at (0;0) (angle=2pi). The rest is just running through them. Pick all control points which are 'equal' on that angular criteria, and process them - i.e. add/del corresponding segments to the heap according to px[i];py[i] ray intersection length for that control point. Let the next control point which is 'greater' according to angular criteria be 'j', after that pick topmost (nearest) segment from the heap, get intersection with px[i];py[i] ray, and px[j];py[j] ray (here don't forget to treat 0;0 as 1;0). After that add their cross product to the answer. |
| How to solve it? | Fdg [Kyiv NU] | 1772. Ski-Trails for Robots | 27 Jul 2026 19:14 | 6 |
DP + sqrt-decomposition (or tree-like structure) I think that Djkstra in graph of robot's ends will work. No need for Dijkstra or sqrt decomposition :) Nodes are (0,s), (i,l[i]-1), (i,r[i]+1) where applicable. The main idea is that you do not have to bend towards edges if you can go in a straight line, you can always make that adjustment later when necessary at the same cost. However, tracing all these rays for every obstacle will quickly MLE/TLE. To work around this you need to answer quickly location of nearest obstacle further ahead. This can be done with going back-to-front and paint over segment tree with lazy propagation. Nodes which have no obstacles ahead going in a straight line are terminal nodes (start may also be such, then the answer is 0). So it's K*log(N) to track those nearest obstacles for each of K*2+1 nodes, and then easy BFS from left to right. And don't forget about int64. Edited by author 08.07.2026 23:27 (LLM-written, always verify, but current AC #1 beating all previous entries) There’s another O(k log n) way: treat the current answer as a function of the trail number. After each obstacle this function is still made only of `+1/-1` linear pieces, and processing an obstacle just replaces its blocked interval by at most two new pieces. A lazy segtree is enough. (LLM-written, improved to 0.015s) There’s also an amortized O(n + k) way: store only the boundaries of those `+1/-1` linear pieces. Each obstacle creates only constantly many new boundaries and may erase old ones; since every erased boundary had to be created earlier, the total number of such operations is linear. The bounded trail indices allow predecessor/successor queries in O(1). |
| WA/RE18 | Solver | 1464. Light | 27 Jul 2026 12:19 | 1 |
There is a segment whose extension contains the origin |
| a few tests | Михаил Аршинов | 2070. Interesting Numbers | 26 Jul 2026 19:56 | 2 |
1000 100000000000 99999971585 10 100 86 17 500 476 13841287201 = 7^12 25937424601 = 11^10 31381059609 = 3^22 68719476736 = 2^36 152587890625 = 5^16 |