Да, действительно, матрицы больших размерностей нашли своё применение в проективной геометрии. Я оставил ссылку в полезных материалах (третья), так как это интересный момент, но не тема моего исследования: в однородных координатах манипуляции с матрицами чуть более замысловатые, нежели добавление строки (0 0 0 1) для трёхмерного пространства, например, обратите внимание :)
Если вы исходите из логики, что все трансформации в линейном пространстве являются линейными, то вы вводите себя в заблуждение.
Линейные трансформации специально называются линейными по той причине, что по определению обладают линейными свойствами: аддитивностью и однородностью, что, к слову, и позволяет выразить их через матрицы не прибегая к трюкам, описанным в статье.
Например x' = 3x — это линейное преобразование, а x' = 3x+4 — нелинейное, но оба афинные. Не верьте мне на слово, проверьте свойства.
Разделяю ваши справедливые замечания. Слог у автора действительно довольно тяжелый, но решил не нарушать его подход к выражению своих мыслей.
Статья имеет продолжение в виде ещё двух частей. Я планировал выкладывать их ежедневно в течении этих дней, чтобы не перегружать, действительно, головы читателей, но, встретив такой уровень непонимания, вынужден согласиться, что такая фрагментная подача потерпела фиаско и следовало бы запостить всё сразу. Я отредактирую пост, дополнив канву авторской идеи. Думаю некоторые вопросы закроются сами собой.
Автор оригинальной статьи действительно скуп на примеры, но я могу привести своё понимание методологии и ответить на ваши вопросы.
Представим ситуацию, что мы делаем веб приложение и у нас готов фронтенд, но мы оба не совсем понимаем как будет работать бэкенд. Если мы совсем не представляем как устроен бэкенд в принципе, то делаем анализ. Но мы с вами опытные разработчики и уже знаем как примерно работает и что умеет тот же ASP.NET и поэтому эту фазу пропускаем, не испытывая неопределенности "а решит ли бэкенд наши проблемы?".
Мы знаем как сделать, но не знаем что именно. Вместо написания кода мы берем бумагу и начинаем расписывать схему, а что же бэкенд вообще должен делать в продукте (включая бумагу в процесс разработки мы тем самым создаем спайк).
Расписывая схему мы вдруг понимаем, что от бэкенда нам нужны только облачные функции, даже без базы данных. Эта глубокое погружение в проблему позволило нам выявить деталь, которая меняет представление о решении проблемы. Теперь мы можем не писать бэкенд вовсе, а, например, взять Firebase как сервис исполнения облачных функций.
А представьте что вместо спайка мы бы уже началиписать код с тестами да с контроллерами, потратили время и силы и выбросили бы это всё. Тут мы выбросим только бумагу.
Мы не пользовались файрбейсом и для нас это тоже неизвестность. Тут свой внутренний цикл анализ-спайк-трассер: мы смотрим что умеет сервис (анализ), пробуем написать простые облачные функции (спайк), а потом попробовать написать наши околопродакшен функции (трассер) чтобы убедиться, что файрбейс удовлетворяет нашим требованиям.
Возвращаемся к основному циклу. Мы теперь уверены, что файрбейс умеет что нам надо, но мы не уверены, а подружится ли он с нашей архитектурой, поэтому вместо внедрения файрбейса мы берем какую-нибудь одну функцию и пробуем встроить это в рабочее окружение (делаем трассер), чтобы фронтенд пнул файрбейс и тот посчитал и вернул ожидаемый результат.
Работает? Кайф. Внедряем полноценно. Файрбейс выбросил утку? Возвращаемся к началу цикла и просматриваем другие варианты решения исходной проблемы.
TLDR
Спайк по своим свойствам никак не может уйти в продакшен. Нужно применить дополнительные усилия, чтобы создать некоторый встраиваемый продукт, а это уже трассер, а не спайк.
Методология борется с неизвестностью. Мы уменьшаем риски, тратим меньше сил, прикладывая усилия к анализу, спайкам и трассерам. Разумеется опытный специалист в конкретной област этого делать не будет, если он уже точно знает как можно решить проблему.
Да, действительно, матрицы больших размерностей нашли своё применение в проективной геометрии. Я оставил ссылку в полезных материалах (третья), так как это интересный момент, но не тема моего исследования: в однородных координатах манипуляции с матрицами чуть более замысловатые, нежели добавление строки (0 0 0 1) для трёхмерного пространства, например, обратите внимание :)
Если вы исходите из логики, что все трансформации в линейном пространстве являются линейными, то вы вводите себя в заблуждение.
Линейные трансформации специально называются линейными по той причине, что по определению обладают линейными свойствами: аддитивностью и однородностью, что, к слову, и позволяет выразить их через матрицы не прибегая к трюкам, описанным в статье.
Например x' = 3x — это линейное преобразование, а x' = 3x+4 — нелинейное, но оба афинные. Не верьте мне на слово, проверьте свойства.
Я мог ввести вас в заблуждение по поводу идеи автора. Вот тут рассказал почему . Статья обновлена, приятного чтения :)
Разделяю ваши справедливые замечания. Слог у автора действительно довольно тяжелый, но решил не нарушать его подход к выражению своих мыслей.
Статья имеет продолжение в виде ещё двух частей. Я планировал выкладывать их ежедневно в течении этих дней, чтобы не перегружать, действительно, головы читателей, но, встретив такой уровень непонимания, вынужден согласиться, что такая фрагментная подача потерпела фиаско и следовало бы запостить всё сразу. Я отредактирую пост, дополнив канву авторской идеи. Думаю некоторые вопросы закроются сами собой.
Хорошего чтения :)
Автор оригинальной статьи действительно скуп на примеры, но я могу привести своё понимание методологии и ответить на ваши вопросы.
Представим ситуацию, что мы делаем веб приложение и у нас готов фронтенд, но мы оба не совсем понимаем как будет работать бэкенд. Если мы совсем не представляем как устроен бэкенд в принципе, то делаем анализ. Но мы с вами опытные разработчики и уже знаем как примерно работает и что умеет тот же ASP.NET и поэтому эту фазу пропускаем, не испытывая неопределенности "а решит ли бэкенд наши проблемы?".
Мы знаем как сделать, но не знаем что именно. Вместо написания кода мы берем бумагу и начинаем расписывать схему, а что же бэкенд вообще должен делать в продукте (включая бумагу в процесс разработки мы тем самым создаем спайк).
Расписывая схему мы вдруг понимаем, что от бэкенда нам нужны только облачные функции, даже без базы данных. Эта глубокое погружение в проблему позволило нам выявить деталь, которая меняет представление о решении проблемы. Теперь мы можем не писать бэкенд вовсе, а, например, взять Firebase как сервис исполнения облачных функций.
А представьте что вместо спайка мы бы уже началиписать код с тестами да с контроллерами, потратили время и силы и выбросили бы это всё. Тут мы выбросим только бумагу.
Мы не пользовались файрбейсом и для нас это тоже неизвестность. Тут свой внутренний цикл анализ-спайк-трассер: мы смотрим что умеет сервис (анализ), пробуем написать простые облачные функции (спайк), а потом попробовать написать наши околопродакшен функции (трассер) чтобы убедиться, что файрбейс удовлетворяет нашим требованиям.
Возвращаемся к основному циклу. Мы теперь уверены, что файрбейс умеет что нам надо, но мы не уверены, а подружится ли он с нашей архитектурой, поэтому вместо внедрения файрбейса мы берем какую-нибудь одну функцию и пробуем встроить это в рабочее окружение (делаем трассер), чтобы фронтенд пнул файрбейс и тот посчитал и вернул ожидаемый результат.
Работает? Кайф. Внедряем полноценно. Файрбейс выбросил утку? Возвращаемся к началу цикла и просматриваем другие варианты решения исходной проблемы.
TLDR
Спайк по своим свойствам никак не может уйти в продакшен. Нужно применить дополнительные усилия, чтобы создать некоторый встраиваемый продукт, а это уже трассер, а не спайк.
Методология борется с неизвестностью. Мы уменьшаем риски, тратим меньше сил, прикладывая усилия к анализу, спайкам и трассерам. Разумеется опытный специалист в конкретной област этого делать не будет, если он уже точно знает как можно решить проблему.