Это вопрос оптимизации вычислений и к обсуждению математического формализма имеет довольно слабое отношение.
Вообще имхо, как раз в этой области особенно заметно, что вычислительные оптимизации и методы математического описания не обязаны совпадать. Некоторые научные статьи пользуются бикватернионами, например, вот смотрите, мы сделали систему управления мультикоптером на бикватернионах. Прекрасно… Только в чём концептуальная разница между парой из матрицы поворота и вектора трансляции с одной стороны и бикватернионом с другой, если эти формализмы эквивалентны. Поэтому я за то, чтобы выкладки всегда в нормальном векторно-матричном виде делать, а посчитать — это уж как вычислитель позволит.
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 в этом плане, увы, тёмная лошадка.
Статически компилируемый код хорош тем, что снижает сложность проектирования матсофта и облегчает его поставку. Это довольно удобно и выгодно, а значит оправдано.
Совмещение статически типизированного компилируемого кода и динамической типизируемого интерпретируемого в рамках одного языка довольно очевидный путь дальнейшей эволюции ЯП. Собственно, сам пайтон часто используется как скриптовая обёртка для склеивания статических библиотек. Однако очень много времени отнимает написание обёрток. Тут же мы выкидаем львиную часть работы, позволяя пользоваться преимуществами оптимизированного скомпилированного кода на языке динамической части.
Можно, конечно, спросить, а зачем вообще нужна динамическая часть, но вот опыт применения скриптовых языков показывает, что таки нужна.
Скорее всего вы умрёте :). Я вообще ни разу не специалист, лучше заслушать биологов и биоинженеров. Факторы Яманаки, скажем так, переводят клетку в состояние "стволовой", когда она еще неопределилась, кем ей быть, жировой, мышечной или, допустим клеткой печени.
С мозгом сложно. Мозг млишком завязан на структуру связей. Если начать туда бездумно добавлять нейроны, можно получить не очень хорошие последствия. Возможно так можно бороться с последствиями инсультов, разве что. Омоложение мозговых тканей здорого организма таким путём увы невозможно, потому как основная проблема — накопление внутриклеточного мусора. Не будем же мы последовательно заменять нейроны, еще каким-то образом решая проблему правильного восстановления структуры аксонов и дендритов.
Пайтон в 99% случаев рассматривпется и использунтся для веб и около веб разработки.
По моим впечатления всё строго наоборот. Пайтон — это в основном прототипирование, расчёты, анализ данных, склейка вычислительных систем. Ну, вэб конечно тоже, но не более чем на общих правах.
Теоретически могут, везде, где требуется восстановление клеток определённого типа. Факторы Яманаки это путь к практически неограниченной регенерации.
Однако надо решить кучу инженерных задач точечной доставки (иначе можно вырастить что-нибудь там где не надо бы).
И, к сожалению не все проблемы решаются путём добавления клеток.
Крупномасштабная структура вселенной в целом проанализирована. Зельдович этим занимался, в частности. А в 2019 за работы посвященные крупномасштабной структуре (вроде как) Ф.Пиблс нобелевку получил. Желающие могут ознакомится, что там и почему.
Это вопрос оптимизации вычислений и к обсуждению математического формализма имеет довольно слабое отношение.
Вообще имхо, как раз в этой области особенно заметно, что вычислительные оптимизации и методы математического описания не обязаны совпадать. Некоторые научные статьи пользуются бикватернионами, например, вот смотрите, мы сделали систему управления мультикоптером на бикватернионах. Прекрасно… Только в чём концептуальная разница между парой из матрицы поворота и вектора трансляции с одной стороны и бикватернионом с другой, если эти формализмы эквивалентны. Поэтому я за то, чтобы выкладки всегда в нормальном векторно-матричном виде делать, а посчитать — это уж как вычислитель позволит.
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 в этом плане, увы, тёмная лошадка.
Статически компилируемый код хорош тем, что снижает сложность проектирования матсофта и облегчает его поставку. Это довольно удобно и выгодно, а значит оправдано.
Совмещение статически типизированного компилируемого кода и динамической типизируемого интерпретируемого в рамках одного языка довольно очевидный путь дальнейшей эволюции ЯП. Собственно, сам пайтон часто используется как скриптовая обёртка для склеивания статических библиотек. Однако очень много времени отнимает написание обёрток. Тут же мы выкидаем львиную часть работы, позволяя пользоваться преимуществами оптимизированного скомпилированного кода на языке динамической части.
Можно, конечно, спросить, а зачем вообще нужна динамическая часть, но вот опыт применения скриптовых языков показывает, что таки нужна.
Вот собственно да… без технологии точечной доставки черевато многочисленными опухолями.
Скорее всего вы умрёте :). Я вообще ни разу не специалист, лучше заслушать биологов и биоинженеров. Факторы Яманаки, скажем так, переводят клетку в состояние "стволовой", когда она еще неопределилась, кем ей быть, жировой, мышечной или, допустим клеткой печени.
С мозгом сложно. Мозг млишком завязан на структуру связей. Если начать туда бездумно добавлять нейроны, можно получить не очень хорошие последствия. Возможно так можно бороться с последствиями инсультов, разве что. Омоложение мозговых тканей здорого организма таким путём увы невозможно, потому как основная проблема — накопление внутриклеточного мусора. Не будем же мы последовательно заменять нейроны, еще каким-то образом решая проблему правильного восстановления структуры аксонов и дендритов.
Вот печень регенировать — это да, милое дело.
На чём основано это заявление:
По моим впечатления всё строго наоборот. Пайтон — это в основном прототипирование, расчёты, анализ данных, склейка вычислительных систем. Ну, вэб конечно тоже, но не более чем на общих правах.
Теоретически могут, везде, где требуется восстановление клеток определённого типа. Факторы Яманаки это путь к практически неограниченной регенерации.
Однако надо решить кучу инженерных задач точечной доставки (иначе можно вырастить что-нибудь там где не надо бы).
И, к сожалению не все проблемы решаются путём добавления клеток.
Это любопытственно. Насколько эффективен такой jit код? Можно ли переписать математику с плюсов на питон?
Причём можно один и тот же сериал с разными сюжетами. Детектив с разными убийцами… Какой простор!
Справка.
Крупномасштабная структура вселенной в целом проанализирована. Зельдович этим занимался, в частности. А в 2019 за работы посвященные крупномасштабной структуре (вроде как) Ф.Пиблс нобелевку получил. Желающие могут ознакомится, что там и почему.