Общий форумMake sure your graph is more than 1296 and try these 3 2 1 2 0 1 5 0 * 3 1 8 2 3 0 1 -5 0 2 25 0 * 2 1 8 2 22 3 -15 0 2 19 3 -50 0 ans = -20 =========================== 4 2 1 2 0 1 5 0 * 4 1 8 2 3 0 1 -5 0 2 25 0 1 22 2 -3 0 * 3 1 8 2 22 3 -15 0 2 19 3 -50 0 4 -1 2 -5 0 * 4 1 -8 2 18 0 1 -5 0 2 -19 3 -22 0 1 12 0 ans= -39 ============================== 2 2 1 2 0 1 5 0 * 4 1 8 2 3 0 1 -5 0 2 25 0 1 22 2 -3 0 ans = -3 ========================== 4 2 1 2 0 1 5 0 * 4 1 81 2 23 0 1 56 0 2 25 0 1 22 2 -31 0 * 3 1 8 2 22 3 -15 0 2 19 3 -50 0 4 -1 2 -5 0 * 4 1 82 2 18 0 1 59 0 2 39 3 52 0 1 112 0 ans = -2 1) greedy works here, although it's not that much obvious how *correct* greedy should look like 2) 5th test case, that didn't pass for me: 12 -3 10 -2 8 -1 16 0 0 Edited by author 17.02.2018 04:30 the only idea/key take-away of this problem is to properly combine calculation of integer and floating point numbers Edited by author 15.02.2018 03:31 var a,b,c:real; begin read(a,b); writeln(a+b); end. Edited by author 14.02.2018 23:36 Edited by author 14.02.2018 23:36 Try this: 2 2 1 2 1 2 Ans: Yes 1 2 It is okay to use an edge if the next cleaning for this edge begins at the exact moment when you have crossed the edge. In other words a road is cleaned during the open interval (s_i, f_i). Edited by author 12.03.2016 20:21 n = int(input()) a = [] summ = 0 for i in range(n): a.append(int(input())) b = list(set(a)) for i in range(len(b)): c=a.count(b[i]) if c > 3: summ+=c//4 print(summ) Epsilon to compare squared distances must be exactly 1.0 / (1 << 24) (at least for M*N algo). Even 23 and 25 leads to WA. (std::numeric_limits< float >::epsilon() / 2) is absolute accuracy needed overall. You can invent twofold float-then-double algorithm to sieve bad points beforehand. For single precision algorithm part you have to use 20.1f (20 + small constant) "epsilon" to compare squared distances in case if you use <= or >= operator (say, vcmpge_oqps or vcmple_oqps instructions) and 28.2f (28 + small constant) in case of strict inequality. Surely you can invent adaptive algorithm to infer relative accuracy needed in particular test case, which takes into account max abs differences of input point coordinates. epsilon should be explicitly specified in the problem statement, it is not hard to make a test to break even simplest O(n*m) double precision solution. I totally agree. The problem should be reformulated in integers or other way to make use of arbitrary precision numbers. Also 10000*100000 is too small dimensionality to encourage participants to make submissions of O((N + M) * log(N + M)) solutions due to high constant factor of latter. Stupid algorithm with randomization and trivial vectorization is faster (and extremely easier to implement) then clever algorithm with Voronoi and point location. I thought that this problem is so easy. After many tries to solve that I should say: that is not so easy and I cant solve it! Please, if you DP-master tell me where I'm wrong. So, the state is dp[sum][length] += dp[sum - digit][length - 1], for each digit 0..9. The base is dp[1..9][1] = 1. I've got WA#10: My program for 10 output: 43756 (correct answer: 43749) I can't find a little bug ;( [code] for s := 1; s <= S; s++ { for l := 2; l <= 9; l++ { for d := 0; d < 10 && s - d > 0; d++ { if dp[s - d][l - 1] == 0 { continue } dp[s][l] += dp[s - d][l - 1] if d == 0 { dp[s][l]++ } } } } [/code] Please anyone... You don't need to store previous positions: for (int position = 2; position <= 9; position++) for (int sum = 81; sum > 0; sum--) for (int digit = 1; digit <= 9; digit++) if (sum >= digit) ways[sum] += ways[sum - digit]; because you have to start l at one and eliminate continue and s - d >= 0 No. You are wrong here. I've found my error, it was a dp base. Thx for all. Guys, what are you doing in New Year? Hahaha I don't understand what's wrong with my code. Help me pls. Thnx in advance. #include<stdio.h> int main(){ int L, H; scanf("%d%d", &L, &H); printf("%d %d ", 10 - L, 10 - H); return 0; } It said not more than 10 cans... thus there could be less than 10 cans Once Harry and Larry shoot a common can... you gotta consider that too... I use Dynamic Programming..and i made several tests myself, my code could calculate the right answer = =...sorry for my poor English Simple tests: 1) 5 2 2 2 ????? ans:XX.XX 2) 4 2 2 2 ???? ans:Impossible 3) 15 3 2 1 2 ??X?.?.......X? ans:.?X?.X.......XX 4) 15 5 2 1 2 1 2 ??X?.?.X.?.?.X? ans:Impossible 5) 5 0 XXXXX ans:Impossible 6) 5 3 1 1 1 X.X.X ans:X.X.X 7) 5 2 1 1 .?.?. ans:.X.X. 8) 18 5 3 1 1 3 1 .???.X?.??..?XX?.? ans:.XXX.X..??..?XX?.X Make two separate arrays for x and y coordinates of cockroaches. Don't use horizontal instructions in tight loops. Perform all the develop and debug in 32-bit mode (evidently GCC/Clang on server has -m32 key). x86-64 has RIP-relative addressing, there would be bottlneck when you go back to 32-bit build and try to backport from 64-bit one. First loop for each sweet is straitforward. Don't use `displacement(base,index,scale)` addressing. Always run all over the `base` part. Finally it may give about a couple of hundred ms. In second loop for each sweet you may use BSF instruction to get least significant bit offset (remeber, judge runs on Sandy Bridge arch). Use LEA to calculate simple index arithmetic. Here is mine: size_type R = 0; asm ( "vbroadcastsd %[dmin], %%ymm5;" "dloop:" "vcmpgt_oqpd %[d](,%[i],8), %%ymm5, %%ymm6;" "vmovmskpd %%ymm6, %%eax;" "test %%eax, %%eax;" "jz rnext;" "rloop:" "bsf %%eax, %%edx;" "lea 1(%%edx,%[i]), %%edx;" "mov %%edx, %[results](,%[R],4);" "inc %[R];" "lea -1(%%eax), %%edx;" "and %%edx, %%eax;" "jnz rloop;" "rnext:" "add $4, %[i];" "cmp %[M], %[i];" "jl dloop;" : [R]"=b"(R) : [d]"m"(d), [dmin]"m"(dmin), "0"(R), [results]"m"(results), [M]"r"(M), [i]"c"(0) : "cc", "memory", "%eax", "%edx", "%ymm5", "%ymm6" ); Custom IO gives about 300+ ms. I hope M*N solutions finally will loose their ACs someday (at least until hardware will be updated to AVX512-compatible). It turns out, that there are possible two way to solve this problem (both M*N) in addition to naïve one (1400ms). 1.) Read all sites, then for each query point do find all the preliminary neighbours using float coordinates (it is almost two time faster in terms of membory bandwitdth, then if use double). This is a "float" sieve. Then for all sites passed "float" sieve perform similar "double" sieve. It get about 500ms (for me from 1.45s to 950ms). Test #16 is still hardest. Prefetch instructions in long runs gain up to 100ms. First loop (precalc of squared float distances) can be unfolded 4 times by query points (vbroadcastss from fixed memory location works fast in loop, you should not occupy dedicated ymm register for these). Second loop, where squared distances compared against least distance (+ eps of course), found in previous loop, can be unfolded 4 times (you can occupy all 32 bit of some register using bit shift (ror, rol) after vmovmskps). I think it allow to better utilize branch prediction mechanism. This approach can be beaten by simple test: cloud of sites in one corner in 10x10 square and cloud of query points in opposite aslo in 10x10 square both in general position (not matters much). Or wiser: query points placed on quarter of circle with center in one corner and radius of 20000, sites on another quarter of circle with center in the same corner and small radius or vice versa. Or even: two distant strait lines: one with query points and another with sites. 2.) You can solve the problem in single loop using just doubles with randomization. If your random numbers hit right sites, then you can probably make even fastest solution (but it is too improbably). I can't find counterexample for this randomized approach. I am very interested in Progbeat's solution details. It seems (by memory consumed) he used approach very similar to mine. It would be great if we'll exchange our solutions somehow =). 17 1 2 3 4 5 6 7 2 8 9 5 10 8 9 11 3 9 1 2 8 9 1 2 3 9 ?????????????????????????????????????? I suspect rounding errors or something I have WA#9 too. The program seems to be right. Who can help me? I think, that your calculations not so are exact, as that is demanded with a problem. Try to not use intermediate values (for example radius etc.). you have all tests on timustests.4t.com Thank you very much. You were right about my bug. I have just change in my C++ code ceil(x) to ceil(x-eps) and floor(x) to floor(x+eps) and got AC!
Hey, UNKNOWN_LAMER! Do I know you from somewhere? je Edited by author 11.02.2018 04:58 [code deleted] Edited by moderator 19.11.2019 23:40 Hi, Very good solution! Just one note, it doesn't affect AC, but: In D+=(i+N/i); if (i == N/i) you don't need to add both i and N/i, but just i. In this case result of check(N) will be 100% equal to triviality(N) in all cases. Please, check test #26, it seems to be incorrect. Oh no, that test is correct! I got AC. |
|