Mercury13

Задача сложна и требует серьёзного исследования. Дело тут в том, что второй эшелон — склад промежуточного хранения — добавляют, если затраты НЕлинейны и в больших объёмах развоз товара дешевле. Это, конечно, можно сымитировать более дешёвым завозом на склады. (А также чтобы разгрузить «мёртвые запасы» магазинов и законом больших чисел скомпенсировать случайные колебания спроса, но это, как я понял, не ваше дело.)

У вас написано: «Стоимость доставки это расстояния между точками». Таким образом, стоимость доставки не зависит от объёма подвоза, а зависит только от расстояния? Тоже, так сказать, нелинейное поведение. Приближённое решение ищите в алгоритмах кластеризации: зона, охватываемая одним складом — и есть кластер. Если же нужно точнее, приходится использовать какие-нибудь эвристики.

Например, расположим семь складов в каких-нибудь городах, вычислим вытекающую стоимость. А теперь вопрос: можно ли перенести какой-нибудь склад в соседний город, чтобы было дешевле? Итерационно работаем, пока не уляжемся в «оптимальное положение». Случайно набрасываем семь точек — и «скатываемся вниз», пока не успокоимся, и так много-много раз.

Лучше выводить не одно решение, а несколько — например, до 120% от оптимального. Дело в том, что после компьютерного вычисления возникнут какие-то человеческие факторы: узнав, что восточный склад только в Комсомольске-на-Амуре, а северо-западный можно ставить где угодно в окрестностях Ленинграда, принимаем решение ставить склады в Комсомольске и недалеко от ленинградского метро.

В первом приближении (деформации малы, балка лёгкая) — половина параболы.
Если точно — решить можно только численно.

Очередь, физически не перемещающая элементы (кольцевая или некое подобие std::deque) и позволяющая по указателю быстро определить позицию.

Плюс любой индекс (хэш- или деревянный), элементы которого — указатели на элементы очереди. Если элементы очереди unique_ptr, то указатели будут именно на unique_ptr! Для «мусорных» языков (C#, Java) вместо указателей можно придумать какие-то идентификационные коды — например, сочетание из номера в пуле массивов и номера в массиве.

Enqueue — вписываем элемент в индекс. Dequeue — удаляем из индекса. Обмен позициями — корректируем эти два элемента индекса.

1. ВЕРНО. A \cap C \in A \in B \in B \cup D (прости уж, что пишу тэгами TeX).
3. ВЕРНО, следует из законов логики.
5. UPD. Всё-таки ВЕРНО, тут надо действовать через x. Пусть $x \in A \cap C$, тогда $x \in A$ и $x \in C$. А значит, $x \in B$ и $x \in D$. Дальше понятно? Точно так же можно решить и 3.

Как я понял, вам нужен угол вектора (x1,y1)→(x2,y2).
Любой школьный «арк», если им действовать в лоб, в определённом диапазоне углов не определён или неустойчив.
Но именно для этого в большинстве языков присутствует функция
atan2(y2 - y1, x2 - x1)

Задача, как ни странно, нетривиальна.
Какой возможен процент, чтобы округление дало 6,21? От 6,205 до 6,215%.
Минимальное число — 10319 * 6,205 / 100 = 640,29
Максимальное — 10319 * 6,215 / 100 = 641,32
Ответ однозначен, 641 человек.

Будь округление более грубым — например, 6,2% — тогда было бы от 635 до 644.

Твоё дело — перебор с кэшированием.
Для каждой кнопки вручную закидываем в массив конских «соседей» — ни одного для 5-ки, три для 4 и 6, два для остальных.
Затем заведи массив 10×7 (стартовая кнопка×длина) и устрой рекурсию с одним небольшим добавлением: если оно закэшировано, брать из кэша. Правила — f(b, 1) = 1, для остальных — sum{c=сосед(b)} f(c, i−1).
Можно и динамическим программированием, без рекурсии — всё равно расход вычислительной мощи незначительный. Сначала f(b, 2), затем f(b, 3), и т.д. до 7.

Инверсия — это когда a < b, но стоят они наоборот.
В пределах блока (например, 1…3n−2) инверсий, разумеется, нет.

Между первым и вторым блоком.
• С 2-кой: 4, 7,… То есть n−1 шт.
• С 5-кой: начиная с 7 — то есть n−2 шт.
• Итого 0 + 1 + 2 +…+ (n−1) = n(n−1)/2 шт.

Между первым и третьим, и между вторым и третьим сам инверсии посчитаешь? И чётное оно или нет — тоже, надеюсь, посчитать несложно.

x делится на 3: 9z² − 2 = 3y. Справа делится на 3, слева нет.
Иначе: (x−1)(x+1) = 3y + 1. Хотя бы один из множителей кратен трём. Всё наоборот: слева делится на 3, справа нет.
Дальше уже, по-моему, доказательство не упростить.

Да более чем! Главная проблема — интегралы. Один средней сложности точно будет.

Двудольный граф можно представить как соответствие R ⊆ A×B. Тогда проекция двудольного графа на долю A (или B) — это те вершины из A (или из B), из которых идёт ребро.

Если x > 0, то 90° − arctg 1/x.
Если <0, думай сам, школьная математика.

Для синуса — делишь на 2pi, берёшь целое-«пол», отнимаешь 2pi·n, и в зависимости от того, в каком диапазоне то, что осталось, работаешь.