Что-то вроде: Мы внедрили систему. В некоторой ситуации бот мог случайным образом выбрать один из трёх вариантов и по результату анализа вариант "пошёл нафиг" признан недостаточно удачным. А то по разделу "сферы применения", как-то не особо то понятно, как оно применяется.
Собственно, там много "может" и открытый финал у каждого кейса.
"Во второй половине 2010-х годов модели машинного обучения, предназначенные для эмоциональных вычислений, заняли прочное место в наборе технологий, применяемых в бизнесе."
Какова типовая схема применения таких технологий бизнесом? Действительно ли это работает вне лаборатории?
Это вопрос оптимизации вычислений и к обсуждению математического формализма имеет довольно слабое отношение.
Вообще имхо, как раз в этой области особенно заметно, что вычислительные оптимизации и методы математического описания не обязаны совпадать. Некоторые научные статьи пользуются бикватернионами, например, вот смотрите, мы сделали систему управления мультикоптером на бикватернионах. Прекрасно… Только в чём концептуальная разница между парой из матрицы поворота и вектора трансляции с одной стороны и бикватернионом с другой, если эти формализмы эквивалентны. Поэтому я за то, чтобы выкладки всегда в нормальном векторно-матричном виде делать, а посчитать — это уж как вычислитель позволит.
P.S. Другие умные люди, которые экономят не память, а производительность пользуются для поворотов пространства кватернионами и лениво разворачивают их до матрицы при необходимости использовать объект-оператор преобразования для операции над вектором.
Думаю эту мысль уже второй день и чем больше думаю, тем больше мне она нравится.
Когда я только начинал писать zencad, я смотрел на pythonocc и как-то он у меня не вязался с идеей программы, хотелось чтобы zencad был обёрткой над некоторой плюсовой библиотекой и чтобы вся логика оставалась на стороне плюсов, а тут получалась какая-то обёртка над обёрткой и в общем, не нравилось оно мне. Практика показала, что я выбрал не самое удобное решение — очень много кода, который решает чисто логистические задача и довольно высоки накладные расходы на внесение изменений.
Переходом на pythonOCC-core можно решить ряд проблем, а заодно наконец-то добавить возможность расширения, то есть позволить в рамках zencad использовать api opencascade на случай, если zencad окажется недостаточно функционален.
Собрал сейчас pythonocc-core для новенького opencascade-7.5.0, он сейчас с occ работает. Не знаю, перешел ли автор на occ или поддерживает все версии occ и oce. Выглядит юзабельно, можно перепереть api zencad на OCC.Core и мне эта мысль вот прям очень нравится. Есть пара вопросов по части дистрибьюции, pythonocc-core нет на pypi, а хотелось бы распространяться именно через него. максимальный вес пакета в pypi порядка 100Мб. pythonocc-core в собранном виде весит порядка 300Мб. Таким образом придётся, видимо, дополнительно выкачивать его после установки.
В общем, я поэксперементирую в этом направлении, потому как проект уже начинает ржаветь, а такая модернизация может вдохнуть в него новую жизнь.
И вот как раз тут, чтобы уравнения снова стали линейными вводится фиктивная переменная w, которая в исследованном случае всегда равная единице.
Формально для 3вектора такое преобразование нелинейно, но если мы говорим об умножении на матрицу 4на4, то такая операция линейна, но умножить на 44матрицу можно только 4вектор, а мы не обобщаясь до однородных координат работаем с 3вектором.
Нелинейна здесь операция операция добавления и последующего изъятия фиктивной переменной. И в общем, учитывая, что переменную можно и не изымать и всё время работать с расширенными векторами… Короче, имхо, это всё-таки вопрос терминологии, считать ли такие преобразования линейными.
В библиотеке, кстати, с некоторых пор появилась построение поверхности по массиву точек (процедура interpolate2), но ей таки обвязки нехватает. Не очень понятно, как эту поверхность в объёмное тело засунуть, для этого некоторая сноровка и понимание работы ядра требуется. В этом направлении тоже надо наращивать.
В защиту скриптового подхода в параметрическом моделировании могу заметить, что средства параметрического моделирования в современных мейнстримных CAD имеют часто ограничения по сравнению с нормальным языком программирования. То есть, размеры задать, массивы построить вы можете, но фильтры какие-нибудь посчитать, условные инструкции добавить, это уже сложно. Ну и конечно да, стирается грань для склеивания с результатами мат расчетов.
Новую статью по библиотеке планировалось написать еще год назад, но жизнь, как говорится, закрутила. Будем навёрстывать. Как минимум, за два года мы стали сильно стабильнее, освоили анимацию, и некоторое дополнительное количество новых операций.
Мне, как человеку немного искушённому в ТАУ понятно, хотя и я на мгновение задумался, имелся в виду в качестве входного синусоидальный сигнал или же белый шум. А вот человеку с улицы очень даже может быть непонятно.
Не уверен, все таки данная фича довольно узкоспециальна и необходима скорее авторам библиотек, которые понимают, что и зачем они делают, плюс к тому замена внешнего компилируемого кода внутренним — это скорее упрощение, чем усложнение. Тенденций же к тому, что практика распространится на весь софт не видно. Кроме того, я все же высказываюсь не относительно пайтона, а в целом по части эволюции ЯП. Даже если в пайтоне этот подход не приживётся, в ближайшие 10-15 лет мы не раз будем наблюдать поползновения в сторону интеграции компилируемого и интерпретируемого кода.
Проблема Cython как мне кажется, в отсутствии прозрачности, а потому недостаточной веры в его эффективность, если таковая вообще есть. Всё-таки цель требует явных выразительных средств. Разработчик должен понимать, что его код действительно эффективно скомпилируется. Cython в этом плане, увы, тёмная лошадка.
Статически компилируемый код хорош тем, что снижает сложность проектирования матсофта и облегчает его поставку. Это довольно удобно и выгодно, а значит оправдано.
Совмещение статически типизированного компилируемого кода и динамической типизируемого интерпретируемого в рамках одного языка довольно очевидный путь дальнейшей эволюции ЯП. Собственно, сам пайтон часто используется как скриптовая обёртка для склеивания статических библиотек. Однако очень много времени отнимает написание обёрток. Тут же мы выкидаем львиную часть работы, позволяя пользоваться преимуществами оптимизированного скомпилированного кода на языке динамической части.
Можно, конечно, спросить, а зачем вообще нужна динамическая часть, но вот опыт применения скриптовых языков показывает, что таки нужна.
Да, это именно то, что я хотел. Спасибо.
А есть более оформленные примеры?
Что-то вроде: Мы внедрили систему. В некоторой ситуации бот мог случайным образом выбрать один из трёх вариантов и по результату анализа вариант "пошёл нафиг" признан недостаточно удачным. А то по разделу "сферы применения", как-то не особо то понятно, как оно применяется.
Собственно, там много "может" и открытый финал у каждого кейса.
"Во второй половине 2010-х годов модели машинного обучения, предназначенные для эмоциональных вычислений, заняли прочное место в наборе технологий, применяемых в бизнесе."
Какова типовая схема применения таких технологий бизнесом? Действительно ли это работает вне лаборатории?
Хорошая шпаргалка. Действительно, это и есть ФП, а не всякие там монады.
Отлично!.. А то мне уже надоело на них перегоревшие светодиоды закорачивать. Опробуем.
А как же количество аккумуляторных умножений.
Это вопрос оптимизации вычислений и к обсуждению математического формализма имеет довольно слабое отношение.
Вообще имхо, как раз в этой области особенно заметно, что вычислительные оптимизации и методы математического описания не обязаны совпадать. Некоторые научные статьи пользуются бикватернионами, например, вот смотрите, мы сделали систему управления мультикоптером на бикватернионах. Прекрасно… Только в чём концептуальная разница между парой из матрицы поворота и вектора трансляции с одной стороны и бикватернионом с другой, если эти формализмы эквивалентны. Поэтому я за то, чтобы выкладки всегда в нормальном векторно-матричном виде делать, а посчитать — это уж как вычислитель позволит.
P.S. Другие умные люди, которые экономят не память, а производительность пользуются для поворотов пространства кватернионами и лениво разворачивают их до матрицы при необходимости использовать объект-оператор преобразования для операции над вектором.
Думаю эту мысль уже второй день и чем больше думаю, тем больше мне она нравится.
Когда я только начинал писать zencad, я смотрел на pythonocc и как-то он у меня не вязался с идеей программы, хотелось чтобы zencad был обёрткой над некоторой плюсовой библиотекой и чтобы вся логика оставалась на стороне плюсов, а тут получалась какая-то обёртка над обёрткой и в общем, не нравилось оно мне. Практика показала, что я выбрал не самое удобное решение — очень много кода, который решает чисто логистические задача и довольно высоки накладные расходы на внесение изменений.
Переходом на pythonOCC-core можно решить ряд проблем, а заодно наконец-то добавить возможность расширения, то есть позволить в рамках zencad использовать api opencascade на случай, если zencad окажется недостаточно функционален.
Собрал сейчас pythonocc-core для новенького opencascade-7.5.0, он сейчас с occ работает. Не знаю, перешел ли автор на occ или поддерживает все версии occ и oce. Выглядит юзабельно, можно перепереть api zencad на OCC.Core и мне эта мысль вот прям очень нравится. Есть пара вопросов по части дистрибьюции, pythonocc-core нет на pypi, а хотелось бы распространяться именно через него. максимальный вес пакета в pypi порядка 100Мб. pythonocc-core в собранном виде весит порядка 300Мб. Таким образом придётся, видимо, дополнительно выкачивать его после установки.
В общем, я поэксперементирую в этом направлении, потому как проект уже начинает ржаветь, а такая модернизация может вдохнуть в него новую жизнь.
И вот как раз тут, чтобы уравнения снова стали линейными вводится фиктивная переменная w, которая в исследованном случае всегда равная единице.
Формально для 3вектора такое преобразование нелинейно, но если мы говорим об умножении на матрицу 4на4, то такая операция линейна, но умножить на 44матрицу можно только 4вектор, а мы не обобщаясь до однородных координат работаем с 3вектором.
Нелинейна здесь операция операция добавления и последующего изъятия фиктивной переменной. И в общем, учитывая, что переменную можно и не изымать и всё время работать с расширенными векторами… Короче, имхо, это всё-таки вопрос терминологии, считать ли такие преобразования линейными.
В библиотеке, кстати, с некоторых пор появилась построение поверхности по массиву точек (процедура interpolate2), но ей таки обвязки нехватает. Не очень понятно, как эту поверхность в объёмное тело засунуть, для этого некоторая сноровка и понимание работы ядра требуется. В этом направлении тоже надо наращивать.
В защиту скриптового подхода в параметрическом моделировании могу заметить, что средства параметрического моделирования в современных мейнстримных CAD имеют часто ограничения по сравнению с нормальным языком программирования. То есть, размеры задать, массивы построить вы можете, но фильтры какие-нибудь посчитать, условные инструкции добавить, это уже сложно. Ну и конечно да, стирается грань для склеивания с результатами мат расчетов.
Новую статью по библиотеке планировалось написать еще год назад, но жизнь, как говорится, закрутила. Будем навёрстывать. Как минимум, за два года мы стали сильно стабильнее, освоили анимацию, и некоторое дополнительное количество новых операций.
Лучшее железо, кресла и прочие прибамбасы делаются для геймеров.
Интегратор :).
Мне, как человеку немного искушённому в ТАУ понятно, хотя и я на мгновение задумался, имелся в виду в качестве входного синусоидальный сигнал или же белый шум. А вот человеку с улицы очень даже может быть непонятно.
В статье использован термин "прямое моделирование". А где-то раскрыто, что это такое?
Не уверен, все таки данная фича довольно узкоспециальна и необходима скорее авторам библиотек, которые понимают, что и зачем они делают, плюс к тому замена внешнего компилируемого кода внутренним — это скорее упрощение, чем усложнение. Тенденций же к тому, что практика распространится на весь софт не видно. Кроме того, я все же высказываюсь не относительно пайтона, а в целом по части эволюции ЯП. Даже если в пайтоне этот подход не приживётся, в ближайшие 10-15 лет мы не раз будем наблюдать поползновения в сторону интеграции компилируемого и интерпретируемого кода.
Проблема Cython как мне кажется, в отсутствии прозрачности, а потому недостаточной веры в его эффективность, если таковая вообще есть. Всё-таки цель требует явных выразительных средств. Разработчик должен понимать, что его код действительно эффективно скомпилируется. Cython в этом плане, увы, тёмная лошадка.
Статически компилируемый код хорош тем, что снижает сложность проектирования матсофта и облегчает его поставку. Это довольно удобно и выгодно, а значит оправдано.
Совмещение статически типизированного компилируемого кода и динамической типизируемого интерпретируемого в рамках одного языка довольно очевидный путь дальнейшей эволюции ЯП. Собственно, сам пайтон часто используется как скриптовая обёртка для склеивания статических библиотек. Однако очень много времени отнимает написание обёрток. Тут же мы выкидаем львиную часть работы, позволяя пользоваться преимуществами оптимизированного скомпилированного кода на языке динамической части.
Можно, конечно, спросить, а зачем вообще нужна динамическая часть, но вот опыт применения скриптовых языков показывает, что таки нужна.
Вот собственно да… без технологии точечной доставки черевато многочисленными опухолями.