Вот сейчас было совсем не понятно.
>Умножения на матрицу между собой коммутируют
Я не очень хорош в математике, но умножение на матрицу не коммутативно, зато ассоциативно (https://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BD%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BC%D0%B0%D1%82%D1%80%D0%B8%D1%86)
Пусть v_i — координата вершины вазы, R_1, t_1 — поворот/перенос в систему координат стола, R_2, t_2 — поворот/перенос в систему координат вагона, R_3, t_3 — поворот/перенос в систему координат камеры
В базовом случае, новая вершина вазы в финальной системе координат будет
v'_i = R_3 * (R_2 * (R_1 * v_i + t_1) + t_2) + t_3
(три умножения на матрицу, плюс добавление смещений)
Но т.к. умножение ассоциативно
v'_i = R_3 * R_2 * R_1 * v_i + R_3 * R_2 * t_1 + R_3 * t_2 + t_3 (мог напутать чуть в формуле, но думаю идея ясна)
Или
v'_i = R' * v_i + t'
где R' = R_3 * R_2 * R_1 и t' = R_3 * R_2 * t_1 + R_3 * t_2 + t_3
Т.е. вся операция сводится к умножению на матрицу 3x3 и добавлению смещения
Вам не нужен тут кватернион.
Кстати, хороший вопрос, что быстрее при вычислении на современных CPU — «честный» поворот вершины при помощи кватерниона или умножение на матрицу поворота, с учетом векторизации
Строго говоря, вам не особо то и нужны матрицы, главное, эта сама идея о том, что повороты можно компоновать вместе, получая просто другой поворот, и идея что поворот(вектор + вектор) это одно и то же что поворот(вектор) + поворот(вектор)
Согласен с предыдущим комментатором и добавлю, что (имхо) ваш пример хорошо бы смотрелся в виде «трейта» с автоматическим выводом реализации, чем в виде метакласса
Если честно, то очень бы хотелось увидеть подробный вывод шага 5 (самая мякотка BFGS, то что отличает его от остальных алгоритмов этого же класса).
Ну и квадратичная ф-ия в качестве примера это слабо как-то. Может лучше взять что-то сложнее и практичней? Вроде нейросети (BFGS довольно часто использовали для обучения, до наступления эпохи SGD)
>Цель статьи не тестирование библиотек, а сравнение интерфейсных возможностей решателей для двух конкретных групп задач линейного программирования
В таком случае, на это стоило делать акцент.
К тому же, мне кажется что если мы сравниваем библиотеки по способу задания задачи, cvxopt/pulp явно предпочтительней. Почему? Потому что они позволяют писать значительно более читаемый и поддерживаемый код.
Ограничения добавляются/удаляются в cvxopt одной строчкой. Функционал так же очень легко модифицируется. Фактически вы просто пишете формулы описывающие ограничения и функционал.
Если же матрицы сформированы вручную, то это разумеется более эффективно, но читать и работать с таким кодом довольно неприятно. Как минимум вам придется писать комментарии
Собственно код из вашей статьи.
Это cvxopt. Если нормально назвать переменные (x1 — moneyForTVAd x2 — moneyForRadioAd) и ф-ии (z — negativeSalesIncr и т.д.), то понять какую именно задачу вы решаете, сможет даже человек не знакомый с предметной областью
Это та же самая задача, но решаемая при помощи linprog (если я не ошибаюсь, конечно).
Работать можно и с этим, но согласитесь, это значительно менее приятно чем работать с кодом выше.
c = [-30,-1] #Функция цели
A_ub = [[90,5]] #'1'
b_ub = [10000]#'1'
A_eq = [[3,-1]] #'2'
b_eq = [0] #'2'
Идем дальше
>Различные формы представления исходных данных с использованием матрицы для формирования функции цели и без влияет на аппаратное время выполнения программы.
Да, это разумеется так.
>При усреднении времен такое сравнение корректно и оправдано.
И это тоже верно, вот только я не увидел чтобы вы решали запускали решение LP задач тысячу раз, чтобы говорить об усреднении. Но это не самое страшное. Проблема в том, что на задачах очень малой размерности на время выполнения начинает сильно влиять различный .Overhead. Overhead от вызова самих питоновских функций (если анализ задачи оптимизации в cvxopt выполняется на питоне, то он может занимать больше времени чем сама оптимизация), overhead от вызова C/C++ кода, и т.д.
Более того, как я и писал выше, linprog и cvxopt (в вашем случае) используют разные алгоритмы оптимизации заточенные под разные случаи. Симплекс-метод хорошо подходит для небольших задач (как ваши), GLPK же (если я правильно понял) использует итеративный алгоритм и заточен под большие задачи (т.е. сотни тысяч переменных/ограничений). Подозреваю, что у cvxopt есть и другие солверы, однако у вас вызывается именно этот. Собственно на этом можно остановиться, сравнение производительности в такой ситуации смысла не имеет.
>Кроме того само утверждения голословно — какой класс, каких задач.
Выпуклые оптимизации же =) CVXOPT — ConVeX OPTimization.
Статью пробежал по диагонали, но очень бросилось в глаза то, что тестовая задача слишком маленькая для тестирования производительности библиотек. Тест который выполняется сотые доли секунды это совсем не показательно для интерпретируемого языка.
Я совершенно не специалист в оптимизациях, но все же я не уверен что корректно сравнивать scipy linprog и cvxopt.
Первый — просто вызов симплекс солвера по готовым матрицам.
https://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.optimize.linprog.html
cvxopt же — целый DSL (т.е. вам не нужно в ручную подготавливать данные для солвера) позволяющий решать намного больший класс задач.
Так же, в примере с cvxopt использовался солвер glpk (https://www.gnu.org/software/glpk/), который вроде как предназначен для работы с задачами большой размерности («The GLPK (GNU Linear Programming Kit) package is intended for solving large-scale linear programming (LP)»). Т.е. в статье сравнивается теплое с мягким.
На самом деле все сильно зависит от конкретного случая.
Скажем, если вам требуется держать много небольших ассоциативных массивов, то хэш-таблицы возможно не особо хороший вариант, т.к. потребляют относительно много памяти.
Ага, я кажется видел что-то подобное но связанное с PyPy (возможно даже в их блоге).
Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
>Now is the time to submit paper on Fully Convolutional Encoder Decoder BatchNorm ResNet GAN applied to Style Transfer, optimized with Adam.
Это великолепно
>Начиналась разработка, как мы уже говорили, с Theano, но со временем добавился Tensorflow. Сейчас Keras по умолчанию работает именно с ним
А известно, почему перешли с Theano на TF?
Особенно это интересно в контексте:
>Также код Keras работает на Tensorflow пока медленнее, чем на Theano
>Веса связей в нейросетях AlphaGo сформированы на основе миллионов партий, несколько дополнительных партий — капля в море.
Ну строго говоря не совсем. Обучали скорее всего SGD, что означает, что мы можем сильно изменить веса просто прогнав новые примеры с большим learning rate. Другое дело, что после такой операции сеть, скорее всего, будет плохо играть.
>Умножения на матрицу между собой коммутируют
Я не очень хорош в математике, но умножение на матрицу не коммутативно, зато ассоциативно (https://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BD%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BC%D0%B0%D1%82%D1%80%D0%B8%D1%86)
Пусть v_i — координата вершины вазы, R_1, t_1 — поворот/перенос в систему координат стола, R_2, t_2 — поворот/перенос в систему координат вагона, R_3, t_3 — поворот/перенос в систему координат камеры
В базовом случае, новая вершина вазы в финальной системе координат будет
v'_i = R_3 * (R_2 * (R_1 * v_i + t_1) + t_2) + t_3
(три умножения на матрицу, плюс добавление смещений)
Но т.к. умножение ассоциативно
v'_i = R_3 * R_2 * R_1 * v_i + R_3 * R_2 * t_1 + R_3 * t_2 + t_3 (мог напутать чуть в формуле, но думаю идея ясна)
Или
v'_i = R' * v_i + t'
где R' = R_3 * R_2 * R_1 и t' = R_3 * R_2 * t_1 + R_3 * t_2 + t_3
Т.е. вся операция сводится к умножению на матрицу 3x3 и добавлению смещения
Вам не нужен тут кватернион.
Кстати, хороший вопрос, что быстрее при вычислении на современных CPU — «честный» поворот вершины при помощи кватерниона или умножение на матрицу поворота, с учетом векторизации
Строго говоря, вам не особо то и нужны матрицы, главное, эта сама идея о том, что повороты можно компоновать вместе, получая просто другой поворот, и идея что поворот(вектор + вектор) это одно и то же что поворот(вектор) + поворот(вектор)
Ну и квадратичная ф-ия в качестве примера это слабо как-то. Может лучше взять что-то сложнее и практичней? Вроде нейросети (BFGS довольно часто использовали для обучения, до наступления эпохи SGD)
>Цель статьи не тестирование библиотек, а сравнение интерфейсных возможностей решателей для двух конкретных групп задач линейного программирования
В таком случае, на это стоило делать акцент.
К тому же, мне кажется что если мы сравниваем библиотеки по способу задания задачи, cvxopt/pulp явно предпочтительней. Почему? Потому что они позволяют писать значительно более читаемый и поддерживаемый код.
Ограничения добавляются/удаляются в cvxopt одной строчкой. Функционал так же очень легко модифицируется. Фактически вы просто пишете формулы описывающие ограничения и функционал.
Если же матрицы сформированы вручную, то это разумеется более эффективно, но читать и работать с таким кодом довольно неприятно. Как минимум вам придется писать комментарии
Собственно код из вашей статьи.
Это cvxopt. Если нормально назвать переменные (x1 — moneyForTVAd x2 — moneyForRadioAd) и ф-ии (z — negativeSalesIncr и т.д.), то понять какую именно задачу вы решаете, сможет даже человек не знакомый с предметной областью
Это та же самая задача, но решаемая при помощи linprog (если я не ошибаюсь, конечно).
Работать можно и с этим, но согласитесь, это значительно менее приятно чем работать с кодом выше.
Идем дальше
>Различные формы представления исходных данных с использованием матрицы для формирования функции цели и без влияет на аппаратное время выполнения программы.
Да, это разумеется так.
>При усреднении времен такое сравнение корректно и оправдано.
И это тоже верно, вот только я не увидел чтобы вы решали запускали решение LP задач тысячу раз, чтобы говорить об усреднении. Но это не самое страшное. Проблема в том, что на задачах очень малой размерности на время выполнения начинает сильно влиять различный .Overhead. Overhead от вызова самих питоновских функций (если анализ задачи оптимизации в cvxopt выполняется на питоне, то он может занимать больше времени чем сама оптимизация), overhead от вызова C/C++ кода, и т.д.
Более того, как я и писал выше, linprog и cvxopt (в вашем случае) используют разные алгоритмы оптимизации заточенные под разные случаи. Симплекс-метод хорошо подходит для небольших задач (как ваши), GLPK же (если я правильно понял) использует итеративный алгоритм и заточен под большие задачи (т.е. сотни тысяч переменных/ограничений). Подозреваю, что у cvxopt есть и другие солверы, однако у вас вызывается именно этот. Собственно на этом можно остановиться, сравнение производительности в такой ситуации смысла не имеет.
>Кроме того само утверждения голословно — какой класс, каких задач.
Выпуклые оптимизации же =) CVXOPT — ConVeX OPTimization.
Я совершенно не специалист в оптимизациях, но все же я не уверен что корректно сравнивать scipy linprog и cvxopt.
Первый — просто вызов симплекс солвера по готовым матрицам.
https://docs.scipy.org/doc/scipy-0.15.1/reference/generated/scipy.optimize.linprog.html
cvxopt же — целый DSL (т.е. вам не нужно в ручную подготавливать данные для солвера) позволяющий решать намного больший класс задач.
Так же, в примере с cvxopt использовался солвер glpk (https://www.gnu.org/software/glpk/), который вроде как предназначен для работы с задачами большой размерности («The GLPK (GNU Linear Programming Kit) package is intended for solving large-scale linear programming (LP)»). Т.е. в статье сравнивается теплое с мягким.
Скажем, если вам требуется держать много небольших ассоциативных массивов, то хэш-таблицы возможно не особо хороший вариант, т.к. потребляют относительно много памяти.
Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
Это великолепно
Это несколько забавно в свете того, что у DeepMind есть свой Sonnet (вроде как тоже обертка над TF)
А известно, почему перешли с Theano на TF?
Особенно это интересно в контексте:
>Также код Keras работает на Tensorflow пока медленнее, чем на Theano
Ну строго говоря не совсем. Обучали скорее всего SGD, что означает, что мы можем сильно изменить веса просто прогнав новые примеры с большим learning rate. Другое дело, что после такой операции сеть, скорее всего, будет плохо играть.
Вы правы, «шахматному» ядру нужна пара.