а она распространенная или как?

пройдись поиском по ЛОРу за всё время.

Вот что интересно: а на каких задачах, кроме как для написания интерактивной оболочки к ней, используются возможности символьных вычислений у этой библиотеки?

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

> Быстрые манипуляции с большими целыми числами и рациональными дробями благодаря использованию библиотеки CLN, в основе работы которой лежит метод умножения Карацубы (Karatsuba) и метод умножения Шёнхаге-Штрассена (Schönhage-Strassen) для больших целых чисел

Epic Fail. В документации по CLN сказано, что собственная реализация в CLN больших целых и рациональных тормозит по сравнению с GMP.

Для таких студентов есть Maxima и Axiom, не считая проприетарных вещей.

> Студенты, которых заставляют брать интегралы не численными методами, не оценят.

Для студентоты есть http://integrals.wolfram.com

А больше никому символьные вычисления не нужны.

А ты кто такой, чтобы за всех говорить?

>А ты кто такой, чтобы за всех говорить?

Я говорю не за всех, я высказываю своё мнение. Право высказывать которое мне дано по факту рождения. И да — неужели они кому-то таки нужны?

> И да — неужели они кому-то таки нужны?

Если бы были не нужны, эта библиотека не дожила бы до версии 1.6.

Вобщем понял, что известность есть, это хорошо.Кстати, а ты сам какие либы используешь для матзадач?

Отлично! Лисп посрамлен на собственном поле. Лисперы пыжились-пыжились, а ничего кроме CAS назвать областью применения лиспа не смогли. Что они теперь скажут, болезные?

> А больше никому символьные вычисления не нужны.

Тупой?

http://www.stephenwolfram.com/publications/articles/computing/90-mj/1/text.html

А ИИ куда делось вдруг?

\\не лиспер,но SICP уважаю

ИИ давно все на Java пишется.

>метод умножения Карацубы (Karatsuba) и метод умножения Шёнхаге-Штрассена (Schönhage-Strassen) для больших целых чисел

Сейчас (с 2007 г.) для больших целых чисел наибыстрейшим считается «алгоритм Фюрера» (Martin Fürer). (PDF)

>Очень быстрое эвристическое вычисление наибольшего общего делителя (НОД) для полиномов

Для «Ъ» расскажите кто-нибудь в 2-х словах на чём основано :)

пошли новости по плюсам, радует.

>ИИ давно все на Java пишется.

О как, а мы дураки то всё AllegroCL и Ocaml пользуем..

>>Вот что интересно: а на каких задачах, кроме как для написания интерактивной оболочки к ней, используются возможности символьных вычислений у этой библиотеки?

Тонко, плюсую вопрос. Генерация матановой капчи, например.

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

>> Karatsuba

И с какой целью на русском сайте фамилия россиянина транслитерируется в английский?

> а мы дураки

Хорошо хоть, что сам это понимаешь

Интересно бы сравнить это с sympy

Интересно бы сравнить это с sympy

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

Начало работы над GiNaC - 1999 г., а работа идет так медленно. Польза добавления в C++ символьных вычислений неясна, поскольку в нагрузку к CAS предлагает изучение еще и C++. С оберткой к Питону это выглядит аппетитней.

Поразило высказывание из их FAQ:

Q: What was the problem with Maple?

A: First of all: Maple is a wonderful product. Yes, it is. However, when you start writing large-scale applications you are doomed to run into trouble with it unless you are extremely careful and know exactly what you are doing. One important problem with Maple (and any other CAS) is the lack of a standardized up-to-date language. For instance, the concept of Object Oriented design is not present. Quite generally, facilities for encapsulation are poorly developed. Maple's language is dynamically scoped and from time to time you find that Maple's developers messed up with that by not properly declaring variables to be local resulting in obscure (history-dependend) bugs. How are we supposed to write scientific software with the language even the Maple developers have problems to handle? Mathematica and Macsyma face the same problem, by the way.

Rather than pointing out a number of Maple's linguistical and structural weaknesses let us ponder about one simple fact. The purpose of symbolic computation is to «simplify» mathematical expressions so that we can more easily understand their structure or code them more efficiently for numerical evaluation by a computing machine. Most beginners simply use their Computer Algebra tool by typing in some expression and then tell the system to «simplify» it, usually by a command with that name. This is fine, so far. However, when several people embark on a large-scale project that relies considerably on symbolic computation, it is unacceptable. This is because whenever somebody codes simplify(expression) somewhere, this is a demonstration of his inability to understand what's going on. Does he really want to «simplify» a rational function by canceling a greatest common divisor from numerator and denominator? Or maybe he really only wants to expand an expression and later collect for some variable? When the CAS manufacturer ships the next release of his product, such calls to «simplify» are doomed to break. Sure, CAS do an amazing job at simplifying results. But since nobody ever defined what «simple» really means the next release might come up with different (though still hopefully correct) results. This frequently leads to subtle errors that are very hard to debug. When you start a large-scale program involving Computer Algebra, it is a good idea to memorize this: «simplify» is evil.

Действительно, каждый раз не знаешь к чему приведет simplify. Интересно глянуть, что предлагают взамен :)

Опенсорс двигает вперёд науку-и это хорошо!

Кто тут поумнее, ответьте на вопрос

Почему нельзя однажды раз и навсегда описать логику аналитической CAS на абстрактном языке, а потом из этого абстрактного кода кодогенерацией делать код хоть на коболе, хоть на плюсах?

Зачем столько велосипедов? Алгоритм simplify - некая выработанная временем более-менее универсальная вещь, которая всплывает с точностью до изоморфизма и в Axiom, и в Maxima и где только ни.

Например, и в Axiom, и в Maxima уже используются довольно абстрактные языки, можно было их и взять за основу и не придумывать убогие костыли с нуля.

Почему нельзя однажды раз и навсегда описать логику аналитической CAS на абстрактном языке

Как вы себе это представляете? Ни одна CAS не может быть полной по определению.

Алгоритм simplify - некая выработанная временем более-менее универсальная вещь

Does he really want to «simplify» a rational function by canceling a greatest common divisor from numerator and denominator? Or maybe he really only wants to expand an expression and later collect for some variable? When the CAS manufacturer ships the next release of his product, such calls to «simplify» are doomed to break. Sure, CAS do an amazing job at simplifying results. But since nobody ever defined what «simple» really means the next release might come up with different (though still hopefully correct) results.

Как видите, есть альтернативные точки зрения.

Например, и в Axiom, и в Maxima уже используются довольно абстрактные языки, можно было их и взять за основу и не придумывать убогие костыли с нуля.

Это два совершенно разных подхода: или стат. типизация как в Aldor, Spad, или динамическая (Maxima). Второй подход гораздо гибче, но может приводить к ошибкам.

>>Как вы себе это представляете? Ни одна CAS не может быть полной по определению.

И что? Что такое «полнота CAS» и о каких определениях речь? Опять Гёделю спать не даете?

Как видите, есть альтернативные точки зрения.

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

В приведенных цитатах основная проблема лежит в закрытоcти алгоритма Maple. Они жалуются на то, что не знают, что делает функция конкретно.

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

>>Это два совершенно разных подхода: или стат. типизация как в Aldor, Spad, или динамическая (Maxima).

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

>>и это стало бы некого рода стандартом в мире математических инструментов.

Ведь есть же таблицы интегралов. Значит и есть оптимальный порядок серфинга по этим таблицам для конкретного выражения. Вот этот порядок и сделать общедоступным в математическом сообществе.

Опять Гёделю спать не даете?

Ага.

В приведенных цитатах основная проблема лежит в закрытоcти алгоритма Maple. Они жалуются на то, что не знают, что делает функция конкретно.

Еще там мысль, что допустим, есть последовательность формул и надо упростить конечную. То, как упрощать промежуточные результаты, будет определяться целью цепочки преобразований. Иногда, чуть другая форма упрощения вылится в butthurt при упрощении конечного результата.

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

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

>>Py

Только как временный винегрет.

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

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

Думаю, время Лиспа в CAS уже ушло: там уж очень легко сделать так, что никто не будет понимать код, кроме автора. Систему типов того же Aldor можно улучшать, чему может способствовать и интерес Haskell-истов к этому языку.

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

Так об этом речи и не идет. Сейчас sympy наращивает возможности, а ядро так или иначе придется переписать.

Ведь есть же таблицы интегралов.

Множество интегрируемых ф-ций как минимум счетное, тут никакие таблицы не помогут.

>>Ага.

Зря. Я поднимал этот вопрос тут каждый раз, как только кто-то взвякивал про Гёделя. Каковы практические затыки возникнут, кроме глюков при ответе на дурацкий вопрос, оперирующий множеством всех множеств? От CAS требуется упростить и вычислить интеграл, пару теорем доказать несложных. Ну так можно же уберечь разум машины от перегорания в парадоксе Рассела - руками задать, чтобы просто не оперировала невыводимыми утверждениями типа множества всех множеств и все будет ок.

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

По крайней мере внятного примера еще никто не привел.

>>Множество интегрируемых ф-ций как минимум счетное, тут никакие таблицы не помогут.

Ни при чем тут этот факт совершенно. Множество линейных функций тоже как минимум счетное, это же не мешает тебе взять интеграл int kx+b по таблице?

>>Думаю, время Лиспа в CAS уже ушло: там уж очень легко сделать так, что никто не будет понимать код, кроме автора.

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

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

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

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

Выявить и обойти - только сужая круг задач, но к ним все задачи не свести (та же квант. теория поля).

внятного примера еще никто не привел.

Внятного примера чего?

>>Внятного примера чего?

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

Ни одного такого примера не видел. Только рассуждения, на практике же все работает как и задумано.

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

Самая сложность - придумать нормальный DSL, а не очередной велосипед. Тогда без разницы, можно хоть на Си делать. Видимо, в DSL и лежит основная проблема и ступор в развитии CAS. Не случайно, после Mathematica/Maple/Maxima появился интерес к Axiom, хотя по возможностям последний им уступает.

>>но к ним все задачи не свести (та же квант. теория поля).

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

в CAS это помешать вычислить интеграл или производную, в физике это помешать расчитать матрицу плотности например.

Тут, наверное, не помешает. А вот разложения в ряды - тут столько возможностей, что и однозначный выбор сделать нелегко. Мое мнение, что человеку нужны как лошадь (CAS), так и поводья, а нормальных средств управления процессом нет. В результате, как проверить какую интересную идею, так все равно все вручную делать приходится.

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

Куда хуже - ультрафиолетовая расходимость.

>>А вот разложения в ряды - тут столько возможностей, что и однозначный выбор сделать нелегко.

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

>>Куда хуже - ультрафиолетовая расходимость.

Какая же связь между этой расходимостью и априорной противоречивостью того матана, на котором построен формальный вывод этой расходимости?

Ответ - никакой связи. Просто ляп для красного словца. В том, чтобы вытереть тряпкой нефизические решения, никакой математической противоречивости не лежит.

Так что чушь не неси.

Какая же связь между этой расходимостью и априорной противоречивостью того матана, на котором построен формальный вывод этой расходимости?

Я что о связи говорил? Там проблема в другом, что формально ряд расходящийся, но из него можно выделить вклад вакуума (бесконечный) плюс вклад частиц. Ни о какой неполноте я не говорил. Просто человек с подобной задачей может справиться, а CAS - на сегодняшний момент, никак.

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

Нет, конечно. Я говорил о том, каких мне средств на сегодняшний день в CAS не хватает. Какое там единое ядро CAS, если многих возможностей просто нет.