-

subj

Well, as anyone can see, this task is quite solvable. And complaining about bad tests is a bad strategy in solving this task. :)

Note: task description does not contain definition of monotonicity intervals for functions defined on grids. So the first step in solving this problem is to understand, what does notion of monotonicity interval mean in the case of functions defined on grid.

Major difference in cases is that for functions defined on grids there could be situations when there is no interval of function decrease between two intervals of function increase (this situation is impossible for continuous functions). And this is a key to this problem.

Here is an example:
sequence
1 2 3 4 1 2 3 4
gives two monotonicity intervals:
(1 2 3 4) (1 2 3 4)

but is there a general commonly known theory of grid functions, which gives us such a definition? Or is this definition intuitive and natural enough? Why can't this understanding be considered possible as well:
(1234)(41)(1234), i.e. intervals should overlap at their ends, just like they do for continious functions? Moreover, nothing was said about how to treat constant intervals: 1 2 2 2 1;
 Finally, I'd like to mention that using the word "group" instead of "interval" would make the problem statement more clear, or putting the example you've shown above.
 Elseway, I can't see how we must have found the exact definition that you propose. I don't say it was impossible (many people have solved the problem), I just say the problem statement wasn't complete, to my mind.

Yes, it was intentionally made incomplete.
But not incomplete in the sence of missing some important information at all. Of course, it was possible to formulate exactly that we want the participant to split sequence of numbers into minimal amount of nonincreasing/nondecreasing subsequences. And it would become the trivial task.

So it was decided to formulate the task in the way it was formulated. It was assumed, that contestants will try strightforward approach, get WA, check solution, understand, that there is no problems with their solutions but there is a problem with their understanding of the task. Then they will be able to analyze it and find a right way to solve it.

And statistics shows that this is the way the people solved this task: almost everyone has at least one unsuccessfull submit. But a lot of people was able to look at the problem from different point of view and solve it. :)

You see, it is a common principle (even a commandment, I should say) for a problem definition to be as clear as possible. It was said a programmer's task is not to guess _what_ he should do, but to understand _how_ he should do it. You are a veteran yourself - and would you be happy failing to solve the easiest problem in a contest - only because some problem authors were up to check whether you can guess something or not?

As for this very problem I have posted some tests, so you can trick people no more, but I still have some questions to you. Is it a single instance or a new approach to problem definitions making? And if so, should we wait such stuff at the upcoming quarterfinal? Don't you afraid of being flooded with questions during the contest? :)

Yes, it is true that I am a participant of problem solving contests since 1996. And I really was faced with a problems where definition was not so clear as I would expect. And I got my 'No comments' answers from jury. And I was sure that my solution is correct while it was not. So it was not me who first invented this kind of tasks.

Concerning "commandment" mentioned. This task definition was agreed by all jury members. No objections were made. Just because this task is so obvious in the part of "how to implement", failing to solve it strightforward should make contestant to think on "what he should do".

Participants too often think about wrong tests prepared by jury BEFORE doing simple check of their own solutions. You may think that this task is a lesson for participant to be sure in tests correctness. :)

Concerning upcoming quarterfinal, I hope, there will be a couple of interesting non-standard problems. :)