Ракетнопромежуточное
Рассмотреть варианты решений по задачке опять не успеваю, простите. Будет позже, как и продолжение про баллистику, как и метро (может быть). Запар.

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

Вот типичные проблемы:

1. Чтение ТЗ по диагонали. Из десятка человек, решивших поучаствовать, целиком задачу не прочитал, похоже, никто. Без комментариев.

2. Домысливание ТЗ (ТЗ: "взять число" - Кодер: "скорее всего, тут подойдет INT", "цель движется" - "это, наверное, танк"). Особенно пикантно в сочетании с п. 1: часть требований не прочитана, а потом восполнена "из головы". В результате кто-то вместо ПТУР пытается конструировать баллистическую ракету, кто-то зенитную, 80% игроков пытается решать задачи стабилизации и т.п.

3. "Дайте мне данные, и я переверну мир". Кодеры почему-то редко задумываются над тем, откуда берутся данные, с которыми они работают. В жизни это приводит к мутанстким формам ввода, а в задачках типа моей к ответам вида "а чего тут сложного? берем отклонение по вертикали, вычитаем его из заданного направления - и все!"

4. Библиотечное мышление. Самый сложный момент, который и по жизни вызывает постоянные споры. "Зачем заново кодить то, что уже написано?". В общем-то, правильная мысль. Но многократно наблюдал, как вместо написания программки из двух строк программер мучительно ищет библиотеку с нужной функцией, находит примерно похожую, пишет здоровенный оверхед, чтобы заставить ее делать не примерно то, что нужно, а именно то, что нужно, потом борется с чужими багами - и получает в конце концов тяжелого уродца, который все равно делает не совсем то, что нужно, и юзеру приходится делать поправки.

А при решении задач типа нашей "ракетной" это выражается еще в одной забавной форме. "О, нужно чем-то рулить? Это решается с помощью черного ящика под названием "декапустный мандулятор", я видел такой на сорсфорже. Все данные подадим в него, а он нам выдаст команды на рули!". В сочетании с пп.1 и 3 - получается бесподобно.

5. Закапывание в несущественные детали. Решение задач, которые понятны и/или интересны вместо тех, что нужно решать. Превосходно сочетается с пп. 1 и 2. Кодер может часами и днями писать модуль, который проигрывает туш по завершении заполнения формы - а бизнес-логику формы будет писать за час до дедлайна, когда поседевший менеджер на него наорет, доведя обоих до нервного срыва.