Итак, поворот вокруг OY на 180 гр. У нас a=c=0, b=pi.
dy1=dy; dz1=dz;
dx1=-dx; dz2=-dz;
dx2=-dx; dy2=dy;
Вектор (dx2,dy2,dz2) равен (-dx,dy,-dz), что и следовало ожидать.
Подозрительно другое. Если у вас ориентация камеры хранится в виде углов a,b,c, то как вы её пересчитываете при очередном повороте камеры, который, как я понимаю, выполняется в локальных координатах?
Простейший пример: допустим, вы повернули камеру вокруг оси OX на 90 гр. Теперь выполняете поворот вокруг локальной оси OY (тоже на 90 гр). В глобальной системе координат эта ось будет уже называться OZ, то есть у вас будет a=pi/2, b=0, c=pi/2. При поворотах в другом порядке (сначала вокруг OZ, потом вокруг OX) всё будет ещё сложнее.
Вы это учитываете? Если да, то как?
Аналогией в классической математике мог бы быть вопрос "существуют ли неизмеримые множества". Пока мы не разберёмся с аксиомой выбора, мы ответить не сможем. Вот после того, как мы решили эту аксиому принять, ответ стал определённо "да".
Насколько я понимаю, в арифметике подобной ситуации возникнуть не может. Но если поменять логику, пойти в сторону какого-нибудь конструктивизма (а при необходимости, и дальше), то не удивлюсь, что значение числа пи будет зависеть пусть не от времени, но от наших знаний о нём.
Армянское Радио: Если мы будем поворачивать почти прямую линию вокруг начала координат, то коэффициент корреляции будет меняться от почти единицы (когда линия идёт в направлении (1,1)) до нуля (когда оси координат направлены вдоль осей эллипса инерции) и обратно. Так что при любом пороге она будет оказываться то прямой, то не прямой. Хотя форма меняться не будет.
Так что вам нужно - отличить прямую от ломаной (которая может быть просто шумной прямой), или прямую от дуги? У того, что изображено справа на рисунке, кривизна тоже очень близка к нулю, прямая аппроксимирует эти точки лучше, чем окружность.
AigizK: Не так. Если есть хотя бы одна единица, то надо вообще ни о чём не думать. Ваш вариант сломается на примере "10,5,1, надо получить 11". Он увидит нечётное число и попытается взять пятёрку, что будет ошибкой.
AigizK: Что-то не так. Если считать по моему алгоритму: 1007-5=1002. Следующим шагом, по жадному алгоритму, мы берём 1000. Остаётся 2, и всё решено. Брать 5*2, когда можно брать 1000, алгоритм не рекомендует. Когда мы "объединяем пятачки в пары", то они остаются в кошельке, пока до них не дойдёт очередь.
Вопрос к условию: слово "ровно" в формулировке вопроса не случайно? То есть, требуется ли, чтобы стороны квадратов были параллельны сторонам прямоугольника? В списке требований этого условия нет.
Потому что если квадраты могут располагаться под углом, то приведённые ниже решения неоптимальны. Например, для прямоугольника 120*120 и 5 квадратов они дадут ответ 40, хотя, повернув квадраты на 45 градусов, мы можем увеличить их размер до 42.42 пикселя.
"если нужно запрограммировать как спутник летит - то почитаете книжки по численным методам благо их нынче вагон - с точки зрения программирования - там все гиперпросто."
Вы серьёзно? Спутник летит в несферическом гравитационном поле (Земля - не идеальный шар). На него действует Луна, которая тоже не очень круглая. Скорости достаточно высоки, чтобы начали действовать релятивистские эффекты. В программе всё это придётся задавать и учитывать. Как вы зададите гравитационное поле? Сферическими функциями? Сколько гармоник надо взять, и как они меняются во времени? Или приближением на сетке? Как эту сетку задать (чтобы она уместилась в доступную память), как учитывать в расчётах? Без этих эффектов вы не сможете не то что направить спутник в окно Белого Дома, но даже посадить его на Пентагон. А если вы допустите ошибку в программировании формул - как без понимания математической модели вы будете её искать?
- отличается от старого тем, что массив заполняется с начала, а не с конца. Если учитывать, то надо очень хорошо переписать функцию output: генерировать перестановки придётся в ней. Постановка задачи "плохая" из-за того, что сначала сортировка идёт по наборам, а потом - по перестановкам этого набора. Поэтому программа будет вдвое сложнее.
Про первый порядок - понятно, он лексикографический. Например, для (4,10,1) должно получиться
1,1,1,7
1,1,2,6
1,1,3,5
1,1,4,4
1,2,2,5
1,2,3,4,
1,3,3,3
2,2,2,4
2,2,3,3
Правильно?
Но вот со вторым понять сложно. Ведь перестановки бывают не только циклическими. Уже для примера 1,1,1,1,2,94 их будет 30 штук. В каком порядке их надо вывести?
dy1=dy; dz1=dz;
dx1=-dx; dz2=-dz;
dx2=-dx; dy2=dy;
Вектор (dx2,dy2,dz2) равен (-dx,dy,-dz), что и следовало ожидать.
Подозрительно другое. Если у вас ориентация камеры хранится в виде углов a,b,c, то как вы её пересчитываете при очередном повороте камеры, который, как я понимаю, выполняется в локальных координатах?
Простейший пример: допустим, вы повернули камеру вокруг оси OX на 90 гр. Теперь выполняете поворот вокруг локальной оси OY (тоже на 90 гр). В глобальной системе координат эта ось будет уже называться OZ, то есть у вас будет a=pi/2, b=0, c=pi/2. При поворотах в другом порядке (сначала вокруг OZ, потом вокруг OX) всё будет ещё сложнее.
Вы это учитываете? Если да, то как?