Expand Cut Tags

No cut tags
mns2012: (Default)
[personal profile] mns2012
Я забил в гпт вопрос.

Вот у меня есть такой-то O(n^2) алгоритм, который стартует со списка кусков линий (в общем случае пространственных), и проверяет: если пара концов каких-либо двух линий из списка ближе, чем ε друг к другу, их нужно слить в один кусок и начать просмотр заново.

Такой, наивный алгоритм. При увеличении размера списка время работы довольно быстро растет поскольку n^2, что неприятно. Спрашиваю: что можно сделать для увеличения быстродействия?

И он пошел мне про какие-то KD-деревья.

А я спросил: а можно ведь разбить изначальный массив на маленькие кусочки и пустить несколько параллельных threads? Потом дождавшись, когда все они выполнятся, в последний раз с результатами из этих веток ещё раз просмотреть на предмет слияния?

Да, говорит. Можно. В данном случае, мне это пойдёт, потому что нет времени на все эти изыски с nearest neighbors. И что?

Нужно этому гпт всё подсказывать. Да ещё и проверять по сто раз, что он такое насоветовал. Но всё равно удобно. Net effect: сильно сокращается время разработки.

Profile

mns2012: (Default)
mns2012

January 2026

S M T W T F S
    1 23
45678910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Page generated Jan. 15th, 2026 11:04 am
Powered by Dreamwidth Studios