Comments 36
Однако данный способ становится достаточно громоздким при написании кода (возможно поэтому вы сейчас читаете эту статью), к тому же, он не является универсальным: если одна из прямых параллельна оси Y, мы получим ошибку деления на ноль при вычислении углового коэффициента, и нам придётся прописать код на этот случай; если две прямые параллельны, требуется повозиться с обработкой и этого случая. Такой код становится длинным и некрасивым.
Тем не менее, в вашем коде также приходится прописывать код на случай совпадающих и пересекающихся под прямым углом прямых. Где же преимущество?
А если серьезно, то «расположена».
А если серьезнонет, это не серьёзно:
если прямая, то расположена целиком? если отрезок, то расположен отрезок целиком в цилиндре или прямая, задаваемая отрезком, целиком расположена в цилиндре (здесь я имею в виду бесконечный цилиндр, а что имеет в виду автор вопроса, можно только гадать)
А это не имеет значения. Все равно основным моментом будет нахождение точек пересечения прямой с бесконечным цилиндром и двумя плоскостями (если цилиндр не бесконечный).
Единственный частный случай — проверка, пересекает ли прямая бесконечный цилиндр. Тогда точки пересечения искать не надо, достаточно посчитать расстояние между прямыми и проверить их на коллинеарность.
Получается, что вас интересует пересечение двух бесконечных цилиндров?
рассчитайте расстояние между двумя прямыми (осями цилиндров) и если сумма полугабаритов (радиусов цилиндров) обоих объектов больше этого расстояния — дело плохо (или наоборот хорошо, если столкновение — это благоприятный исход)
Вопрос я сам не очень-то мог сформулировать — что-то вроде упреждения при стрельбе по цели с известными начальными координатами и направлением движения, причем зона поражения стреляющего имеет форму конуса определенных угловых размеров.
Интереснее было бы рассмотреть задачу не на плоскости, а в пространстве
Я к тому, что искать пересечение прямых (как в заголовке) это одно, а пересечение отрезков (как в статье) это другое немного.
#include <iostream>
#include <cmath>
using namespace std;
int main()
{
double x1, y1, x2, y2, x3, y3, x4, y4;
double Ua, Ub, numerator_a, numerator_b, denominator;
cin >> x1 >> y1 >> x2 >> y2 >> x3 >> y3 >> x4 >> y4;
denominator=(y4-y3)*(x1-x2)-(x4-x3)*(y1-y2);
if (denominator == 0) {
if ( (x1*y2-x2*y1)*(x4-x3) - (x3*y4-x4*y3)*(x2-x1) == 0 && (x1*y2-x2*y1)*(y4-y3) - (x3*y4-x4*y3)*(y2-y1) == 0)
cout << "Отрезки пересекаются (совпадают)";
else
cout << "Отрезки не пересекаются (параллельны)";
}
else{
numerator_a=(x4-x2)*(y4-y3)-(x4-x3)*(y4-y2);
numerator_b=(x1-x2)*(y4-y2)-(x4-x2)*(y1-y2);
Ua=numerator_a/denominator;
Ub=numerator_b/denominator;
cout << (Ua >=0 && Ua <=1 && Ub >=0 && Ub <=1 ? "Отрезки пересекаются" : "Отрезки не пересекаются");
}
return 0;
}Pc = P(x1, y1) + P(x2, y2) * Ua;
Pc = P(x3, y3) + P(x4, y4) * Ub;
Причем можно метод расширить до плоскостей и точек в трехмерном пространстве, только плоскость будет образовываться тремя точками, а точка тремя плоскостями
, читайте 3 главуИ, по моему, в каких-то эхоконференциях регулярно ходил Faq на эту тему, возможно Ru.Graphics, но я нашёл только demo design 3d faq там нет пересечения линий, а чисто 3D
Однако данный способ [...] не является универсальным: если одна из прямых параллельна оси Y, мы получим ошибку деления на ноль при вычислении углового коэффициента, и нам придётся прописать код на этот случай
В курсе аналитической геометрии, помню, было полдесятка различных уравнений прямых на плоскости, нужно выбрать более подходящий для задачи вид уравнения и проблема углового коэффициента уйдёт.
Я когда-то задавал эту задачку студентам-первокурсникам на лабах по C++. Ожидал увидеть какое-то такое решение:
— составить два общих уравнения прямой (в форме Аx + Bx + С = 0);
— подстановкой точек в левые части уравнений убедиться, что концы отрезков лежат по разные стороны от этих прямых;
— решить систему методом Крамера.
Ситуацию, когда на третьем этапе матрица всё равно оказывалась вырожденной, несмотря на сделанные проверки, можно было не рассматривать. К сожалению, и без этого задача оказалось слишком сложной для студентов.
Верно, проблема с устойчивостью — это огромная проблема при решении СЛАУ. А минимизация квадратичного отклонения — один из способов регуляризации.
Вот только в данном случае это совершенно не актуально. Предыдущий комментарий был о том, что тупые студенты были даже не в состоянии составить систему. Вы же пишете о том, что систему надо решать правильно. Но в данном случае это оверинжиниринг. Метода Крамера или Гаусса для решения системы из 2 уравнений более, чем достаточно.
Какой там нафиг ряд может расходиться, когда оба метода используют лишь 4 базовые арифметические операции?
Вот что правда может "разойтись" — так это потеря точности на вычитании близких чисел, усугубляемая последующим делением на это число. Но это лишь означает, что искать точку пересечения почти-параллельных прямых — плохая идея.
del
Нахождение точки пересечения двух прямых (и отрезков)