SymPy 0.7.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>на последнем написана морда к 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'>

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

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

Простота языка 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 же есть библиотека как раз для множества рациональных чисел.

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

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

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

> То, что коэффициенты будут рациональными, я знаю. Получить по известным 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, здесь ответственность куда выше.

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

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

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

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

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

4.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As part of a project to include reasoning capabilities in the Aldor computer algebra system it is necessary to modify the type checking algorithm in Aldor. This paper reports on work to write Aldor abstract syntax trees as elements of Haskell data types, and to implement a prototype modified type checker for Aldor in Haskell.

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

тебе Numeric Prelude мало?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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