Sergey B Kirpichev <skirpichev@gmail.com> writes: > On Friday, February 7, 2014 2:30:02 PM UTC+4, Dmitrii Kashin wrote: >> Сергей, мне пока несколько непонятно, что именно я должен там >> смотреть. Какой код просится быть автогенерированным и почему? > > Я подразумевал, что ваш. Почему - потому что обычно от аналитической > постановки задачи до численного кода куча промежуточных шагов. > > Элементарный пример: пусть у вас есть задача Коши для > системы ОДУ. Вы можете в C стартовать из аналитического описания > задачи, преобразовать функции в форму, удобную для численного счета, > сгенерировать эффективный численный метод интегрирования именно > данной конкретной задачи? Или все это предлагается каждый раз > делать вручную? Ну, вообще говоря, мы как раз строим численные методы вручную, потому что не получается построить его в хорошем виде аналитически. Вот например в моей текущей задаче я решаю уравнения Эйлера с учётом многофазности среды. Я использовал maxima, чтобы линеаризовать систему уравнений, но оказалось, что мою систему линеаризовать нельзя, а это означало, что я не смогу найти скорость распространения волны, и не построю схему Годунова, так как не решу задачу о распаде разрыва. Поэтому пришлось реализовывать менее хорошую в плане "размазанности" решения схему Лакса-Фридрихса. Но даже если бы я нашёл матрицу перехода, то Вы представляете в каком виде она обычно получается? Обычно я, получив её, сажусь и выписываю каждый член ручками, и долго-долго занимаюсь его упрощением. Как пример, я могу предложить Вам построить схему Годунова для классической трёхмерной системы уравнений Эйлера. Я всё ещё помню то чувство, когда я впервые увидел собственные вектора. =) Так что численный метод для каждой новой задачи строится вручную, и никаких других путей я не вижу. >> Расчёты сильно ресурсоёмки, не скажется ли работа этих "автогенераторов" на >> производительности? > > Вы, наверно, все-таки используете оптимизацию в C (всякие -ON), а не > делаете ее руками? Здесь приблизительно то же самое. Человек > может создать хороший новый алгоритм, а сгенерировать > эффективный код для вычисления полинома - вполне задача для машины. > > Собственно, ничто вам не мешает писать и непосредственно > численный код в Python (+scipy/numpy). И никаких проблем > с юникодом... Ну, учитывая, что Python славится своей нерасторопностью (хотя может я неправ, fixme), у меня есть подозрения, что проблемы с производительностью всё же будут. >> Да и Python для меня язык незнакомый. > > Если вам знаком другой достаточно высокоуровневый язык - пишите > на нем. На ассемблере писать все подряд - глупо. > > Кстати, скорее всего Julia умеет нормальный юникод, можете > посмотреть в эту сторону. Но там нет возможности делать аналитические > вычисления (впрочем, вроде прикрутили sympy), да и scipy > проекты развиваются ощутимо быстрее и умеют уже гораздо больше > чем их любые конкуренты из мира OSS. Ну, про Julia я слышу впервые. Опять же, связка C++ и LLVM вызывает недоверие. В википедии употреблена фраза "sophisticated types system", я вот сижу и думаю, это хорошо или плохо? В общем, проект пока молодой, я думаю, что как и Python - вряд ли вариант. > Если не знаком никакой - есть повод выучить. Ну, на Perl, Bash и Zsh я бы не стал писать таких вещей. Я чётко ощущаю, что эти языки явно не для научных целей предназначены. >> Смысл был в том, чтобы *видеть* результат обработки комментария, >> оформленного в виде amsmath и latex непосредственно в буфере, где я >> редактирую код. > > Как вариант, в python можно писать код в ipython notebook, > напр. см.: > http://ipython.org/presentation.html > http://fperez.org/talks/1203_ipython_pycon.pdf > Вполне годится для прототипирования, математику можно > писать в latex (текстовые "ячейки" в markdown). Посмотрел. Штука интересная. Напоминает Maxima/Mathematica. > PS: На рассылку я не подписан, ставьте CC если интересен ответ. Ok.
Attachment:
pgpkKpds6rEm5.pgp
Description: PGP signature