SymPy 0.7.0

Просьба говорить что не так в тексте новости (:

pevzi (28.06.2011 18:45:17)

>>выполнение арифметических операций над многочленами, упрощение многочленов, раскрытие скобок, дифференцирование, нахождение пределов, интегрирование, факторизация, решение уравнений и систем уравнений, работа с матрицами и многое другое.

Списком сделай. И да, раскрытие скобок и факторизацию рядом надо поставить ИМХО.

adriano32 (28.06.2011 18:50:15)

Если не сочтешь за труд, то напиши что SymPy работает с Python2,а работа по поддержке 3-его активно ведутся

pylin (28.06.2011 18:59:11)

> раскрытие скобок и факторизацию рядом надо поставить

Просто первое — фича ядра, а второе уже из модуля polys, поэтому так получилось. Спасибо, исправил.

pevzi (28.06.2011 19:02:07)

>>Следует отметить, что в данный момент библиотека работает только со второй веткой Python, но уже ведется работа по портированию её на Python 3.

Следует отметить, что на данный момент для работы SymPy необходим Python 2 версии не ниже 2.4, а со следующей после 0.7 версии - Python 2.5. Поддержку Python 3 планируется реализовать уже в версии 0.8.

Так лучше имхо

adriano32 (28.06.2011 19:34:57)

Оперативно работают ребята )

pylin (28.06.2011 21:11:18)

А табличка "Сарказм" была или нет?
Если что, так в Roadmap написано :)

adriano32 (28.06.2011 21:15:36)

Да не я не иронизирую, они действительно довольно быстро фиксят и расширяют функциональность

pylin (28.06.2011 21:36:22)

Чем оно лучше maxima?

RCV (28.06.2011 22:08:47)

А чем maxima лучше axiom?

Она полезна тем что позволяет проводить различные вычисления, объединять в программе свои возможности с иными математическими библиотеками Python

pylin (28.06.2011 22:20:05)

По поводу axiom был тред, выяснили: пока она не пригодна для жизни

RCV (28.06.2011 22:49:07)

Анонимные эксперты?

Товарищ либо фанат Maxima и во всех темах о CAS вбрасывает просит привести аргументы, чем оно лучше Maxima, либо избирательно выбирает негативные комменты, сам при этом никогда ничего не пробуя.

adriano32 (29.06.2011 1:04:56)

Maxima и SymPy основаны на динамически типизированных языках Lisp и Python, соответственно. Как результат, при увеличении кол-ва кода увеличивается кол-во багов, что очень плохо для мат. пакетов. Более перспективным видится реализации со стат. типизацией - Axiom, по отношению к языкам - Haskell. Кстати, на последнем написана морда к Axiom - DoCon. Но пока, похоже, для жизни непригодное.

iVS (29.06.2011 1:07:33)

> Как результат, при увеличении кол-ва кода увеличивается кол-во багов

И при чем здесь динамическая типизация?

pevzi (29.06.2011 1:10:25)

Отсутствие проверки преобразования типов, сравни с Haskell.

iVS (29.06.2011 1:16:25)

Нашел сравнение на простом примере: A small example of the hidden dangers of dynamically typed programming languages

iVS (29.06.2011 1:25:06)

Axiom очень трудно "кастомизировать" под задачу, по крайней мере, мне это не удалось. Хотя да, по поддерживаемым возможностям, она - впереди планеты всей.

XVilka (29.06.2011 7:21:25)

>на последнем написана морда к Axiom - DoCon

блджад, достали с этим доконом. Он же ни на что не годен. Они не потрудились даже запилить тип Expression a и включить в свою иерархию. Чем он лучше Numeric.Prelude? Та хотя бы жива ещё и иерархия побогаче.

И уж точно он такая же морда к аксиоме, как моя жопа морда макскому.

пример по ссылке мягка скажем идиотский.
кто в реальном приложении будет собирать ввод и передавать не обработку без предварительной проверки типа введенных данных? тот ССЗБ.
после определения типа данных ты уже не сможешь сложить str и int

In [2]: "1" + 1
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/tmp/<ipython console> in <module>()

TypeError: cannot concatenate 'str' and 'int' objects

хотя кнчно ты можешь и после определения типа сделать так(тоже вариант ССЗБ):

In [7]: a="1"; type(a)
Out[7]: <type 'str'>

In [8]: a=1; type(a)
Out[8]: <type 'int'>

fr_butch (29.06.2011 8:21:00)

WTF? Я же писал: "Но пока, похоже, для жизни непригодное".

iVS (29.06.2011 10:51:53)

Пример у тебя в духе К.О. Пример, приведенный по ссылке, содержал ошибку, которая проявлялась только при одном значении параметра и до этого никак себя не проявляла. На практике получается, что приложение нужно покрыть кучей юнит-тестов. Однако, в случае такого мат. пакета как SymPy эти ваши юнит-тесты попросту бесполезны.

iVS (29.06.2011 11:07:35)

Простота языка Python покрывает подобные недостатки с лихвой. Да и вроде как при любых расчетах принято делать проверку полученных результатов — это не юнит-тесты, это гораздо проще и бьет точно в цель. Поэтому не так уж принципиальна статичность системы типов.

То есть этот мсье просто унылая тролота? Ну и хрен с ним.

Тогда и начни проверку с простого примера: пусть даны многочлены P_n(x) и Q_n(x) с рациональными коэффициентами. Причем, P_n(x) определяется из равенства:

P_{n+1}(x) = (x + a_n) P_n(x + b_n) + Q_n(x + c_n).

Покажи, что все P_n(x) будут иметь рациональные коэффициенты. Сколько unit-тестов по n нужно сделать? 10, 1000, 1000000? Может из-за какой ошибки именно в 1000001 решении коэффиценты перестанут давать правильный результат? В Haskell же есть библиотека как раз для множества рациональных чисел.

iVS (29.06.2011 12:24:16)

Ты точно уверен, что про CAS'ы говоришь, а не про proof assistant'ы, например?

Уверен, а то. То, что коэффициенты будут рациональными, я знаю. Получить по известным a_n, b_n, c_n коэффициенты при P_{n+1}(x) CAS должна уметь. Где гарантия, что полученные значения будут рациональными? И сколько юнит-тестов нужно, чтобы отловить возможные баги? Мне кажется, что при стат. типизации можно сделать проверку на рациональность. Чтобы по входящим рациональным a_n, b_n, c_n на выходе заведомо получались рациональные коэффициенты у P_{n+1}(x). Наличие такой простой проверки - огромный плюс. Ну, или та же задача, но для только целых или только действительных коэффициентов.

iVS (29.06.2011 15:05:28)

раскрытие скобок это безусловно мощное свойство

argin (29.06.2011 15:38:43)

> То, что коэффициенты будут рациональными, я знаю. Получить по известным a_n, b_n, c_n коэффициенты при P_{n+1}(x) CAS должна уметь. Где гарантия, что полученные значения будут рациональными?

А где гарантия, например, что ты получишь эти значения вообще? Гарантия что программа вообще завершится.

> И сколько юнит-тестов нужно, чтобы отловить возможные баги?

Да. Сколько юнит-тестов нужно, чтобы узнать, что программа на любых входных данных завершится?

> Мне кажется, что при стат. типизации можно сделать проверку на рациональность. Чтобы по входящим рациональным a_n, b_n, c_n на выходе заведомо получались рациональные коэффициенты у P_{n+1}(x).

ОК. Почти 100% гарантия, что в случае получения результата он будет именно рациональным числом.

> Наличие такой простой проверки - огромный плюс.

Плюс, но не такой огромный. Он спасает от тех багов, которые почти все вылавливаются еще при тестировании. Да, есть шанс, что некоторые из них попадут в релиз, но это еще никого не останавливало.

Чесслово, не понимаю сути твоей претензии.

> А где гарантия, например, что ты получишь эти значения вообще? Гарантия что программа вообще завершится.

> Да. Сколько юнит-тестов нужно, чтобы узнать, что программа на любых входных данных завершится?

Не завершится - буду знать, что есть баг. Попробую получить результат другим способом. Например, при расчетах космического корабля программа отработала, данные получены, корабль запущен. Фигня, что была небольшая ошибка, в результате которой корабль взорвался прямо в воздухе. В итоге, миллиардные потери, куча людей погибло. Ни того, ни другого не было, если бы программа _не_завершилась_. Так понятно?

> ОК. Почти 100% гарантия, что в случае получения результата он будет именно рациональным числом.

Откуда гарантия? Оно будет рациональным, если программа находит коэффициенты реккурентно, каждый раз понижая порядок степени многочлена P_n(x) на 1, т.е. нужно n шагов реккурсии. Какой-нибудь умник мог сообразить, что P_n(0) дает коэффициент при нулевой степени без реккурсии и ввел в программу для упрощения счета. При этом, из-за отсутствия проверки типов получил действительное значение.

Причем, данный пример - очень простой. Случаи, когда реально прибегают к помощи CAS, во много раз сложнее.

> Да, есть шанс, что некоторые из них попадут в релиз, но это еще никого не останавливало.

Если очередной плеер, попавший в релиз, будет немного искажать звук - никого не волнует, большинство и так будут слушать его в метро или на улице. Но я против подобного подхода к CAS, здесь ответственность куда выше.

iVS (29.06.2011 19:28:32)

> Пример у тебя в духе К.О

У тебя по ссылке тоже.

> На практике получается, что приложение нужно покрыть кучей юнит-тестов

ЛЮБОЕ приложение нужно покрывать кучей юнит-тестов, иначе оно не считается работоспособным.

> Однако, в случае такого мат. пакета как SymPy эти ваши юнит-тесты попросту бесполезны.

4.2.

Вообще в чем претензия состоит? В SymPy есть класс, представляющий собой рациональные числа, и проверить, является ли число рациональным, не составляет труда. И да, на всякий случай: питон динамически типизируемый, но типизация строгая, неявных преобразований типов нет.

pevzi (29.06.2011 19:56:49)

> ЛЮБОЕ приложение нужно покрывать кучей юнит-тестов, иначе оно не считается работоспособным.

Пример из области аналитических функций: равенство верно на всей области определения функций (внутри комплексной плоскости), если оно выполняется на счетном множестве точек, находящихся внутри границы области. Даже такой простецкий пример требует счетное количество точек. А если надо проверить корректность на всей области комплексных чисел?

> В SymPy есть класс, представляющий собой рациональные числа, и проверить, является ли число рациональным, не составляет труда.

А проверить, что все преобразования типов были проделаны корректно?

> И да, на всякий случай: питон динамически типизируемый, но типизация строгая, неявных преобразований типов нет.

Я бы не придирался, если бы альтернатив не было. Однако все это ни в какое сравнение не идет с проверкой типов в Haskell.

iVS (29.06.2011 20:19:08)

ok, хотел сказать, что докон --- не морда к аксиоме, это отдельный продукт, довольно мёртвый и с практически отсутсвующим функционалом.

А есть CAS на хацкеле? Срочно ссылку в студию!

Уже обсудили DoCon, правда, проект никакой, пилит его какой-то PhD of Computer Science. Принципиально, никто не запрещает сделать на Haskell систему типов как в Axiom, обсуждения этого вопроса мне уже как-то попадались.

iVS (29.06.2011 21:54:48)

К сожалению, повторить систему типов axiom не получится. А DoCon не рабочий, да и с последним релизом четырехлетней давности.

> К сожалению, повторить систему типов axiom не получится.

Можно узнать, почему? По запросу "Haskell + Axiom" гугл выдает ссылки даже на какие-то научные статьи, я думал, у них всё там пучком.

iVS (29.06.2011 22:29:30)

Да у них разные же системы типов. Например, насколько я помню, ad-hoc полиморфизм в Axiom достигается тем, что разные функции с одним названием вносятся в единую область видимости, а выбор конкретной функции происходит по сигнатурам и типу применяемых аргументов. Крайне противоположная ситуация с тем, как это происходит в хацкеле.

Будь все пучком, давно бы уже кто-нибудь переносил код из одного чудовища в другое.

Вот например проект, на который я наткнулся: ссылка.

iVS (30.06.2011 16:00:27)

>К сожалению, повторить систему типов axiom не получится.

тебе Numeric Prelude мало?

тем более, с одной правильной системой типов далеко не уедешь. Самое тоскливое на самом деле писать различные функции для работы с типом expression, упрощения, приведения выражений к определенному виду, повесится можно. Если это есть, то даже простенькое символьное интегрированное пишется строк в 100-150. CAS без алгоритмов "упрощений", по сути бесполезна, иначе размер выражений растет невероятно быстро.

Конечно, остальной функционал CAS (без возни с expression) пишется не так геморройно, там только и надо, что хорошая система типа. Но без выражений кас не кас.

> ЛЮБОЕ приложение нужно покрывать кучей юнит-тестов, иначе оно не считается работоспособным.

Покажи мне, где лежат юнит-тесты ядра :) И gcc тоже.

tailgunner (30.06.2011 18:04:20)

>А есть CAS на хацкеле? Срочно ссылку в студию!

Будь мужиком, напиши! А если серьезно, предлагаю написать такую. Хуже SymPy не будет точно, Хаскелл всё же. Можно в хаскелл-кафе найти ещё кого и напишем, вдохновляясь аксиомой.

> Хуже SymPy не будет точно

Предрекаю, будет гораздо хуже даже вот этого.

baverman (30.06.2011 18:20:55)

> Хуже SymPy не будет точно, Хаскелл всё же

Программа, написанная на хаскеле, автоматически становится крутой из-за того, что написана на хаскеле?

pevzi (30.06.2011 18:22:19)

> Предрекаю, будет гораздо хуже даже вот этого.

Ты про тормоза питона и необъятное потребление памяти? Тогда, пока ядро SymPy на Си не перепишут, его никто не догонит, ога. Если ядро все же перепишут, то включить его в тот же Haskell труда не составит. Настоящий мужик сам допишет нужный функционал.

iVS (30.06.2011 18:33:55)

> Ты про тормоза питона и необъятное потребление памяти?

Я про приземленные человеко-часы. Даже хаскель над ними не властен.

baverman (30.06.2011 18:53:15)

> Я про приземленные человеко-часы. Даже хаскель над ними не властен.

Тогда почему все не пишут на Java, C#, продпочитая столь "уродливые" языки как С/C++? Почему, если сейчас мода на Питон, то все нужно писать на нем? Не уверен, что у того же Питона больше плюсов, чем у Лиспа. В Maxima до сих пор полно багов. Писать, может, и легче на динамически типизируемом языке, но отлавливать и исправлять баги - одно из страшнейших наказаний. ИМХО, димамическая типизация хороша при написании небольших скриптов, но не для серьезных мат. проектов, где цена багов слишком высока.

iVS (30.06.2011 19:08:05)

> Тогда почему…

Ты слишком много вычитал между строк. Ничего, кроме оценки поделки студента-хаскелиста, я не давал. На чем писать, каждый выбирает сам, и никого, ни на что не агитирую.

baverman (30.06.2011 19:34:20)