К сожалению это неправильный алгоритм. То есть он делает не совсем то, что очевидно ожидает большинство пользователей. Проще понять это на 2D модели Алгоритм в статье делает как на левом рисунке, а ожидается результат, как на правом.
Всё верно, зато этот алгоритм прост в реализации. Можно использовать Ransac, но что делать если исходных точек мало? статья с хорошим алгоритмом http://mathforum.org/library/drmath/view/63765.html
алгоритм в приведённой выше статье рабочий. Однако появился вопрос, а что делать с полученной информацией, какому примитиву соответствует плоскость? Для чего можно использовать параметры плоскости?
Что толку от простого в реализации алгоритма, если он не отвечает на поставленный вопрос? Но и его можно приспособить для нахождения "правильного" ответа. Идея очень проста. Находим в первом приближении параметры преобразования (смещение и углы разворота). Преобразуем исходное облако точек с помощью этих параметров так, что плоскость становится почти параллельно основанию. Опять находим новые параметры и суммируем их с исходно найденными. Идём на шаг 2 и так до сходимости. З.Ы. Поиск в гугле говорит, что реализация SVD на Lisp существует.
svd на лисп? Это не верх извращения? Я надеюсь это шутка. --- Сообщения объединены, , Оригинальное время сообщения: --- кстати в алгоритме во второй статье функция минимизируется по ортогональным расстояниям
как я понял в приведённом листинге реализации алгоритмов разложений нет, в коде есть ссылки на lapack. Читаемость кода в лиспе никакая, возможно ли вообще на лиспе написать серьёзную библиотеку по линейной алгебре? Нет. Это же реально шутка.
На самом деле хочется обсудить алгоритм или стратегию аппроксимации цилиндра 3д точками. Занялся этой темой недавно, был объект с наклонными сваями, нужно было центра их искать. Поделитесь кто что знает по этой теме, из того расчёта что точек будет немного, не более 10 на цилиндр.
Спасибо за совет, увидел пост поздно, нашел реализацию через Geomagic Desing X, умеет очень много, особенно порадовала возможность установки пределов вылета точек, но продолжаю искать подобные программы ввиду того что Geomagic только с моделями у которых центр тяжести в 0;0;0 работает, приходится трансформировать из WGS-84 и обратно. Если всего 10 точек на весь цилиндр, то об облаке и аппроксимации говорить не приходится. Из практических решений могу предложить либо измерить диаметр и крен, либо снимать по ярусам примерно (тут наличие точек на разной высоте в пределах одного яруса влиять особо не будет), а потом вычислить центр тяжести каждого яруса и через него проводить ось цилиндра.[/QUOTE]
Это актуально только для одной установки прибора, единственной фронтальной плоскости не всегда хватает что бы снять достаточное сечение для нахождения центра тяжести фигуры.
Дошли наконец руки. Выкладываю простую итерационную (копи-пастную) схему без всяких там макросов и прочей ерунды.
я не понял. в начальных вычислениях используются координаты, которые получаются после второй итерации... Иными словами задача решается, но ответ уже известен?
Нет. Нулевая итерация - это среднее исходных координат. А все остальные итерации - среднее "центров". Ежели итерации не устраивают и нужен МНК (OLS), то пользуй https://github.com/Geo-Linux-Calculations/gnumeric-ols .
дело не в "устраивает / не устраивает", а в том, что dx и dy находятся как разности текущих координат и финальных координат центра. Если нам уже известны финальные координаты, то к чему все вычисления - вот что не ясно.
Откуда они известны? PS: Скопируй по значению "first iter" в "target", после этого копируй "second iter". И всё поймёшь.
