LINUX.ORG.RU

GiNaC 1.6.0 - C++ библиотека для символьных вычислений

 , , ,


0

2

Новый выпуск 1.6.0 C++ библиотеки GiNaC (GiNaC is Not a CAS), предназначенной для неинтерактивных операций с символьными математическими выражениями, стал доступен для загрузки 22 мая 2011 года спустя 11 месяцев после выхода предыдущей версии 1.5.8.

GiNaC написана на ISO-C++ и распространяется под лицензией GNU GPLv3.

Среди основных возможностей GiNaC следующее:

  • Быстрые манипуляции с большими целыми числами и рациональными дробями благодаря использованию библиотеки CLN, в основе работы которой лежит метод умножения Карацубы (Karatsuba) и метод умножения Шёнхаге-Штрассена (Schönhage-Strassen) для больших целых чисел
  • Эффективная обработка полиномов от нескольких переменных и рациональных функций
  • Поддержка линейной алгебры включает символьные матрицы, векторы и решение уравнений
  • Очень быстрое эвристическое вычисление наибольшего общего делителя (НОД) для полиномов
  • Большое количество встроенных функций (sin, cos, atan, sinh, factorial, итд)
  • Символьное дифференцирование и разложение в ряды для всех встроенных функций
  • Различные формы возвращаемого результата (в том числе для последующей численной подстановки)
  • Эффективное и безопасное использование памяти благодаря внутреннему подсчёту ссылок (reference counting) на все выражения

Разработчикики позиционируют библиотеку как неинтерактивную, то есть наиболее естественный способ взаимодействия с ней - написание программы на C++, компиляция и затем линковка с libginac. Собственно разработчики используют компилятор C++ из GCC.
Связанный проект PyGiNaC - интерфейс к библиотеке GiNaC на Python, заброшен с версии GiNaC 1.3.2, тем не менее исходный код всё ещё доступен в CVS репозитории.

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

>>> Загрузить исходный код

>>> Страница проекта

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

pylin ★★★★★ ()

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

anonymous_incognito ★★★★★ ()

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

prischeyadro ★★★☆☆ ()

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от prischeyadro

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

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

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


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

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

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

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

prischeyadro ★★★☆☆ ()
Ответ на: комментарий от prischeyadro

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

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

Manhunt ★★★★★ ()
Ответ на: комментарий от adriano32

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

pylin ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

pylin ★★★★★ ()

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

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

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

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

quickquest ★★★★★ ()

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

Vernat ★★ ()
Ответ на: комментарий от anonymous

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

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

fontpath ()
Ответ на: комментарий от anonymous_incognito

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

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

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

mclaudt ()

>> Karatsuba

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

zzo ()
Ответ на: комментарий от fontpath

> а мы дураки

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

anonymous ()

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

michwill ★★★★★ ()
Ответ на: комментарий от michwill

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

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

baverman ★★★ ()

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

iVS ★★★★★ ()

Поразило высказывание из их 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. Интересно глянуть, что предлагают взамен :)

iVS ★★★★★ ()

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

Ubuntu1104 ()

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

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

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

mclaudt ()
Ответ на: Кто тут поумнее, ответьте на вопрос от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

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

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

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

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

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

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

mclaudt ()
Ответ на: комментарий от iVS

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

Ага.

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

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

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

>>Py

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

>>Ага.

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

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

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

mclaudt ()
Ответ на: комментарий от iVS

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

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

mclaudt ()
Ответ на: комментарий от iVS

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

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

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

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

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

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от iVS

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

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

mclaudt ()
Ответ на: комментарий от iVS

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

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

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

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

mclaudt ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Ответ на: комментарий от mclaudt

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

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

iVS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.