Проблема в реализации проверки.Такие проблемы частенько возникают. Спасибо за разбор)

Ну если смотреть на вашу статистику по прошлым раундам, то 3 задачи это не так плохо, это раз. По чесноку я тоже успел написать build(), но когда заметил (a[i] <= a[i+1]) понял, что здесь что-то не так, представил, и увидел что делать. Собсно, о чем я — вам стоит убедиться в том, что проблема именно в соображалке) Я видел что и желтые решали деревом отрезков, это просто недостаточный реверс-инжиниринг условия) Зачем давать дерево отрезков на задачу А див1? Ну кому это в голову придет? Задача А див2 это всегда до чего-нибудь догадаться и подсчитать. В див1 обычно нужна какая-то формула и небольшая надстройка над ней в виде алгоритма простенького, или просто надо как-то особенным образом выбрать значения, которые в нее подставить. Но если вам все же интересны те способы развития креативности, о которых я знаю — надо заставлять мозг делать привычные дела непривычными способами, тогда он начнет изыскивать больше путей решения различных задач (он ведь всегда аналогии с приобретенным опытом простраивает). Я раньше этим увлекался, даже моторику левой руки развил, таблицами Шульте баловался, еще там разными вещами, не знаю уж, как мне это помогло мне) Можете и вы попробовать, но на мой взгляд для успехов в конкретной области все же лучше просто более внимательно относиться к мелочам, разбирать все что непонятно и не висеть на месте (но это скорее следствие искренней заинтересованности).

Никак. По себе знаю.

Вообще сложность алгоритма оценивается без учета коэффициентов, так что можно и до конца пробежать (поиск элемента в не сортированном массиве это ведь O(N)). Ущерб в виде некоторого кол-ва проверок, выигрыш в унификации, меньше шанс запутаться. Но если у меня будет TL68 я конечно начну решение просовывать и делать разные таки вот оптимизации) По поводу посчитать при построении — идея, думаю если бы такая возможность была, то приведенного выше кода у меня бы в решении и не появилась)