QOJ.ac
QOJ
ID | 题目 | 提交者 | 结果 | 用时 | 内存 | 语言 | 文件大小 | 提交时间 | 测评时间 |
---|---|---|---|---|---|---|---|---|---|
#335959 | #8281. Pangu and Stones | ucup-team3099# | WA | 3ms | 7760kb | C++14 | 3.2kb | 2024-02-24 10:25:57 | 2024-02-24 10:25:57 |
Judging History
answer
#include <iostream>
#include <vector>
#include <chrono>
#include <random>
#include <cassert>
#include <algorithm>
#include <cstring>
std::mt19937 rng((int) std::chrono::steady_clock::now().time_since_epoch().count());
int dp[102][101][101];
int a[101];
int main() {
std::ios_base::sync_with_stdio(false); std::cin.tie(NULL);
int n, L, R;
std::cin >> n >> L >> R;
for(int i = 0; i < n; i++) {
std::cin >> a[i];
}
memset(dp, 0x3f, sizeof dp);
for(int l = n; l >= 0; l--) {
for(int r = l; r <= n; r++) {
for(int i = R; i >= 0; i--) {
if(l == r) {
dp[i][l][r] = L <= i && i <= R ? 0 : 0x3f3f3f3f;
} else if(i < R && l != r) for(int m = l+1, s = a[l]; m <= r; s += a[m++]) {
dp[i][l][r] = std::min(dp[i][l][r], dp[i+1][m][r] + s + (m - l == 1 ? 0 : dp[0][l][m]));
}
//std::cout << "(" << i << ", " << l << ", " << r << ") = " << dp[i][l][r] << '\n';
}
}
}
int ans = dp[0][0][n];
if(ans >= 0x3f3f3f3f) {
ans = 0;
}
std::cout << ans << '\n';
}
/*
NEVER FORGET TO:
Look at the problem's constraints before coding.
How to cheese cf:
Find a lower bound or upper bound for the problem. Have faith that it is the answer of the problem.
If it isn't the answer, have more faith or change to another bound god by looking for a better bound.
Trust guesses. Who has time to think? If people in div2 AC the problem it requires no proof since people don't prove things.
You must draw cases. Thinking gets you nowhere, so draw cases and reach illogical conclusions from them.
Sometimes drawing cases is bad because it takes too much time. Faster is to not think at all and just code a bruteforce solution.
This is called "law of small numbers". If something works for small numbers, surely it works for big numbers.
https://en.wikipedia.org/wiki/Faulty_generalization#Hasty_generalization don't mind the "faulty" part of it, in competitive programming mistakes are lightly punished
Don't think about them being right or not, cf is a battle of intuition only.
Be as stupid as possible in implementation. Trying to be smart is an easy way to get WA.
Think about 2x2 cases for matrix problems and hope that everything works for the general case.
Find a necessary condition and trust it to be sufficient. They're basically the same thing.
Heuristics might speed up your code. Forget about complexity, it's only about ACing and not proving that your solution is good.
For paths in a grid starting at (1, i) or something like that, assume that they never cross and do D&C
Consider doing problems in reverse order of queries/updates
For combinatorics problems, consider symmetry
General strategy (MUST DO):
Try to solve the problem with more restricted constraints.
About testing:
Test n=1, a[i]=1, a[i]=n, etc. Basically, test low values. No need to test if pretests are strong, but if you get WA it's good.
This isn't a joke. Do it if you get stuck. It's shit practice in my opinion, but do it if you want AC.
*/
詳細信息
Test #1:
score: 100
Accepted
time: 2ms
memory: 7640kb
input:
3 2 2 1 2 3
output:
9
result:
ok 1 number(s): "9"
Test #2:
score: 0
Accepted
time: 2ms
memory: 7760kb
input:
3 2 3 1 2 3
output:
6
result:
ok 1 number(s): "6"
Test #3:
score: 0
Accepted
time: 2ms
memory: 7612kb
input:
4 3 3 1 2 3 4
output:
0
result:
ok 1 number(s): "0"
Test #4:
score: -100
Wrong Answer
time: 3ms
memory: 7676kb
input:
100 4 7 570 608 194 26 243 470 418 119 1000 936 440 302 797 155 676 283 869 60 959 793 158 397 808 656 379 316 485 854 753 280 543 435 756 822 106 561 402 347 99 739 8 682 834 549 812 32 338 765 699 575 575 785 171 504 335 113 284 612 276 518 835 677 865 900 687 48 859 179 343 318 626 812 523 11 400...
output:
124078
result:
wrong answer 1st numbers differ - expected: '120446', found: '124078'