Kd-Tree. Быстрый поиск в K-мерном пространстве

Rd-Tree

Если есть гигантский массив данных, то неизбежно встаёт вопрос о быстром поиске данных в нём. Очевидно, что надо строить дерево поиска. Существует множество разновидностей подобных деревьев. Для K-мерных величин, например, 2D или 3D координат, неплохим решением является Kd-Tree.

Волею судеб, возникла необходимость разобраться в этом вопросе. Я бы с удовольствием взял уже готовую Delphi-реализацию, но таковой и толковой на просторах инета не оказалось.

Какие задачи хотел решить:

  • Размер обрабатываемых массивов должен исчисляться миллионами точек.
  • Построение дерева за минимально короткое время. На миллион точек должно уходить меньше секунды.
  • Время поиска ближайшей точки должно составлять около 0.5 мсек.

Рассуждения

Понятно, что узлы дерева должны направлять поиск точки и однозначно приводить к результату. Таким образом, узел должен содержать информацию о своих дочерних узлах. В этом случае он называется ветвью. Либо, если дочерних узлов нет, такой узел называется листом и содержит конечный набор K-мерных величин.

В листе дерева содержится информация о точках. Массив данных у меня уже есть. Поэтому в листьях дерева должны содержаться индексы массива.

В ветвях дерева должна содержаться дополнительная информация, которая позволит мне принять верное решение, что это мой узел и мне с ним работать дальше.

В общем случае, рекурсия поиска должна выглядеть так:

Спрашиваю узел: Дескать, у меня есть такие координаты, это к тебе?

Он: Не, не моё. Спроси соседа.

Сосед: О, это моё. Заходи.

Захожу в этот узел, а там ещё узлы. И так до тех пор, пока узлов не окажется вовсе, а окажутся индексы, из которых я выберу наиболее подходящий.

Построение Kd-tree в теории

Kd означает, что дерево построено в k-мерном (k-dimensional) информационном пространстве. Проще говоря, трехмерным кубом рассматриваемое пространство значений не ограничивается. Теоретически, это может быть масса-температура-материал-состояние. Валюта-номинал-время. X-Y-R-G-B для изображений (любопытно было бы поэкспериментировать). Зачем нужен в перечисленных измерениях Kd-tree, это уже второй вопрос.

Чтобы не делать вечер слишком томным, остановимся на двумерном пространстве X-Y.

В двух словах

Итак, у нас есть один объемлющий прямоугольник всех точек в массиве (Xmin,Ymin) — (Xmax,Ymax), у которого ширина равна W = Xmax-Xmin, и высота H = Yмax-Ymin. Это однозначно корневой узел.

Выбираем некоторое значение в пределах W в качестве разделителя по X.

Рис.1. Корневой узел. Объемлющий прямоугольник для всех точек массива

После этого добавляем в корневой узел ветвь для точек, которые находятся слева от разделителя Sx , т.е. содержатся в прямоугольнике (Xmin,Ymin) — (Xmin+Sх,Ymax). Назовём такой узел левым. И ветвь для точек, находящихся справа от Sx, в прямоугольнике (Xmin+Sх,Ymin) — (Xmax,Ymax). Это правый узел.

Рис.2. Левый и правый узлы по измерению X. Глубина 1

Затем для каждого получившегося узла выбираем делитель по Y, делим, и добавляем в каждый по два узла. Если для предыдущего левого узла выбрать делитель Sy, то в него добавилось бы ещё два узла, чьи прямоугольники выглядели бы так: (Xmin,Ymin) — (Xmin+Sx,Ymin+Sy) и (Xmin,Ymin+Sy) — (Xmin+Sx,Ymax).

Рис.3. Левый и правый узлы по измерению Y. Глубина 2

Затем снова выбираем измерение X, делим, добавляем левый-правый узлы. И так далее до тех пор, пока число точек в очередном получившемся прямоугольнике не стало меньше заранее заданного количества. На этом мы останавливаемся и сохраняем в узел-лист индексы всех попавших в него точек.

Возникают вопросы:

  • Как выбрать текущее измерение;
  • Как выбрать делитель в текущем измерении.

Выбор текущего измерения

В самом простом случае последовательно перебираем измерения: X,Y,Z,…X,Y,Z, и т.д. Если количество измерений у нас DimCount, а текущая глубина дерева ADepth, то текущее измерение D вычисляется так:

Однако, тут может возникнуть ситуация, когда в текущем измерении значения всех точек одинаковы. Например, начинаем с измерения X, а все точки в нашем многомиллионном массиве выстроены по вертикальной линии, т.е. различаются только координатой Y. Тогда все точки попадут в один узел-лист и никакого упорядочивания массива не будет. Быстрый поиск ближайшей точки станет медленней полного перебора.

Очевидно, что для выбора текущего измерения надо найти такое измерение, где разница между текущими граничными значениями максимальна.

Вернёмся снова к двумерному пространству X-Y. На момент деления левого узла (рис.2) текущими граничными значениями были (Xmin,Ymin) — (Xmin+Sх,Ymax). Чтобы выбрать измерение для деления мы должны найти разницы dX = Xmin+Sх-Xmin и dY = Ymax-Ymin, затем сравнить dX и dY и если dX>dY, то за текущее берём измерение X, в противном случае — Y.

В случае, когда измерений у нас произвольное количество DimCount, текущие минимальные и максимальные граничные значения можно задать массивами AMin(DimCount) и AMax(DimCount). Тогда выбор текущего измерения D можно представить так:

Тут мы предполагаем (на 100% уверены), что значения в AMax не могут быть меньше, чем в AMin, и что количество измерений DimCount однозначно больше нуля.

Выбрать делитель в текущем измерении

Проблема выбора делителя связана с тем, что «прямоугольники» (если мы говорим про X-Y) после деления не должны быть пустыми и точки внутри них должны быть распределены более-менее равномерно.

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

Итак, у нас есть массив AIndices: TIntegerDynArray, это массив индексов в массиве К-мерных данных. Есть текущее измерение D, которые мы нашли пунктом выше. Представим К-мерную точку таким типом:

Естественно, мы никогда не будем объявлять переменную типа TKdPoint. Безумное расточительство. Работаем всегда с указателем PKdPoint. Почему не динамический массив? Потому что я сам хочу выделять память и контролировать её освобождение. Мне не нужно интересоваться длиной массива, она у меня и так есть — DimCount.

Выбор делителя S в таком случае можно представить так:

FPoints — это массив K-мерных точек, который передан извне, который мы не меняем и работаем только с его индексами.

i1 — это текущий начальный индекс очередного фрагмента массива индексов

Len — длина этого фрагмента.

Откуда берётся i1 и Len? Это станет ясно чуть ниже.

Архитектура и построение Kd-tree

Узел Kd-tree

В теории предлагается завести две отдельные структуры под ветвь и лист. Я попытался всё уместить в одну структуру — узел Kd-tree.

Хм… А где же в узле массивы, задающие границы попавших внутрь точек? Что-то типа, FMin(DimCount), FMax(DimCount)? А не нужны. Алгоритм таков, что всё обязано считаться на лету, на основании поля FSplit. И как бы стрёмно это не звучало, это лучше, чем хранить лишнее.

Заголовок класса Kd-Tree

Помещу в спойлер, чтобы текст статьи не разрастался сильно уж

Класс TKdTree

[свернуть]

Построение Kd-Tree

В классе дерева есть поля FRoot и FPoints, которые никак не выходят наружу:

Всё дерево нам доступно из корневого узла FRoot, по сути именно его мы и создаём при построении Kd-Tree. FPoints — это список K-мерных точек, который будем передавать в параметре APoints: TList. Мы его просто запомним и будем к нему обращаться, когда потребуется узнать какое-то значение какого-то измерения в каком-то индексе .

Перед тем, как вызывать рекурсию построения, необходимо выполнить некоторые подготовительные действия.

Необходимо сформировать массив индексов. Как ранее договорились, мы будем структурировать индексы, не трогая сами данные.

Необходимо определить K-мерные границы массива данных. В терминологии X-Y это переводится, как найти объемлющий прямоугольник.

И запустить рекурсивное построение.

В листинге ниже используется некий параметр AModern — это флаг того, что при рекурсивном построении будет использован «не-классический» метод, о котором речь пойдёт тут.

Рекурсивное построение: Классика

Говоря об алгоритме построения Kd-Tree можно смело утверждать, что это алгоритм упорядочивания и структурирования индексов. Вначале мы сортируем весь диапазон индексов, потом определяем некий участок от i1 до i2, далее снова рекурсия, происходит сортировка по новому текущему измерению внутри этого диапазона, потом этот фрагмент снова делится и так далее.

В числе параметров рекурсии присутствуют значения для текущих границ диапазона значений AMin, AMax: TSingleDynArray. Динамический массив — это указатель, поэтому изменяя значение в массиве и рекурсивно вызывая дальнейшее построение, следует вернуть старое значение, которое было до изменения.

Как видим, для построения Kd-Tree не требуется запоминать текущие границы областей, они динамически меняются из рекурсии в рекурсию и специально их где-то хранить нет нужды.

Всё работает просто отлично. Но скорость построения ужасная. На миллионе точек у меня получилось порядка 13 секунд.

Разбираемся и понимаем, что львиная часть времени тратится на сортировку:

Здесь использован алгоритм быстрой сортировки. Но какой бы сортировка не была быстрой, нас она не устраивает. Поэтому, придумываем что-то другое, мимо сортировки и медианного значения.

Рекурсивное построение: Модерн

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

Сразу скажу, это работает. Но как всегда есть нюансы. Можем получить значение разделителя такое, что ни одна точка не попадёт в получившуюся после деления область. Как всегда в таких случаях бывает, код в этом месте сильно разрастается. Там где у нас ранее была лаконичная, красивая и медленная сортировка, вырос куст условий.

Алгоритм тот же самый, но вместо блока «Нахождение медианы массива», в котором жила маленькая сортировка, теперь там достаточно приличный кусок кода. Регионом оформлять внутри процедуры не стал, посчитал некрасивым. Я постарался максимально откомментировать изменившийся участок.

И да, теперь выбор измерения происходит как тут сказано.

Теперь построение миллиона точек у меня занимает чуть больше 600 мсек. Победа!

Поиск ближайшей точки в Kd-Tree

Вот добрались до самого важного. Ради чего, собственно всё и затевалось.

Общий алгоритм поиска

Нужно рекурсивно пройти все ветви от корневого узла до листа, всякий раз определяя поддерево для спуска — левое или правое.

Поддерево определяется по разделителю в измерении, который хранится в узле. Это поле FSplit в структуре узла. Если значение точки в измерении FAxis, которое также хранится в узле, меньше разделителя, то уходим в левое поддерево, иначе — в правое. Есть нюанс в выборе поддеревьев, он решён ниже, ссылки даю исключительно для нетерпеливых ))) Но лучше читать всё последовательно.

Так продолжается до тех пор, пока мы не натыкаемся на лист. Который можно определить по полю длины массива индексов FLength, которое должно быть в этом случае больше нуля.

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

Радиус определяем, как декартово расстояние, то есть сумму квадратов разностей по каждому измерению. Квадратный корень не извлекаем. Экономим время операции.

Поиск минимального радиуса до ближайшей точки

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

В данном случае APoints: TList — это массив с К-мерными точками. APoint: PKdPoint — K-мерная точка, для которой ищем ближайшую. ADimCount: Integer — число измерений. ANode: PKdNode — текущий рассматриваемый узел.

Возвращает минимальный найденный радиус ARadius: Single и индекс ближайшей точки AIndex: Integer.

В методе класса вызов будет такой:

И что у нас получилось.

Рис.4. Поиск ближайшей точки. Быстрый, но неправильный.

Видим, что найден такой радиус, что в него попадают точки, намного ближе расположенные к исходной. Да и ближайшая точка, выделенная желтым цветом, явно не ближайшая.

Очевидно, что помимо «своего» поддерева, надо искать и в соседнем. То есть, надо определять может ли теоретически искомая точка быть в левом/правом поддереве. Предположим, сама точка больше делителя, и по идее, надо искать в правом поддереве. Но точка минус радиус меньше делителя. То есть, теоретически, она может находится и в левом тоже.

Поиск ближайшей точки с коррекцией радиуса

Скопипастим процедуру нахождения минимального радиуса, назовём по другому и модифицируем тело.

Здесь определяется возможность захода в одно из поддеревьев, либо сразу в оба, учитывая текущий радиус. В классических описаниях есть слова о более приоритетном поддереве, и менее. И вначале поиск идёт в более приоритетном. Но, честно говоря, смысла в этом особого не увидел.

Когда мы добираемся до листа, происходит перебор значений и корректируется радиус на более оптимальное значение и исходя из него, корректируется индекс ближайшей точки.

В принципе, можно уже использовать эту процедуру вместо FindRadius. Однако, в ряде случаев, например, когда точка имеет одинаковую координату по Y, использовать комбо — выгодней.

Что подразумеваю под комбо. Вначале тупо ищем минимальный радиус. Жёлтый круг. А потом по этому радиусу проходим уже только что написанной процедурой поиска ближайшей точки, куда передаём найденный радиус.

Вот что получилось в итоге:

Результат в картинках:

Рис.5. Поиск ближайшей точки. Быстрый и правильный.

Тот же самый массив данных, но не смотря на то, что находимся мало того, что в другом «прямоугольнике», так ещё и в другом измерении (красный — X, синий — Y), мы однозначно нашли и минимальный радиус (зелёный круг) и явно ближайшую точку.

Тестирование Kd-Tree

Чтобы протестировать правильность работы и оценить скорость поиска, сделал следующее. Нахожу индекс ближайшей точки через полный перебор и сравниваю с результатом поиска в Kd-Tree. Если индексы не совпадают, инкрементирую счётчик ошибки.

Считаем, что полный перебор — это истина в последней инстанции. Тут всё очень тривиально:

Далее, я просто прохожу всю площадь отрисовки, нахожу индексы, сравниваю и вывожу в заголовок результат:

Позволю себе спрятать в спойлер, к статье уже имеет отношение весьма опосредованное. В демо есть сверху две кнопки 2D и 3D — это запуск теста на количество точек, которые указано в левом нижнем SpinEdit’е. Операция длительная и больше 100 000 точек лучше не заказывать.

Тесты

[свернуть]

На 10 000 точек получилось следующее:

Рис.6. Тест трехмерных данных

Как видим, ошибок ноль, при полном переборе одна операция поиска занимает в среднем 0.107 миллисекунд, одна операция поиска Kd-Tree пролетает за 0.002 миллисекунды.

Рис.7. Тест двухмерных данных. Точек слишком много, поэтому отрисовки нет

На 100 000 точек, снова ошибок: 0, полный перебор: 1.082 msec, Kd-Tree: 0.016 msec.

Миллион точек завис на полчаса, но выдал такой результат:

Рис.8. Тест массива двухмерных данных размером в миллион точек

На 1 000 000 точек, снова ошибок: 0, полный перебор: 8.675 msec, Kd-Tree: 0.272 msec.

Здесь учитывается и время поиска вне области, где вообще могут находиться точки. Там поиск дольше. В любом случае средние 1/5 миллисекунды на миллионе записей это очень хорошо. Сколько занимает поиск внутри объемлющего прямоугольника массива точек можно увидеть на скрине рис.8.: тысячные доли миллисекунды.

Я хотел в начале статьи на миллионе точек видеть поиск в 0.5 миллисекунд и построение Kd-Tree меньше секунды. По факту имеем поиск в два раза быстрее, чем хотелось. Построение дерева почти половина секунды, что также немыслимо хорошо )))

Почему выбрал именно такой подход

Почему нет приватного поля массива индексов

Да, резонно… А почему? Можно было бы не передавать параметром AIndices, всё равно работаем с одним массивом. Можно было бы вместо того, чтобы создавать в узле массив индексов, использовать индекс начала в приватном поле, например, некоем FIndices.

Тут есть одна проблема. Дерево мы строим на готовом массиве данных. А если придётся добавлять данные? Например, нам нужно проверять на дубль вставляемую точку. Как осуществлять вставку в дерево? Проблема совсем не тривиальная, как может показаться.

Если у нас есть в каждом листе свой массив индексов, то мы можем вполне себе динамично осуществить вставку индекса непосредственно в него, и если количество стало больше заданного — переразделить его на два узла. Эдакий кивок в сторону R-Tree. Конечно, при наступлении некоего предела, нам придётся пересоздать дерево, но на таких скоростях построения, это уже не существенно.

Носорог плохо видит, но при его массе, это уже не его проблемы.

Если бы у нас был «глобальный» массив индексов, который уже структурирован, то такой финт был бы очень дорогим удовольствием. Потому что нам пришлось бы искать диапазон на нём, и ради вставки нового индекса задавать размер+1 и сдвигать оставшуюся часть вправо.

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

Почему нет единого массива под узлы

В этом случае ведь не придётся тратить время на выделение памяти под каждый узел. Да, это правда. Но тут есть нюансы. Куда ж без них )))

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

Тем более, что мы не знаем заранее сколько нам нужно узлов, поэтому запросим сразу возможный максимум. А это в худшем случае длина массива данных, помноженная на 2. Случай, когда в каждом листе у нас только один элемент.

Мне критичней размер данных, а скорость и так просто космическая.

Почему минимумы и максимумы существуют только как параметры

А зачем они мне вообще нужны? Они нужны только в момент построения, зачем во время построения мне их где-то ещё хранить? Если понадобится что-то дополнительное анализировать внутри рекурсии я сделаю какой-нибудь дополнительный параметр, типа ссылки на функцию, куда буду передавать текущие значения, включая и минимумы с максимумом.

Почему используется Single, а не Double или что-то ещё

Думаете экономия памяти? Не.

Просто в Delphi тип двумерной вещественной точки, это TPointF (System.Types). За трёхмерную точку отвечает тип TPoint3D (System.Math.Vectors). В качестве 4-мерной точки можно взять tagVECTOR3D (System.Math.Vectors). У всех них значение в измерении представлено типом Single.

Например:

Любой из этих типов можно понять как PKdPoint. Например, у нас есть список с указателями на TPoint3D. Тогда запись PKdPoint(FList[0])^[0] — вернёт координату X нулевого элемента списка, PKdPoint(FList[0])^[1] — координату Y и PKdPoint(FList[0])^[2] — координату Z.

Мы можем создавать список (или массив) из привычных типов, родных для Delphi, не придумывая каких-то своих. У меня в Delphi 7 для вещественных точек был специальный тип TxPoint. Ну, что тут скажешь, он устарел и умер, с восторгом перешёл на TPointF.

Весь класс в одном спойлере

Класс представлен и с отрисовкой, и с разными методами, которые используются в статье. Если будет продолжение, то предоставлю вариант, который делает сухо-строго только то, для чего он был создан. Никаких вольностей в параметрах и холстов всяких там! )))

Рис.9. Ищем точку

Сейчас он больше приспособлен для каких-то своих экспериментов. Экспериментируйте! )))

IP76.KdTree

[свернуть]

Ссылки

Тут можно посмотреть теорию, расчёт производительности, прочую сопутствующую информацию. Если статья на английском, это не значит, что я читаю Шекспира в оригинале, это значит, что гугловский переводчик меня вполне устраивает.

Вики (теория + производительность)

Разделение пространства и K-мерные деревья (стоит заглянуть)

Kd-tree and Nearest neighbor (NN) search (2D case) (понравилось + производительность)

ЖЖ: KD-деревья и R-деревья (для общего представления)

StackOverflow: Поиск ближайшей точки (как всегда познавательно)


Скачать

Друзья, спасибо за внимание!

Исходник (zip) 68 Кб. Delphi XE 7, XE 10, XE 11

Исполняемый файл (zip) 936 Kб.

Небольшой гайд

Поле, где 100 — это количество точек в массиве, где 8 — это максимальное количество точек в листе, следующая кнопка — сгенерировать массив и дерево. После генерации в заголовке кнопке покажет сколько времени ушло на создание дерева (не массива). Only Tree — построить только дерево. Подразумевается, что массив уже есть.

Массив строится на основании радио-батонов сверху, хинты подскажут. Надо выбрать нужный и нажать кнопку генерации массива.

Галка Modern — дерево будет строится не по классике, супер-быстро, при генерации эта галка учитывается, так что перед генерацией имеет смысл её выставить. Leafs — рисует только листья.

Кнопки 2D и 3D сверху — это тесты, при нажатии будет взято запрашиваемое количество точек в массиве и число элементов в листе (поля 100 и 8 на рисунке), сами сгенерят массив и дерево и будут тестировать. Чем больше точек заказано, тем дольше можно курить.

Вроде на этом этапе всё )))


5 8 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
0
Не нашли ответ на свой вопрос? Задайте его здесь!...x