Кажется, что назревает новая тема для исследования) Думаю, что было бы полезно сравнить разные реализации этого алгоритма (углы или SVD). Вероятно, что я будущем поделюсь результатами этого исследования.
Рассмотренный в статье алгоритм является не единственным, использующим сингулярные числа. Вполне возможно, что результаты сравнения могут оказаться неоднозначными и/или неочевидными. В противном случае, люди бы не продолжали исследовать SVD-алгоритмы.
Третий хранить не надо вообще, он из первых двух вычисляется, ведь их сумма равна 180 градусов. Что похоже надежнее SVD
Любую надёжность всегда хочется оценивать численно. То, что три угла содержат больше информации о треугольнике - это факт, с которым нельзя спорить. К тому же SVD само по себе подразумевает возможность отбрасывания части сингулярных чисел с потерей какой-то информации.
Однако на практике едва ли третий угол что-то изменит. Углы, как и сингулярные числа, скорее всего будут считаться, а после дискретизироваться с каким-то шагом, влияющим на робастность системы. Дисторсия, шумы, паразитные токи у матрицы, битые пиксели и прочие неприятности реальных условий эксплуатации неизбежно приведут либо к необходимости увеличения шага, либо к росту допустимой погрешности. Я не уверен, что это не перечеркнет все старания, связанные с введением третьего угла.
Также мои слова подкрепляются небольшим сравнением автора статьи [1], где оценивается точность рассмотренного мною алгоритма и некоторых других, в частности, использующих углы для геометрического голосования.
Можно же сравнивать не сами углы, а их косинусы,синусы или тангенсы
Да, можно. Но я упомянул, что тригонометрия не всегда является дешевой с вычислительной точки зрения.
Ещё могу подметить, что иногда важен итоговый размер скомпилированной программы (например, если существует вероятность, что её придется удалённо загружать на спутник). В случае, если нет аппаратного FPU, использование тригонометрических функций заставляет компиляторы генерировать ощутимо больше кода. Значительно больше, чем при использовании базовых арифметических операций.
Мне казалось, что плюсом тут было бы нечеткое сравнение.
Да, это вы подметили очень точно. На практике это существенно.
Да, все верно, вы правильно поняли алгоритм. Сравнивать сингулярные числа вместо углов лучше по нескольким причинам.
Во-первых, в каталоге нужно хранить не 3 числа (3 угла), а всего 2. Если предположить, что в каталоге 200 тысяч треугольников, то экономия по памяти может оказаться ощутимой, особенно, если идентификация проводится на микроконтроллере.
Во-вторых, сравнение углов треугольника требует использования тригонометрических функций по типу арккосинуса. Есть и чуть более эффективные способы сравнения углов, но все их объединяет необходимость использования чисел с плавающей точкой. Если алгоритм работает на железе без FPU, то это становится большой проблемой, ведь тригонометрические функции начинают съедать производительность. SVD же можно выполнять в целых числах, что на порядок быстрее.
Кажется, что назревает новая тема для исследования) Думаю, что было бы полезно сравнить разные реализации этого алгоритма (углы или SVD). Вероятно, что я будущем поделюсь результатами этого исследования.
Рассмотренный в статье алгоритм является не единственным, использующим сингулярные числа. Вполне возможно, что результаты сравнения могут оказаться неоднозначными и/или неочевидными. В противном случае, люди бы не продолжали исследовать SVD-алгоритмы.
Спасибо за комментарий к моему ответу.
Любую надёжность всегда хочется оценивать численно. То, что три угла содержат больше информации о треугольнике - это факт, с которым нельзя спорить. К тому же SVD само по себе подразумевает возможность отбрасывания части сингулярных чисел с потерей какой-то информации.
Однако на практике едва ли третий угол что-то изменит. Углы, как и сингулярные числа, скорее всего будут считаться, а после дискретизироваться с каким-то шагом, влияющим на робастность системы. Дисторсия, шумы, паразитные токи у матрицы, битые пиксели и прочие неприятности реальных условий эксплуатации неизбежно приведут либо к необходимости увеличения шага, либо к росту допустимой погрешности. Я не уверен, что это не перечеркнет все старания, связанные с введением третьего угла.
Также мои слова подкрепляются небольшим сравнением автора статьи [1], где оценивается точность рассмотренного мною алгоритма и некоторых других, в частности, использующих углы для геометрического голосования.
Да, можно. Но я упомянул, что тригонометрия не всегда является дешевой с вычислительной точки зрения.
Ещё могу подметить, что иногда важен итоговый размер скомпилированной программы (например, если существует вероятность, что её придется удалённо загружать на спутник). В случае, если нет аппаратного FPU, использование тригонометрических функций заставляет компиляторы генерировать ощутимо больше кода. Значительно больше, чем при использовании базовых арифметических операций.
Да, это вы подметили очень точно. На практике это существенно.
Да, все верно, вы правильно поняли алгоритм. Сравнивать сингулярные числа вместо углов лучше по нескольким причинам.
Во-первых, в каталоге нужно хранить не 3 числа (3 угла), а всего 2. Если предположить, что в каталоге 200 тысяч треугольников, то экономия по памяти может оказаться ощутимой, особенно, если идентификация проводится на микроконтроллере.
Во-вторых, сравнение углов треугольника требует использования тригонометрических функций по типу арккосинуса. Есть и чуть более эффективные способы сравнения углов, но все их объединяет необходимость использования чисел с плавающей точкой. Если алгоритм работает на железе без FPU, то это становится большой проблемой, ведь тригонометрические функции начинают съедать производительность. SVD же можно выполнять в целых числах, что на порядок быстрее.