OIC~ thanks for solve my confusion~

tnx for helping :)

I agree with you

Good luck and Have fun~!

Ah, this wasn't my mistake. I wasn't properly computing my new dp values. I fixed it now — 6396342 :D

I missed this trick , Learned a nice trick (i am almost a newbie :p)

would be able to fill a rectangular table N × M with squares of different positive integers in such a way,

Ой, я хотел сказать, элементы с пересекающимися масками.

I've solved over 100 problems using cout, but solutions work with such restrictions. And endl also hadn't create problems.

I used ios_base::sync_with_stdio(0) and still got TLE : http://mirror.codeforces.com/contest/418/submission/6387665

998 ms!!! also using '\n' in place of endl halves time because flushing happens only once.

I'm not sure which solution of mine accidentally became Java, but I was unaware that I still use this language for Codeforces. Thank you for correcting me. I will be sure to take Java's disadvantages into account when coding in C++.

The issue with this problem stems not from the fact that a slow solution is not passing. The issue is that, despite the fact that the contestant is really solving the problem, different methods of printing result in wildly different verdicts. Besides the precedent of specifying not to use cin when this is a possibility, this is just a terrible problem from an algorithmic standpoint. What is the purpose of a problem that is all about choosing the correct printing method? Perhaps it's good as a homework problem, but it has no place whatsoever in a contest. Especially since some languages just can't do it (and Java is not exactly an obscure language...) under typical circumstances.

Anyway, there is a profound difference between industry coding and recreational coding. Pick any nontrivial problem, and pick a random solution. Is this code you want to see in production? Of course not. With some exceptions, the formatting will likely be difficult, there is likely to be silly hacks to get around issues rather than writing clean code (as there should be with time constraints), but most importantly you probably need to take a long time to figure out what the code is doing. When was the last time you saw a solution with proper documentation, abundance of comments, and written for readability, accessibility, and evolvability? So the objection "this code wouldn't be good in industry" is a stupid one — no contest code would be good in industry (if it is, you're probably not doing contests right!).

I'm not sure whether you work in the coding industry, but when was the last time you considered runtime as a serious factor? Besides not doing something insanely stupid like making a code O(N^8), there just isn't a great need to. Sure, several algorithms are useful, but implementing complicated things to avoid a logarithmic factor is silly. And anyway, code should not be elegant or clever — it should be readable and understandable. If you see

// to convert prefix to postfix
main() {
  char c = getchar();
  (c == '+' || c == '-' || c == '*' || c == '/') ? main(), main() : 0;
  putchar(c);
}

in somebody's code, even though this is some pretty damn cool code that person should be out of a job quickly. It's not worth the headache that someone else is going to have when trying to edit this code a few years down the road.

I suppose we'll agree to disagree, but I think a good contest problem is one that provokes thought, has a nice solution, and gives that "aha!" moment when you solve it (perhaps because of my math background where an inelegant problem is considered a huge disappointment, not a good exercise). This particular problem satisfies exactly 0 of these criteria. Ok, maybe you have to think a moment to realize you can just connect a vertex to the k nearest clockwise ones, and maybe another moment to prove it if you're so inclined. But there's nothing interesting about the problem, and it's not one of those problems that you recognize a week later as "oh, I remember that problem! That was a nice one" (assuming you remember it at all, which this problem doesn't give much reason too). It's just not a good contest problem. A good homework exercise in the speed differences between output, but not a good contest problem.

Блин, div.1 звери. Как-то совсем много народу порешало...

P.S. A упала из-за кривой проверки на -1, B упала из-за отсутствия сорта. Победитель по жизни я, лол.

Почему сортим в возрастающем порядке по мониторам? Мне кажется наоборот, чтобы избежать ситуации, когда мы не взяли чувака с большими требованиями по мониторам и маленькой ценой, а потом нам пришлось взять мониторов больше...

Кстати, первое измерение в таком дп не нужно, всё можно обновлять в одном массиве (потому что два раза одного и того же чела не выгодно брать, и такое обновление не произойдёт).

Я тестил в запуске — если вообще все переменные long long и делать в vector, то не пройдёт. Если long long только те, что нужны и делать на массивах — вроде, едва, но влезает...

смотря на каком компиляторе)

Действительно :)

998 мс XD

cout<<endl;

and

cout<<"\n";

perform differently.

In particular, the former flushes which is why it is slower.

cout << endl; flushes every time.

Or to use cin.tie(0);, I believe.

On 1000 499 your program took 966 ms. Not surprising that another similar case would take over a second, it's just random variance.