Hack for your M solution.

Problem B — Beautiful Mountains can be solved in a much easier way (in my opinion).

Preprocess for each index i, the largest index j so that (i, j) is non-decreasing. Do the same in reverse (so we get the data for the non-increasing indices). Each direction can be done in O(n) if you keep track of indices (of missing values, and biggest previous value, etc).

Using this precomputed data it's possible to compute in O(1) if a subarray is a mountain. Let $$$A[from:to]$$$ be a slice/subarray (indices are inclusive), then it's a valid mountain if $$$asc[from] >= desc[to]$$$.

Then we can try all possible mountain chains. Starting from $$$size = 3$$$, try all mountains and increase the subarray starting index with a step of $$$size$$$.

What's the complexity of doing this? The first chain does $$$\frac{N}{3}$$$ iterations, for the next size it does $$$\frac{N}{4}$$$, and so on, until the last size which does $$$\frac{N}{N}$$$ iterations. In total $$$T(N) = \frac{N}{3} + \frac{N}{4} + ... + \frac{N}{N}$$$, which can be written as $$$T(N) = N (\frac{1}{3} + \frac{1}{4} + ... + \frac{1}{N})$$$. The value inside the parentheses is the harmonic number (without the first two terms though), which is known to be around $$$ln(N) + C$$$ (C is some constant, but it doesn't really matter). So $$$T(N) \in \mathcal{O}(N log N)$$$.

Also your code has wrong answer for these cases (size N is the first integer in each line):

4 -1 -1 86 100

6 53 80 -1 99 9 34

Both should be "NO". I also got AC with some lousy programs by the way. Data seems weak.