Ошибки математических пакетов

[ИСН]

До некоторых пор у меня было убеждение, что "железка не врёт". То есть она может не знать каких-то частных приёмов, которые знаю я (хотя тут чаще бывает наоборот), может с упрямством ослопотама не замечать и не делать банальнейших упрощений, но если уж выдала результат - то это так и есть.
И вот я ей (Mathematica 3.0) говорю:
- Возьми-ка $\int\limits_0^\infty(1-e^{-1/x})^2dx$
А она мне:
- [ля-ля-ля...] does not converge on ${0,\infty}$
Да как же, сволочь, does not, когда оно отлично converge и я даже знаю, к чему!?

Изменил заголовок (PAV)

[Руст]

Эта не железка виновата, а программа Mathematika 3.0. Может более поздние версии уже справляются.

[ИСН]

Я это слово употребил не в смысле программиста ("есть hardware, а есть software"), но в смысле математика ("есть человек с карандашом+бумагой, а есть железка"). Так-то оно понятно, что виновата программа.

[bubu gaga]

Математика 5.2 всё посчитала Log[4]

[GAA]

Maple 7.0 вычислил: $2\ln2$. Более ранней версии у меня уже давно нет. 12-ая версия дала тот же результат. Но в других случаях Maple символьно вычисляет неправильно [один из примеров я приводил на этом Форуме], а бывает — численно неправильно.

в теме bugs форума Maple о неправильном численном вычислении GAA писал(а):

При вычислении производной некоторой функции столкнулся с неожиданным поведением Simplify. Зададим функцию:

> Digits:= 21;
> WX := (2.55563401004781745174-54.9270360964131147719*r+453.595260432302775843*r^2-1676.71648513012367970*r^3+3899.51431792874436850*r^4-4189.74977935082353329*r^5+2101.79887112923141608*r^6-408.135347197421378084*r^7)/r^5;

Если производную вывести таким способом (способ 1):

 > expand((diff(WX, r)));

или таким способом (способ 2):

 > diff(expand(WX), r);

то результат не будет содержать слагаемого вида c/r, где с – некоторая константа. Однако, если выполнить:

 > simplify(diff(WX, r));

то получим дополнительное слагаемое
0.500000000000000000000e-16/r, (*)
которого, конечно, быть не должно. Складывается впечатление, что при выполнении приведения подобных слагаемых Simplify выполняет операции с меньшим числом знаков, чем присвоено Digits. Это не может быть естественной ошибкой округления, поскольку выражение для производной, возвращаемое diff:

(-54.9270360964131147719+907.190520864605551686*r-5030.14945539037103910*r^2+15598.0572717149774740*r^3-20948.7488967541176664*r^4+12610.7932267753884965*r^5-2856.94743038194964659*r^6)/r^5-5*(2.55563401004781745174-54.9270360964131147719*r+453.595260432302775843*r^2-1676.71648513012367970*r^3+3899.51431792874436850*r^4-4189.74977935082353329*r^5+2101.79887112923141608*r^6-408.135347197421378084*r^7)/r^6

содержит сумму:
-20948.7488967541176664*r^4/r^5 + 5*4189.74977935082353329*r^5/r^6,
которая, после приведения к общему знаменателю, выражение (*) не даст.

Замечу, что если Digits присвоить 10 (значение по умолчанию), то все равно способ 1 или способ 2 приведут к выражениям, не содержащим слагаемое (*).

Проверялось в версиях 10.00 и 7.00.
[...]
в 12-ой версии баг не исправлен.

Добавлено 2.01.09

Bug Search: solveна сайте Encyclopaedia of Maple bugs bugs (42 bugs, включая ошибки dsolve и rsolve) не нашел описанной в следующем сообщении (автор mkot) ошибки. Я проверил в 7-ой, 10.00-ой и 12.00-ой версиях Maple. В 7-ой и 12-ой версиях ошибка не наблюдается, в 10-ой наблюдается.

[mkot]

Вот ещё один пример:
При попытке решить систему

$$ \left\{ \begin{array}{lcl} y(x^2+y^2) & =& 5, \\ y(x^3-y^3) &=& 7, \end{array} \right. $$

Maple 9 находит, помимо прочего, неверное решение $x = \frac75$, $y = 0$.

solve({y*(x^2+y^2)=5, y*(x^3-y^3)=7});
{y = 0, x = 7/5}, {y = 1, x = 2}, ...

[VladimirBondarenko]

ИСН
До некоторых пор у меня было убеждение, что "железка не врёт".

Недавно мы купили MATLAB 2008b за 4137.50 USD и Mathematica 7 за 590 USD (у Wolfram Research нам полагались скидки).

Символьный движок MATLAB - это MuPAD 5.1. Полный отстой.

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

Я уже не говорю про тот бред, который MuPAD 5.1 сам по себе выдает. Плохая интеграция MATLAB и MuPAD породила дополнительные проблемы.

Мы быстро рассчитали автоматически тысячи разных багов в MuPAD 5.1. Особенно в solve, int, limit, интегральных преобразованиях.

Что касается Mathematica 7 - там символьный интегратор замедлился во многих случаях. Про баги не говорю. Не пофикшены полностью даже те баги Mathematica 6, которые мы выложили в открытом доступе. И есть новые (регрессионные) баги - то есть в 6 работало, в 7 сломалось.

Потихоньку готовится выпуск Maple 13... пока там кардинальным улучшением в сторону повышения корректности результатов не пахнет.

В общем, пора нам что-то делать.

Cheers,

Vladimir Bondarenko

Co-founder, CEO, Mathematical Director

http://www.cybertester.com/ Cyber Tester Ltd.

[VladimirBondarenko]

ИСН writes:

"До некоторых пор у меня было убеждение, что "железка не врёт"."

Ваше разочарование было бы намного глубже, если бы Вы попробовали, к примеру, Integrate в Mathematica 7. Мы, купив ее за $590 (Premier Service, скидка), установили и натравили the VM machine на нее. Первый баг был найден через 7 минут.

Integrate[Sin[z]/(z Cosh[z]), {z, 0, Infinity}]

0

Это, конечно, не так. Например,

NIntegrate[Sin[z]/(z Cosh[z]), {z, 0, Infinity}]

1.16088

Вообще, за прошлые 8 месяцев мы, ведомые целью повышения производительности, переписали VM machine заново. Теперь баги в Mathematica 7 сыплются, как если Вы
тряхнете перезревшее абрикосное дерево.

То ли пора продавать их Wolfram Research, то ли построить нечто типа Mathematica Bugs Encyclopaedia - обновляемой в реальном масштабе времени...

Cheers,

Vladimir Bondarenko

CEO, Mathematical Director

Cyber Tester Ltd.
http://www.cybertester.com

phone: [phone]
fax: [phone]

3/4 Zadorozhny Str, Simferopol
Crimea 95047, Ukraine

[PSP]

[VladimirBondarenko]

The year of Cyber Tester

http://groups.google.com/group/sci.math ... 12ef378e86