Да, я тоже примерно так себе и представляю. Единственное, добавлю, что скалярное произведение в виде |a|*|b|, хоть, кажется, и удовлетворяет нужным аксиомам, но не очень удобно: нулевое значение его из векторов единичной длины (измеренных линейкой) не получить, то есть ортонормированный базис не построить.
Вы правы. Но аффинное пространство по-хорошему строится «поверх» векторного. То есть векторное пространство надо объяснять так или иначе. Поворот—самую сложную из операций (как мне кажется)—можно объяснить сразу в векторном пространстве. После этого расширение до аффинного, переход к четырехмерным матрицам и все остальные матрицы (сдвиг, сжатие/растяжение, даже проекцию) понять очень просто. То есть такая последовательность изложения мне кажется оптимальной. Может быть, я когда-нибудь и напишу продолжение этой статьи.
1. вершины в настоящей графике—объекты аффинного пространства, как справедливо заметили выше. И некоторые операции над вершинами присущи только ему. Но аффинное пространство строится «поверх» векторного, так что вначале стоит рассказать про векторное пространство
2. некоторые операции с вершинами и камерой не являются линейными операторами в векторном пространстве (сдвиг, например). То есть трехмерной матрицей их не задать. Но мы уже работаем в четырехмерном пространстве (чтоб разделять векторы и точки), а четырехмерными матрицами можно задать и сдвиг
3. Я не совсем понимаю, что вы имеете в виду под " в реальных приложениях… поворачивается базисный вектор в случае с поворотом". Поворот системы координат (для простоты будем говорить о 2D) на Х градусов против часовой стрелки эквивалентен повороту камеры на Х градусов по часовой стрелке. Который, в свою очередь, эквивалентен повороту наблюдаемых объектов на Х градусов снова против часовой стрелки. То есть формулы из статьи для поворота системы координат—такие же, как и для поворота камеры или объектов (только для камеры угол надо вставить в формулу со знаком минус).
3 а. Давайте посмотрим на пункт «2. Зачем компьютерной графике матрицы?» из ссылки из вашего комментария, на матрицу поворота: ,
Последний столбец и последняя строка проистекают из расширения векторного пространства до аффинного, их можно убрать. Коеффициенты А и B можно найти чуть выше в тексте: «Где A = sin(a), B = cos(a).» То есть оставшаяся двумерная матрица—как раз формула (12) из моей статьи. Собственно, основная цель моей статьи—дать общий вывод этой формулы.
4. Ваша ссылка замечательная, но у нее другой формат (как следует из названия), это FAQ. В нем формулы без определений, особого вывода и объяснения. Как я уже сказал, цель моей статьи—дать самые важные определения и вывод самой сложной и важной, на мой взгляд, формулы.
5. (боже, как много) поворот не задается в матрице проекции. Поворот объектов задается, как указали ниже, в матрице model, поворот камеры—во view. В проекции—только проекция (как следует и из вашего FAQ и собственно из названия матрицы).
6. "«матрица поворота из трёх других матриц поворота»… что есть профанация" Ссылка на википедию из последнего раздела сразу ведет на эти элементарные вращения, а следующий подраздел в статье на википедии—о том, как собрать из них общую матрицу поворота. И конечно, можно задавать вращения по-другому, о чем я и пишу в следующем абзаце.
7. если бы я описывал подробнее трехмерные вращения, статья была бы излишне большой. Мне кажется, если понять весь текст перед последним разделом, то ссылки на википедию понять очень легко. Это оптимальное решение, на мой взгляд.
Спасибо! Вообще, я всего лишь хотел написать краткую заметку о том, почему некоторые звуки гармонируют, некоторые нет (на хабре было несколько статей, но они даже, можно сказать, с ошибками). Для этого нужно писать про преобразование Фурье. На хабре было несколько статей и про него, некоторые очень хорошие, но там нет того объяснения, которое мне нравится. А в этом объяснении используется матрица поворота. Поэтому пришлось писать вначале про матрицу поворота :-) Так что я планирую еще как минимум две статьи. И, может быть, по просьбам благодарных читателей про аффинные преобразования и кватернионы, если будет время.
Как обычно, все немного сложнее. Если почитать оригинальную статью, то у них там какая-то сложная нано-структура на углеродных нанотрубках и никеле, вроде как комбинация двух уже известных, но не так хорошо работающих нано-структур. Ниже картинка из оригинальной статьи. Их структура—это а), NiO/Ni-CNT, а две другие, на основе которых они сделали свою—b) и с), соответственно (NiO/CNT и Ni/CNT). .
Вы можете опубликовать проект на кикстартере и открыть небольшой, но полезный бизнес. Или запатентовать идею и предложить кому-нибудь, чтоб они открыли небольшой и полезный бизнес, а вам отчисляли немного прибыли.
Ну и в качестве продолжения: perfect forwarding, на мой взгляд, весьма тяжело понять из этой статьи (я не понял, например), а вот по этой ссылке есть действительно полное объяснение (нам особенно важны решения 6 и 7). Более краткое изложение этой ссылки дается в неплохом ответе на stackoverflow, хотя местами тоже скомкано. Мне кажется, можено начать со SO, а если непонятно, обращаться к первой ссылке.
Лично мне намного более коротким, понятным и по существу кажется ответ на stackoverflow на вопрос «What is move semantics?». За ним следует более подробный ответ от того же автора.
Лично меня дико бесит эта перманентная панель слева. По простой причине—читаю посты и комментарии я, как, думаю, и большинство пользователей хабра, намного больше времени, чем делаю навигацию по сайту. Поэтому 99.99% времени это бесполезные кнопки и иконки, которые отвлекают внимание и занимают место. Было бы здорово, если б ее можно было хотя бы скрыть. Старый дизайн выгодно отличался тем, что она была почти всегда не видна, как только вы немного прокрутите страницу вниз.
На самом деле, этот сервис не показывает даже корреляции, а показывает только то, что с помощью хитрого представления данных читателя можно обмануть.
Дело в том, что почти во всех данных есть сильный шум. Поэтому точки правильнее было бы не интерполировать, а аппроксимировать прямыми (а ля линейная регрессия). Если присмотреться, то графики заскейлены (на оси Y справа всегда другой масштаб и есть смещение). А любые две прямые, которые двигаются в одну сторону, можно заскейлить так, что они совпадут. Поэтому в большинстве графиков отличие корреляции от единицы обусловлено в основном шумом.
Вот, собственно и алгоритм работы сервиса: берем любых два шумящих набора данных, которые одновременно растут или падают, аппроксимируем линиями, скейлим один из графиков, чтоб линии совпали, считаем коэффициент корреляции. Вуаля! Он близок к единице. И чтоб сбить читателя с толку, интерполируем точки вместо того, чтоб рисовать линейную регрессию.
Как же плохо, когда нет хотя бы обзорного описания алгоритма и ссылки на научную статью (ссылка на статью, кстати, есть на techcrunch, а статья открыта). На techcrunch же есть и краткое описаиние—распознавание идет с помощью deep convolutional neural network.
Замечу, что этот апдейт вышел все-таки через 5 лет, не через 10 и, кроме того, это статья от других авторов.
После прочтения вашей статьи я осознал, что именно эту задачу мне предстоит решить в течение ближайших дней (но в 3D)—спасибо вам огромное за статью!—поэтому я немного почитал научные статьи по этой теме. Это оказалась довольно обширная область. И вот что я нашел: есть два очень неплохих обзора алгоритмов EDT: 2008 года и 2011 года.
В обзоре 2008 года рассматриваются только точные алгоритмы, поэтому вашего нет. В нем можно сразу перейти к заключению: из точных быстрее всего (и примерно одинаково) работают алгоритмы Maurer'а и Meijster'а. Алгоритм Маурера, судя по всему, очень сложный для реализации, а вот алгоритм Мейстера выглядит очень привлекательным.
В обзоре 2011 есть точные и неточные алгоритмы. В обзоре самые ценные—таблица 3 и картинка 4. Тот алгоритм, что вы используете, назыавется там EDT-2, он действительно дает ошибки. Что интересно, авторы показывают, что этот алгоритм работает медленне алгоритма Маурера (и, соответственно, Мейстера). Там представлен еще один точный алгоритм поновее—LLT, он описан в этой статье. Но он реально сложный (преобразования Лежандра, то-се) и лишь чуть-чуть быстрее алгоритма Маурера (и, соответственно, Мейстера). Авторы рассматривают еще один супер-алгоритм, FEED, но если присмотреться, то это алгоритм самих авторов, и он не очень популярен. Его основной недостаток—нужно заранее знать или оценить максимальную euclidean distance в картинке (чем она меньше, тем он быстрее). Поэтому его можно не рассматривать :-).
Исходя из всего этого, лично я пока собираюсь остановиться на алгоритме Мейстера. Может быть, еще посмотрю внимательнее на LLT. И может быть, даже опубликую отдельный пост с этими изысканиями.
P.S. В статье про LLT есть еще один алгоритм, NEP, быстрее чем LLT, но он, если почитать, будет работать только с выпуклыми объектами на картинке, так что в общем случае не подходит.
1. вершины в настоящей графике—объекты аффинного пространства, как справедливо заметили выше. И некоторые операции над вершинами присущи только ему. Но аффинное пространство строится «поверх» векторного, так что вначале стоит рассказать про векторное пространство
2. некоторые операции с вершинами и камерой не являются линейными операторами в векторном пространстве (сдвиг, например). То есть трехмерной матрицей их не задать. Но мы уже работаем в четырехмерном пространстве (чтоб разделять векторы и точки), а четырехмерными матрицами можно задать и сдвиг
3. Я не совсем понимаю, что вы имеете в виду под " в реальных приложениях… поворачивается базисный вектор в случае с поворотом". Поворот системы координат (для простоты будем говорить о 2D) на Х градусов против часовой стрелки эквивалентен повороту камеры на Х градусов по часовой стрелке. Который, в свою очередь, эквивалентен повороту наблюдаемых объектов на Х градусов снова против часовой стрелки. То есть формулы из статьи для поворота системы координат—такие же, как и для поворота камеры или объектов (только для камеры угол надо вставить в формулу со знаком минус).
3 а. Давайте посмотрим на пункт «2. Зачем компьютерной графике матрицы?» из ссылки из вашего комментария, на матрицу поворота:
Последний столбец и последняя строка проистекают из расширения векторного пространства до аффинного, их можно убрать. Коеффициенты А и B можно найти чуть выше в тексте: «Где A = sin(a), B = cos(a).» То есть оставшаяся двумерная матрица—как раз формула (12) из моей статьи. Собственно, основная цель моей статьи—дать общий вывод этой формулы.
4. Ваша ссылка замечательная, но у нее другой формат (как следует из названия), это FAQ. В нем формулы без определений, особого вывода и объяснения. Как я уже сказал, цель моей статьи—дать самые важные определения и вывод самой сложной и важной, на мой взгляд, формулы.
5. (боже, как много) поворот не задается в матрице проекции. Поворот объектов задается, как указали ниже, в матрице model, поворот камеры—во view. В проекции—только проекция (как следует и из вашего FAQ и собственно из названия матрицы).
6. "«матрица поворота из трёх других матриц поворота»… что есть профанация" Ссылка на википедию из последнего раздела сразу ведет на эти элементарные вращения, а следующий подраздел в статье на википедии—о том, как собрать из них общую матрицу поворота. И конечно, можно задавать вращения по-другому, о чем я и пишу в следующем абзаце.
7. если бы я описывал подробнее трехмерные вращения, статья была бы излишне большой. Мне кажется, если понять весь текст перед последним разделом, то ссылки на википедию понять очень легко. Это оптимальное решение, на мой взгляд.
Спасибо
Дело в том, что почти во всех данных есть сильный шум. Поэтому точки правильнее было бы не интерполировать, а аппроксимировать прямыми (а ля линейная регрессия). Если присмотреться, то графики заскейлены (на оси Y справа всегда другой масштаб и есть смещение). А любые две прямые, которые двигаются в одну сторону, можно заскейлить так, что они совпадут. Поэтому в большинстве графиков отличие корреляции от единицы обусловлено в основном шумом.
Вот, собственно и алгоритм работы сервиса: берем любых два шумящих набора данных, которые одновременно растут или падают, аппроксимируем линиями, скейлим один из графиков, чтоб линии совпали, считаем коэффициент корреляции. Вуаля! Он близок к единице. И чтоб сбить читателя с толку, интерполируем точки вместо того, чтоб рисовать линейную регрессию.
После прочтения вашей статьи я осознал, что именно эту задачу мне предстоит решить в течение ближайших дней (но в 3D)—спасибо вам огромное за статью!—поэтому я немного почитал научные статьи по этой теме. Это оказалась довольно обширная область. И вот что я нашел: есть два очень неплохих обзора алгоритмов EDT: 2008 года и 2011 года.
В обзоре 2008 года рассматриваются только точные алгоритмы, поэтому вашего нет. В нем можно сразу перейти к заключению: из точных быстрее всего (и примерно одинаково) работают алгоритмы Maurer'а и Meijster'а. Алгоритм Маурера, судя по всему, очень сложный для реализации, а вот алгоритм Мейстера выглядит очень привлекательным.
В обзоре 2011 есть точные и неточные алгоритмы. В обзоре самые ценные—таблица 3 и картинка 4. Тот алгоритм, что вы используете, назыавется там EDT-2, он действительно дает ошибки. Что интересно, авторы показывают, что этот алгоритм работает медленне алгоритма Маурера (и, соответственно, Мейстера). Там представлен еще один точный алгоритм поновее—LLT, он описан в этой статье. Но он реально сложный (преобразования Лежандра, то-се) и лишь чуть-чуть быстрее алгоритма Маурера (и, соответственно, Мейстера). Авторы рассматривают еще один супер-алгоритм, FEED, но если присмотреться, то это алгоритм самих авторов, и он не очень популярен. Его основной недостаток—нужно заранее знать или оценить максимальную euclidean distance в картинке (чем она меньше, тем он быстрее). Поэтому его можно не рассматривать :-).
Исходя из всего этого, лично я пока собираюсь остановиться на алгоритме Мейстера. Может быть, еще посмотрю внимательнее на LLT. И может быть, даже опубликую отдельный пост с этими изысканиями.
P.S. В статье про LLT есть еще один алгоритм, NEP, быстрее чем LLT, но он, если почитать, будет работать только с выпуклыми объектами на картинке, так что в общем случае не подходит.