Вообще, я тут посчитал и у меня получаются удивительные, надо сказать, результаты.
Понятно, что кватернионное умножение быстрее, чем матричное само по себе… но… Вторая компонента портит все дело…
Вычисляем предберя производную: 2x*(x+3) + x^2 = 3*x*x + 6*x = 3*x*(x+2)
Итого: 1 сложение, 2 умножения. (и столько же, если мы хотим и значение функции тоже (Итого: 2 сложения, 4 умножения))
Проблема в том, что, если вы погоните дуальные числа через кватернионы, то каждая операция умножения (коих в кватернионном умножении 16) будет превращаться в три. Стоимость кватернионного умножения в дуальных числах — 48 аппаратных умножений, не считая сложений.
Это будет работать, но, как я пишу выше, это огроменный оверхед по производительности. Это вдвойне излишне, учитывая, что обычно в контексте задач кинематики (для которых обычно применяются кватернионы и бикватернионы)
g'(M*x) == M*g'(x) — производная трансформированного вектора равна трансформированной производной вектора (хотя, это, конечно… не всегда)…
Рискну предположить. Взятие производной с помощью дуальных чисел само по себе вычислительно избыточно, а значит, никак не может быть использовано для «быстрого» вычисления компонент кватернионной производной.
Случай кватернион + 3вектор тут не рассматривается, но если подумать, комбинация преобразований в этой форме включает довольно затратный поворот 3вектора. Надо будет посчитать на досуге.
У меня такой вопрос:
Есть ли преимущество в использовании бикватерниона перед преобразованием, описываемым кватернионом (для ориентации) и 3-вектором (для трансляции). Есть ли преимущество по скорости вычисления комбинированного перемещения?
Собственно, в таком варианте, мы опять потрошим брокера, передавая некоторые это функции шине, а некоторые навязываем нодам, а а в целом получаем похожий функционал.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
Дело не в мессенджере, а в том, что tcp становится плохо при хреновой связи. Это проблема сетевого и транспортного уровней, а не уровня приложения.
Получается, нужно выкинуть из головы всю хрень про шифрование, сервера и прочую лабуду и разработать аналог tcp, который будет нормально работать при 95% потерянных пакетов…
П.С. Warhammer 40000 dawn of war, надо разведчиком тау надо было снимать флаг, находясь от него с западной стороны. Тогда разведчик оставался невидимым…
Примерно так мы однажды поймём, что живём в симуляции.
— Зачем тот чувак дует на персики?
— А? Это наш колдун-практикант. Он переставляет местами слои мира, чтобы повысить равномерность распределения примесей в стальных отливках в цехе на первом этаже.
Нужно будет внимательно изучить эти методы.
P.S. Нет ли информации о том, собираются ли как-то стандартизовать эти решения с добавлением их непосредственно в браузеры в ближайшее время?
Понятно, что кватернионное умножение быстрее, чем матричное само по себе… но… Вторая компонента портит все дело…
(q0*q1, r0*q1+q0*r1) — бикватернионы — 48 умножений, 40 сложений.
(q0*q1, r0+qrot(r1, q0)) — кватернион + вектор — 41 умножение, 35 сложений.
(M0*M1, r0 + M0*r1) -> 36 умножений, 27 сложений…
!!!
Оказывается, расчет в матрицах — самый быстрый… То ли я где-то накосячил в расчете, то ли… вся картина мира едет.
x->(a,1)
x^2 -> (a,1)*(a,1) -> (a*a, a*1 + a*1) -> (b, bi)
x+3 -> (a,1) + (3,0) -> (a+3, 1+0) -> (c, ci)
x^2 * (x+3) -> (b,bi)*(c,ci) -> (b*c, b*ci + c*bi) -> (d, di)
result: (d, di).imag -> di
Итого: 6 умножений, 4 сложения.
Вычисляем предберя производную: 2x*(x+3) + x^2 = 3*x*x + 6*x = 3*x*(x+2)
Итого: 1 сложение, 2 умножения. (и столько же, если мы хотим и значение функции тоже (Итого: 2 сложения, 4 умножения))
Проблема в том, что, если вы погоните дуальные числа через кватернионы, то каждая операция умножения (коих в кватернионном умножении 16) будет превращаться в три. Стоимость кватернионного умножения в дуальных числах — 48 аппаратных умножений, не считая сложений.
g'(M*x) == M*g'(x) — производная трансформированного вектора равна трансформированной производной вектора (хотя, это, конечно… не всегда)…
Если посчитать количество операций на расчет функции + производной и на расчет функции в дуальных числах, окажется, что второе вычислительно тяжелее
Надо будет почитать статью.
P.S. Если преобразование точки, то 3вектор+кватернион однозначно медленнее матрицы 3х4.
У меня такой вопрос:
Есть ли преимущество в использовании бикватерниона перед преобразованием, описываемым кватернионом (для ориентации) и 3-вектором (для трансляции). Есть ли преимущество по скорости вычисления комбинированного перемещения?
P.S. А, хотя вижу комментарий выше.
Если есть сообщение определенного типа, которое некоторый нод ни в коем разе не хочет потерять, он объявляет об этом броадкастом. Нод производитель запоминает его и объявляет об этом в сеть и с отныне будет повторять сообщение до тех пор, пока каждый «явный» подписчик не скажет, что он это сообщение получил, или пока не истечет счетчик перепосылок (QoS в таких условиях может идти и не бродкастом, потому что издатель и подписчик уже познакомились). Но есть проблема перезагрузки производителя.
П.С. в теории то все очевидно… Когда тебе уже показали и рассказали.
Дело не в мессенджере, а в том, что tcp становится плохо при хреновой связи. Это проблема сетевого и транспортного уровней, а не уровня приложения.
Получается, нужно выкинуть из головы всю хрень про шифрование, сервера и прочую лабуду и разработать аналог tcp, который будет нормально работать при 95% потерянных пакетов…
— Зачем тот чувак дует на персики?
— А? Это наш колдун-практикант. Он переставляет местами слои мира, чтобы повысить равномерность распределения примесей в стальных отливках в цехе на первом этаже.
P.S. Нет ли информации о том, собираются ли как-то стандартизовать эти решения с добавлением их непосредственно в браузеры в ближайшее время?