» Mathematica (математика)

Alex_B
Попробуй:
Sum[Cos[n]^2/n^3, {n, 1, Infinity}]
N[Sum[Cos[n]^2/n^3, {n, 1, Infinity}]]
Ответ Mathematica 6.02:
0.367038
0.367072+ 0.0000120766*I
Здесь уже баг налицо...

Добавлено:
Забавно, но версия 5.2 выдаёт более правильный ответ:
0.367038
0.367042 + 0.*I

Добавлено:
В MuPAD 4.06 (символьно взять не может):
numeric::sum((cos(n))^2/(n^3),n=1..infinity)
0.3670427155

popkov

Цитата:

Здесь уже баг налицо...

Странно, а я не вижу.
Если речь идет о точности численного вычисления, то естественно, она будет маленькая. Просто надо точность численного вычисления контролировать. Это можно делать разными способами. Например, так
In[96]:= N[Sum[Cos[n]^2/n^3, {n, 1, Infinity}], 20]
Out[96]= 0.36704271553731162697 + 0.*10^-21 I

Цитата:

Посмотрел я первую ссылку на ошибку Sum - 2 (Cos, invalid Indeterminate, regression bug). Насколько я смог понять, ошибка, о которой там говорится, состоит в том, что Математика не может аналитически вычислить Sum[Cos[n]^2/(n^3+1),{n,1,Infinity}]. Я бы не называл это ошибкой.

Я не уверен, где Вы нашли что

"Математика не может аналитически вычислить Sum[Cos[n]^2/(n^3+1),{n,1,Infinity}]"

Я такого нигде не писал. Вот что писал я:

http://groups.google.com/group/alt.math.recreational/browse_thread/thread/207c574740daefda/67fe71e061e4816a?lnk=raot

То есть Математика 6 выдает для это суммы значение Indeterminate .

Это абсурд ибо Mathematicа 3 в 1996 году эту же сумму считала правильно.
(см ссылку, там точное значение)

Затем они сломали что-то и дальше ВСЕ версии вверх дают дурацкое
Indeterminate

Да determinate, еще как determinate - это первокурснику ясно - ряд
мажорируется 1/(n^3 + 1), который, очевидно, сходится, да и не
так уж медленно.


-----------------------------------------------------------------

Sum[Cos[n]^2/(n^3 + 1), {n, 1, Infinity}]

-----------------------------------------------------------------
VERSION OUTPUT RESOLUTION
-----------------------------------------------------------------

Mathematica 6.0 Indeterminate <----------------------- BUG #2

Mathematica 5.2 Indeterminate <----------------------- BUG #2

Mathematica 4.2 Unevaluated <------------------------- BUG #1

Mathematica 3.0 Correct answer OK

-----------------------------------------------------------------

Вот такие пирожки.

Этот тип багов называется "регрессионный баг".

То есть сначала работало, потом, в следующей версии, уже не
работает.

vb2008

Цитата:

Я не уверен, где Вы нашли что

И я не уверен.

Цитата:

Я такого нигде не писал

Я не утверждал, что Вы это писали.

Цитата:

Это абсурд

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

Цитата:

см ссылку, там точное значение

Что-то я не нашел там. Не могли бы Вы зедь указать правильное значение?

Цитата:

Да determinate, еще как determinate

Ясень корень. Но почему Вы не допускаете, что в избранном ими методе аналитического вычисления бесконечной суммы не может возникнуть indeterminate?

Alex_B writes


Цитата:

Я не утверждал, что Вы это писали.

Теперь можете смело утверждать. Это был я.

"Проверено. Мин нет." (с) Vladimir Bondarenko Cyber Tester


Цитата:

Что-то я не нашел там. Не могли бы Вы здесь указать правильное значение?

Пожалуйста, вклеиваю прямо из моей ссылки... вот она еще раз

http://groups.google.com/group/alt.math.recreational/browse_thread/thread/207c574740daefda/67fe71e061e4816a?lnk=raot

N[(E^(-2*I-Sqrt[3])*((-I)*(-I+Sqrt[3])*E^(I+2*Sqrt[3])*Beta[E^(-2
*I),(1-I*Sqrt[3])/2,0]+I*(I+Sqrt[3])*E^I*Beta[E^(-2*I),(1+I*Sqrt[
3])/2,0]+(-1-I*Sqrt[3])*E^(3*I)*Beta[E^(2*I),(1-I*Sqrt[3])/2,0]+I
*(I+Sqrt[3])*E^(3*I+2*Sqrt[3])*Beta[E^(2*I),(1+I*Sqrt[3])/2,0]+E^
(4*I+Sqrt[3])*(2*I-I*Pi+Log[Csc[1]^2/4])+I*E^Sqrt[3]*(-2+Pi+I*Log
[4*Sin[1]^2]) + 2*E^(2*I+Sqrt[3])*(-4+2*EulerGamma+(1+I*Sqrt[3])*
PolyGamma[0,(1-I*Sqrt[3])/2]+(1-I*Sqrt[3])*PolyGamma[0,(1+I*Sqrt[
3])/2])))/24]

NSum[Cos[n]^2/(n^3 + 1), {n, 1, Infinity}]

0.217243
0.217243



Цитата:

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

О!

В самую точку!

Да пусть все, что угодно хоть трижды возникает - мне как покупателю, фиолетово, что у них там происходит - они должны дать ПРАВИЛЬНЫЙ ответ. Тем более, Wolfram Research уже это делала.

Если же правильного ответа нет - это БАГ.

Извините, но если Вы работали Quality Assurance Engineer, то Вы меня поймете, если нет - примите как оно есть в моей многолетней практике Quality Assurance Engineer, каковой я себе на шампанское и черную икру зарабатываю...

Любопытно:
Table[{2*m^z - m^z, FullSimplify[2*m^z - m^z]}, {m, 1, 21}] // TableForm
Наверное, Alex_B не согласится, что это баг, однако очевидно, что у Mathematica серьёзные проблемы с экспоненциальными функциями... Причём именно функции с чётным основанием оказываются камнем преткновения...


Добавлено:
Alex_B

Цитата:

Тогда это не будет абсурдом.

По-вашему, не абсурд принуждать пользователей к накоплению предыдущих версий программы, чтобы иметь возможность пользоваться их функционалом, отсутствующим в новой версии? Может, эту функцию проще было бы в виде отдельного подключаемого модуля тогда выпустить? Старый функционал сохранить, и новый добавить... Глупо обманывать ожидания пользователей, заявляя о выпуске "улучшенной" версии, не справляющейся с простыми задачами, которые предыдущая решала "на ура".
Да и скажите пожалуйста, так ли уж похоже, чтобы у Mathematica были таблицы готовых ответов такого типа:

Цитата:

N[(E^(-2*I-Sqrt[3])*((-I)*(-I+Sqrt[3])*E^(I+2*Sqrt[3])*Beta[E^(-2
*I),(1-I*Sqrt[3])/2,0]+I*(I+Sqrt[3])*E^I*Beta[E^(-2*I),(1+I*Sqrt[
3])/2,0]+(-1-I*Sqrt[3])*E^(3*I)*Beta[E^(2*I),(1-I*Sqrt[3])/2,0]+I
*(I+Sqrt[3])*E^(3*I+2*Sqrt[3])*Beta[E^(2*I),(1+I*Sqrt[3])/2,0]+E^
(4*I+Sqrt[3])*(2*I-I*Pi+Log[Csc[1]^2/4])+I*E^Sqrt[3]*(-2+Pi+I*Log
[4*Sin[1]^2]) + 2*E^(2*I+Sqrt[3])*(-4+2*EulerGamma+(1+I*Sqrt[3])*
PolyGamma[0,(1-I*Sqrt[3])/2]+(1-I*Sqrt[3])*PolyGamma[0,(1+I*Sqrt[
3])/2])))/24]

Добавлено:

Цитата:

Странно, а я не вижу.
Если речь идет о точности численного вычисления, то естественно, она будет маленькая.

Согласен, немного погорячился, но немного странно, что функция N[] предыдущей версии по умолчанию выдавала ответ, в котором правильные все знаки, а новая - с неправильными знаками?

vb2008

Цитата:

я себе на шампанское и черную икру зарабатываю

С чем Вас и поздравляю!


Цитата:

Если же правильного ответа нет - это БАГ.

Если неправильный ответ - это ошибка (грубый баг).
Если правильный ответ существует, а его нет - это баг.

Сейчас я вижу, что правильный ответ существует, поэтому неспособность Математики вычислить Sum[Cos[n]^2/(n^3+1),{n,1,Infinity}] можно считать багом.

Вычисляет ли старая Математика Sum[Cos[n]^2/(n^3+a),{n,1,Infinity}]?

Цитата:

Вычисляет ли старая Математика Sum[Cos[n]^2/(n^3+a),{n,1,Infinity}]?

Совершенно верно. Версия Mathematica 3.0 вычисляет и эту параметрическую
сумму без запинки - вот результат

(-4*I*LerchPhi[E^(-2*I), 1, 1 + a^(1/3)] - 2*(-1)^(1/6)*LerchPhi[E^(-2*I), 1, 1 + a^(1/3)] -
2*(-1)^(5/6)*LerchPhi[E^(-2*I), 1, 1 + a^(1/3)] + 2*I*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] +
(-1)^(1/6)*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] +
(-1)^(5/6)*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] -
2*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] -
(-1)^(1/3)*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] +
(-1)^(2/3)*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] +
2*I*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + (-1)^(1/6)*LerchPhi[E^(-2*I), 1,
(2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + (-1)^(5/6)*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] +
2*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] +
(-1)^(1/3)*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] -
(-1)^(2/3)*Sqrt[3]*LerchPhi[E^(-2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] -
4*I*E^(4*I)*LerchPhi[E^(2*I), 1, 1 + a^(1/3)] - 2*(-1)^(1/6)*E^(4*I)*LerchPhi[E^(2*I), 1, 1 + a^(1/3)] -
2*(-1)^(5/6)*E^(4*I)*LerchPhi[E^(2*I), 1, 1 + a^(1/3)] + 2*I*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] + (-1)^(1/6)*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] + (-1)^(5/6)*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] - 2*Sqrt[3]*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] - (-1)^(1/3)*Sqrt[3]*E^(4*I)*
LerchPhi[E^(2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] + (-1)^(2/3)*Sqrt[3]*E^(4*I)*
LerchPhi[E^(2*I), 1, (2 - a^(1/3) - I*Sqrt[3]*a^(1/3))/2] + 2*I*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + (-1)^(1/6)*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + (-1)^(5/6)*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + 2*Sqrt[3]*E^(4*I)*LerchPhi[E^(2*I), 1,
(2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + (-1)^(1/3)*Sqrt[3]*E^(4*I)*
LerchPhi[E^(2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] - (-1)^(2/3)*Sqrt[3]*E^(4*I)*
LerchPhi[E^(2*I), 1, (2 - a^(1/3) + I*Sqrt[3]*a^(1/3))/2] + 12*I*E^(2*I)*PolyGamma[0, 1 + a^(1/3)] +
6*(-I + Sqrt[3])*E^(2*I)*PolyGamma[0, 1 - (-1)^(1/3)*a^(1/3)] - 12*(-1)^(1/6)*E^(2*I)*PolyGamma[0, 1 + (-1)^(2/3)*a^(1/3)])/
(2*(-1 + (-1)^(1/3))*(1 + (-1)^(1/3))^2*(-3 + I*Sqrt[3])*(-3*I + Sqrt[3])*a^(2/3)*E^(2*I))

и если подставить %/.{a->1}

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

Но начиная с версии Mathematica 4.0 2000 года и по сю пору ни одна из версий
Mathematica не дает более того правильного ответа, а всучивает мне как покупателю математически некорректный ответ, Indeterminate.


Цитата:

С чем Вас и поздравляю!

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

vb2008

Цитата:

Версия Mathematica 3.0 вычисляет и эту параметрическую сумму без запинки - вот результат

Математика 6.1 тоже сумела это сделать, но через промежуточные преобразования.
Представляем Cos[n]^2/(a + n^3) в виде (1 + Cos[2 n])/(2 (a + n^3)). Затем заменяем переменные и разбиваем на две суммы. Причем каждая сумма вычисляется аналитически, а результаты совпадают с численными оценками. Суммирование лучше производить от 0 до Infinity: таким способом результат лучше упрощается. Результат второй суммы выражается через другие спец. функции, а именно, только через Hypergeometric2F1.

Так что можно считать, что здесь баг отсутствует.

Alex_B

Цитата:

Так что можно считать, что здесь баг отсутствует.

Может, проще вообще обойтись без Mathematica? Тогда уж точно баг отсутствует...

Alex_B writes


Цитата:

Так что можно считать, что здесь баг отсутствует.

Если мы хотим действовать в рамках Quality Assurance Engineering
ну типа знаменитой книжке Канера "Тестирование программного
обеспечения"

http://www.books.ru/shop/books/6004

то единственный ответ - регрессионный баг.

...

Если Вы сильнее меня в QAE, я хочу учиться у Вас.

Если я сильнее Вас в QAE, почему бы Вам не учиться у меня?

Я с точки зрения QAE - вот он... еще и не весь...

http://www.cas-testing.org/index.php?list=3

Могу ли я увидеть Ваши QAE достижения?


Добавлено:
Alex_B


Цитата:

Математика 6.1 тоже сумела это сделать, но через промежуточные преобразования.
Представляем Cos[n]^2/(a + n^3) в виде (1 + Cos[2 n])/(2 (a + n^3)). Затем заменяем переменные и разбиваем на две суммы. Причем каждая сумма вычисляется аналитически, а результаты совпадают с численными оценками. Суммирование лучше производить от 0 до Infinity: таким способом результат лучше упрощается. Результат второй суммы выражается через другие спец. функции, а именно, только через Hypergeometric2F1.

Вы несомненно обожаете математику как науку (или это искусство?)!

Безусловно, Вы правы, что искусный аналитик - а я не сомневаюсь, что Вы еще далеко не продемонстрировали всех Ваших талантов - в состоянии вынудить Mathematica сделать многое...

Тут ведь вопрос в несколько ином... Ведь она ж сама должна это делать... да и делала уже!

"За шо ж дэньгы-то плачены??!! Все, заработанное непосильным трудом!!"

Вот есть 2,000,000+ покупателей у Wolfram Research - реальных, платящих.... надо ж как-то денежки отрабатывать... уже-ж работало!

Так нет.... одно лечим, два калечим....

Единственная за 15 лет система компьютерной алгебры, которая, к моему крайнему изумлению, почти НЕ содержала регрессионных багов - это Derive, который я помогал улучшать с 1993 до 2006.

А TI-Nspire.... я промолчу..........

Если заводить речь о недостатках, то в Mathematica 6.x их море. Прежде всего, весьма существенно снизилась скорость вычисления элементарных функций и численного интегрирования по сравнению с 5.2. См. результаты выполнения стандартной функции Benchmark: http://img211.imageshack.us/img211/9857/60vs52re6.gif В результате, многие из моих расчетов (заключающиеся, главным образом, в численном интегрировании от сложных комбинаций элементарных и специальных функций) в 6.x стали работать раза в два-три медленнее. Таким образом, пакет версии 6.x сейчас можно использовать как средство для рисования красивых графиков и демонстраций, а более старые версии -- для дела. Интересно, каким образом подобные вещи могли остаться незамеченными?

Цитата:

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

Потому что никто не пишет и не обсуждает. Все молчат, как рыбы, как будто так и надо.
А откуда сам график?

---

Кстати, наткнулся сегодня на любопытный эксперимент, демонстрирующий утечки памяти в Mathematica 6.02. К сожалению, это же касается и 5.2-версии...

График строился в Excel на основе вывода функции Benchmark[].

Griefin

Цитата:

Цитата:Интересно, каким образом подобные вещи могли остаться незамеченными?
...Потому что никто не пишет и не обсуждает. Все молчат, как рыбы, как будто так и надо.

Да у большинства пока не тот уровень и естественно не те запросы.. У меня всё примитивнее.. может только через пару лет - но вряд-ли к тому времени здесь публика останется та-же (ну и версия соответственно с новыми багами)..

popkov
Посмотрел еще одну твою ссылку. Там нашел сообщение об ошибке

NSum[(Cos[n]/n)^1,{n,1,Infinity}]     slow convergence
0.0420195    RIGHT
NSum[(Cos[n]/n)^2,{n,1,Infinity}]    fast convergence
0.572578    WRONG

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

s1=Sum[(Cos[n]/n)^2,{n,1,Infinity}]//N
0.574138

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

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

Хорошая точность первого числового суммирования (по сравнению со вторым) объясняется тем, что в первом случае мы имеем знакопеременный ряд, а во втором – нет. Так что к своей сумме первый ряд приближается с двух сторон, и по малому числу слагаемых мы можем довольно точно предсказать результат.
Оценить же точность второго суммирования мы можем несколькими способами. Например, так

NSum[(Cos[n]/n)^2, {n, 1, 500}]
0.57314

Ясно, что уже третья значащая цифра неточна. Точность суммирования мы можем несколько увеличить так

s2 = NSum[(Cos[n]/n)^2, {n, 1, Infinity}, AccuracyGoal -> 10, PrecisionGoal -> 10]
0.573969

Ошибка s1 – s2 составит 0.00017. Она немаленькая, но реальная. Метод числового бесконечного суммирования дает хороший результат для положительной функции только в том случае, если она монотонная, а у нас она осциллирующая.

Следующие ошибки посмотрю позже.

ЗЫ
На личные вопросы отвечу позже. В первую очередь меня Математика интересует.

ЗЫЫ
Еще более точный метод суммирования для этого случая будет следующий

NSum[(Cos[n]/n)^2, {n, 1, Infinity}, Method -> "EulerMaclaurin"]
0.574138

Так что, Математика с этой задачей успешно справилась

Alex_B writes

Цитата:

знакопеременный ряд

Стоп-стоп. Знакопеременный ряд - это

a0 - a1 + a2 - a3 ... где aj > 0.

У нас здесь Cos[n] не ведет себя так хорошо (предсказуемо) и регулярности в чередовании знаков нет и вещи типа признака Лейбница напрямую неприменимы.

N[Table[Cos[n]/n, {n, 1, 20}], 2]

{0.54, -0.21, -0.33, -0.16, 0.057, 0.16, 0.11, -0.018, -0.10, -0.084, 0.00040, 0.070, 0.070,
0.0098, -0.051, -0.060, -0.016, 0.037, 0.052, 0.020}

Вообще, знак n-го члена здесь *невозможно* предсказать.

(кто сомневается, скажите, какой знак имеет 1000000000!-й член?)

"Вот такие, понимашь, политические расколбасы"

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

Так что сама сходимость Cos[n]/n мне не чувствуется как тривиальный факт (хотя ряд, конечно, сходится).

vb2008

Цитата:

У нас здесь Cos[n] не ведет себя так хорошо (предсказуемо) и регулярности в чередовании знаков нет и вещи типа признака Лейбница напрямую неприменимы.

Да, конечно, это не знакопеременный ряд в собственном смысле. Но здесь мы обсуждаем вопрос не о сходимости \ несходимости ряда, а о странном на первый взгляд обстоятельстве: для более медленно сходящего ряда численное суммирование дает более точный результат.

Цитата:

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

Давайте не будет голословными, и рассмотрим проблему графически. Для этого построим на одном и том же графике разность между точным и приближённым значениями для каждой из рассматриваемых бесконечных сумм, как зависимость от числа слагаемых в сумме.
Вот программа для версии 6.0.2, выводящая этот график:
sum1 = Sum[Cos[n]/n, {n, 1, Infinity}];
f1[k_] := Sum[Cos[n]/n, {n, 1, k}];
sum2 = Sum[(Cos[n]/n)^2, {n, 1, Infinity}];
f2[k_] := Sum[(Cos[n]/n)^2, {n, 1, k}];
Plot[{sum1 - f1[k], sum2 - f2[k]}, {k, 1, 1000}]
А теперь посмотрим на сам график (синяя кривая - для первой разности, красная - для второй, что очевидно):

Так который ряд сходится быстрее?

Добавлено:
Alex_B

Цитата:

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

Такая проблема действительно существует, и весьма актуальна! Вы её, собственно, подробно описали в своём посте:

Цитата:

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

s1=Sum[(Cos[n]/n)^2,{n,1,Infinity}]//N
0.574138

и значением 0.572578, полученным в результате численного суммирования.

Действительно, расхождение уже в третьем знаке, а Mathematica выводит до 6-го! Мягко говоря, это подстава! При этом в документации они ещё пишут, что Mathematica "отслеживает точность, и выводит максимальное число достоверных знаков" (в вольном переводе по памяти)! Здесь явное нае....во!

popkov
Посмотрел третью твою ссылку на ошибку. Насколько я смог понять, ошибка заключается в том, что при вычислении

Integrate[Sqrt[I x - x^2] Sqrt[I x - 3], {x, -1, 1}]

Математика дает неправильный результат. Наличие ошибки подтверждаю.

Как эту ошибку можно обойти и избежать подобных ошибок в будущем? Стратегия очевидна. Строим график подинтегрального выражения, находим особые точи и разбиваем область интегрирования на части без особых точек. В данном конкретном случае строим график подинтегрального выражения Re[Sqrt[I x - x^2] Sqrt[I x - 3]], убеждаемся в наличии особой точки при x = 0 (бесконечная производная первого порядка), заменяем наш интеграл на

2 Integrate[Sqrt[I x - x^2] Sqrt[I x - 3], {x,0, 1}]

и получаем правильный результат.

vb2008

Цитата:

скажите, какой знак имеет 1000000000!-й член?)

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

popkov

Цитата:

Так который ряд сходится быстрее?

Первый ряд сходится медленнее, а второй быстрее, как я и говорил. С этим как раз и была связана проблема.


Добавлено:
popkov

Цитата:

Действительно, расхождение уже в третьем знаке, а Mathematica выводит до 6-го! Мягко говоря, это подстава! При этом в документации они ещё пишут, что Mathematica "отслеживает точность, и выводит максимальное число достоверных знаков" (в вольном переводе по памяти)! Здесь явное нае....во!

Нет, в документации пишется другое: N[expr,n] attempts to give a result with n-digit precision. Unless numbers in expr are exact, or of sufficiently high precision, N[expr,n] may not be able to give results with n-digit precision. Мы здесь используем не стандартную числовую функцию, а процедуру бесконечного числового суммирования. Наивно надеяться, что точность будет в 16 значащих цифр.

Другие ошибки посмотрю позже.

Цитата:

Наивно надеяться, что точность будет в 16 значащих цифр.

И как это соотносится с тем, что вы писали ранее?

Цитата:

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

[no]In[1]:= s = NSum[(Cos[n]/n)^2, {n, 1, Infinity}];
In[2]:= Precision
Out[2]= MachinePrecision
In[3]:= Accuracy[s]
Out[3]= 16.1968[/no]
И при этом в расчётах по умолчанию PrecisionGoal = 1/2*WorkingPrecision = 1/2*MachinePrecision > 7, а AccuracyGoal = Infinity.
Если Mathematica по какой-то причине достичь заданной точности не может, она должна выдать предупреждение как минимум! А по-хорошему - выдать только правильные знаки!
Да и так ли уж наивно надеяться? По крайней мере, чтобы получить точность 6 значащих цифр, нужно взять всего лишь 10^6 членов ряда:
In[1]:= Sum[N[Cos[n]^2/n^2], {n, 1, 1000000}] // N // Timing
Out[1]= {19.468, 0.574137}

[s]Добавлено:
Всё же вы сами себе противоречите:

Цитата:

popkov

Цитата: Так который ряд сходится быстрее?

Первый ряд сходится медленнее, а второй быстрее, как я и говорил. С этим как раз и была связана проблема.

popkov

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

Прежде всего, мы должны различать точность представления числа и величину ошибки метода получения какого-то результата по сравнению с действительным значением. Для краткости первую величину будем называть точностью числа, а вторую величину – точностью результата (данного метода). Когда вы пользуетесь такими функциями, как Precision или Accuracy, вы получаете точность числа. Точность же результата Математика, как правило, не контролирует. Например, вам нужно вычислить, чему равна функция f1[x]

f1[x_] := Cos[1] - (Sin[1 + x] - Sin[1 - x])/(2 x);

при h = 10^-12. Число, которое вы в результате получайте, будет всегда представлено с машинной точностью. Но это не значит, что результат, который вы хотите получить, имеет точность даже близкую к машинной. В конкретном случае получаем результат с большой ошибкой.

f1[10^-12] // N
0.0000122709

вместо нуля, хотя полученное число имеет машинную точность.

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

f2[x_] := (Cos[1] (x - Sin[x]))/x;

которая дает правильный результат с машинной точностью.

f2[10^-12] // N
0.


Цитата:

И как это соотносится с тем, что вы писали ранее?

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


Цитата:

при этом в расчётах по умолчанию PrecisionGoal = 1/2*WorkingPrecision

И что из этого? Математика не заявляет, что PrecisionGoal всегда будет достигнута.


Цитата:

AccuracyGoal = Infinity

Это значит, что AccuracyGoal не принимается в расчет, принимается в расчет только PrecisionGoal.


Цитата:

Если Mathematica по какой-то причине достичь заданной точности не может, она должна выдать предупреждение как минимум!

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

Теперь о вашем втором замечании.


Цитата:

Цитата:Хорошая точность первого числового суммирования (по сравнению со вторым) объясняется тем, что в первом случае мы имеем знакопеременный ряд, а во втором – нет. Так что к своей сумме первый ряд приближается с двух сторон, и по малому числу слагаемых мы можем довольно точно предсказать результат.

Смысл этой фразы - что первый ряд сходится быстрее, поскольку "к своей сумме первый ряд приближается с двух сторон, и по малому числу слагаемых мы можем довольно точно предсказать результат". Или я совсем разучился понимать русский язык?

Мне кажется, вы просто не внимательно читаете. Придется себя цитировать. С самого начала при постановке проблемы я сказал:


Цитата:

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

Одно дело – сходимость ряда, т.е. скорость приближения частных сумм к своему пределу, а другое дело – возможность точно оценить ошибку того или иного метода суммирования. Поскольку первый ряд незнакопостоянный, его частные суммы аппроксимируют точное значение с двух сторон. Во втором же случае частные суммы дают оценку только снизу. Это обстоятельство объясняет успешность Математики стандартным методом вычислить первую сумму и возникновение трудностей при вычислении второй суммы.

Другие сообщения об ошибках Математики рассмотрю позже.

Alex_B
Спасибо за развёрнутый комментарий! Вот такие комментарии действительно проясняют ситуацию! Теперь всё стало кристалльно ясно.


Цитата:

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

Хм. Действительно:

Цитата:

Even though you may specify PrecisionGoal->n, the results you get may sometimes have much less than n-digit precision.

Хотя я бы не сказал, что такое отношение к пользователю со стороны Wolfram Research мне нравится, и что оно вообще корректно! По сути, программа оказывается "чёрным ящиком", выдающим непредсказуемый результат безо всяких гарантий! За что же деньги плачены?

P.S. Вот почему у меня всегда вызывали подозрения и сомнения, например, результаты работы даже таких, казалось бы более простых функций, как FindMinimum. Ручная реализация алгоритма Левенберга-Марквардта, например, у меня дала огромный выигрыш в скорости и точности по сравнению со встроенной функцией FindMinimum, даже если в ней указать Method->"LevenbergMarquardt". При использовании FindMinimum Mathematica ещё и накапливала память в огромных количествах, что уже можно рассматривать, как баг - промежуточные результаты FindMinimum всё равно не хранит: запросто возникает ситуация, когда в процессе поиска минимума FindMinimum уже на 3-м, к примеру, шаге на него случайно натыкается, но потом снова уходит от него далеко, и выдаёт в конечном счёте абсурдный ответ.

Цитата:

9tiku
В Варезнике была сcылка на Neural Networks for Mathematica 5.2

уже.. Не нашел. Можете выложить еще раз?

yasteff
Ответил.

popkov

Цитата:

Хотя я бы не сказал, что такое отношение к пользователю со стороны Wolfram Research мне нравится, и что оно вообще корректно! По сути, программа оказывается "чёрным ящиком", выдающим непредсказуемый результат безо всяких гарантий! За что же деньги плачены?

Давайте попробуем разобраться с этой проблемой. Конечно, когда наш общий друг покупает один килограмм черной икры, он хочет знать, продали ему 1 ± 0.5 кг или же 1 ± 0.005 кг икры. Аналогичным образом, когда Математика отвечает на наш вопрос результатом равным 1.0, мы хотим знать, означает ли это 1 ± 0.5 или 1 ± 0.005. Но строго говоря, это будет второй вопрос. Например, при вычислении f1[10^-12] Математика отвечает на ваш первый запрос выполнением математических преобразований в том порядке, в каком вы ей указали. Следует ли при этом заставлять Математику каждый раз отвечать и на второй вопрос? Я бы поставил вопрос шире. Следует ли вообще требовать от программ, подобных Математике, чтобы каждый раз они отвечали на два вопроса? Если мы задумаемся над этой проблемой, то, скорее всего, откажемся от нашего требования по следующим причинам.

Во-первых. Осуществление нашего требования превратит обычные вычисления в вычисления, принадлежащие так называемой интервальной математике. Интервальная математика это отдельная ветвь математики и, соответственно, программироваться она должна как отдельный пакет. Заставлять Математику (для простоты будем здесь говорить конкретно о Математике) выполнять все обычные вычисления как вычисления в интервальной математике будет ничем неоправданной тратой ресурсов.

Во-вторых. В таких вычислениях как бесконечное суммирование или взятие интеграла в ошибку метода вносит вклад делаемые этим методом приблизительные оценки. Эти оценки ошибки метода являются лишь оценками ошибки сверху. Поэтому в некоторых случаях невозможно в принципе дать величину ошибки метода. В таких случаях мы можем говорить не о точности метода, а лишь об оценке точности метода.

В-третьих. Когда возникает вопрос об оценке точности результата, у математика имеются достаточно средств, чтобы получить ответ на этот вопрос. Например, при вычислении f1[10^-12] мы можем задать точность промежуточных вычислений

N[f1[10^-12],$MachinePrecision]
9.005038431135662*10^-26

При вычислении бесконечной суммы – посчитать конечные суммы и сравнить с первоначальным результатом. При вычислении интеграла – увеличить точность промежуточных вычислений и сравнить с первоначальным результатом.

В-четвертых. Ответственность за возникновение ошибок результата лежит также и на пользователе. На пользователе лежит ответственность задавать Математике вопросы в корректной форме. В данном контексте это означает, что пользователь должен произвести аналитические преобразования своего вопроса, чтобы максимально его упростить по форме, а потом уже просить Математику численно его оценить. Другими словами, математик должен задавать вопрос в форме f2, а не в форме f1, чтобы получить точный результат.

Другие сообщения об ошибках Математики посмотрю позже.

Вот ещё парочка действительно опасных багов Mathematica:

1.) Integrate[Sin[(m*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}]/.m->n даёт Indeterminate, хотя
Integrate[Sin[(n*Pi*x)/L]*Sin[(n*Pi*x)/L], {x, 0, L}] даёт корректный ответ
(L*(2 - Sin[2*n*Pi]/(n*Pi)))/4.
То есть, в первом случае потерян ответ для случая m=n.

---

2.) Регрессионный баг (появился в Mathematica 6.00 - 6.02, в 5.2 его не было):
Integrate[Exp[a*x]*Cos[b*x], {x, 0, Infinity}]
даёт в Mathematica 6.02 ответ
If[b \[Element] Reals, -(a/(a^2 + b^2)),
Integrate[E^(a*x)*Cos[b*x], {x, 0, Infinity}, Assumptions -> Im[b] < 0 || Im[b] > 0]]
(потеряно условие Re[a] < 0)
Для сравнения, при указании, что a и b - действительные числа, ответ правильный, и содержит условие a < 0:
Integrate[Exp[a*x]*Cos[b*x], {x, 0, Infinity}, Assumptions -> {a \[Element] Reals, b \[Element] Reals}]
приводит к ответу
If[a < 0, -(a/(a^2 + b^2)),
Integrate[E^(a*x)*Cos[b*x], {x, 0, Infinity}, Assumptions -> Element[b, Reals] && a >= 0]]

Ещё стоит привести результат Mathematica 5.2 для общего случая (без указания, что a и b - действительные числа):
If[b \[Element] Reals && Re[a] < 0, -(a/(a^2 + b^2)),
Integrate[E^(a*x)*Cos[b*x], {x, 0, Infinity}, Assumptions -> Re[a] >= 0 || b \[NotElement] Reals]]

Легко видеть, что Mathematica 5.2 даёт ответ, содержащий все необходимые условия, а версия 6 важнейшее из них опускает...

Добавлено:

---

Alex_B

Цитата:

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

Всё-таки я считаю, что в ситуации, когда Mathematica не способна сама надёжно оценивать точность получаемого результата, она должна как минимум выдавать предупреждение об этом! Подобных ситуаций не так уж и много, как я понимаю. В конкретном случае NSum[(Cos[n]/n)^2, {n, 1, Infinity}] неточность возникает потому, что Mathematica неправильно выбирает метод суммирования, как вы сами показали выше. Так что это вполне можно считать багом: в первую очередь Mathematica должна искать возможность применить надёжные методы, которые быстро дают результат с контролируемой точностью. Если же таких методов нет, она может использовать менее надёжный метод, точность которого контролировать не может, и при этом обязательно выдавать предупреждение! То, что она этого не делает, действительно способно наносить моральный и материальный ущерб пользователю! Пользователь не обязан глубоко разбираться в математических методах проверки точности результата (которых в других случаях может не быть или они могут быть труднодоступны для изучения по самым разным причинам, хотя бы из-за отсутствия времени). Он платит хорошие деньги за то, чтобы получить ожидаемый им красивый и правильный результат, используя простые команды! Необходимость перепроверять каждый результат несколькими способами, порой трудными для изучения, сводит на нет преимущества такой системы для огромного большинства пользователей, и низводит её до языка программирования высокого уровня, а не пакета символьной математики! Фактически, наличие функций, выдающих без предупреждения результат непредсказуемой точности (а уж тем более, просто неверный) вводит в заблуждение пользователя относительно возможностей пакета! Я даже больше скажу: лучше, чтобы Mathematica вообще не выдавала ответ в тех случаях, когда она не может дать его точно, чем выдавать ответ с неизвестной ошибкой!

Цитата:

f1[x_] := Cos[1] - (Sin[1 + x] - Sin[1 - x])/(2 x);
f1[10^-12] // N
0.0000122709
f2[x_] := (Cos[1] (x - Sin[x]))/x;
f2[10^-12] // N
0.
N[f1[10^-12],$MachinePrecision]
9.005038431135662*10^-26

Спасибо Вам большое за то, что документировали "логику точности по умолчанию": стандартная документация уделяет вопросам точности явно недостаточно внимания! По-хорошему, в документации должен присутствовать где-то на видном месте специальный раздел об этом!

---

3.) Только что обнаружен регрессионный баг в NIntegrate (присутствует в Mathematica 6.02, в версиях 3, 4 и 5.2 отсутствует):
NIntegrate[Sin[z] Erf[z], {z, 0, Infinity}]
в Mathematica 6.02 выдаёт ложный ответ 0.778801 без каких-либо предупреждений или сообщений об ошибке. В предыдущих версиях Mathematica появлялись сообщения об ошибке, например в Mathematica 5.2:
In[2]:=NIntegrate[Sin[z] Erf[z],{z,0,Infinity}]
From In[2]:=
NIntegrate::inum : Integrand(Erf[z])(Sin[z]) is not numerical at {z} = {34179.2}. More…
Out[2]=NIntegrate[Sin[z] Erf[z],{z,0,\[Infinity]}]

Любопытно, что в функции Integrate, наоборот, исправлен баг с этой функцией в Mathematica 6.0.2:
Версия 6.02 под Windows правильно считает интеграл расходящимся (хоть и забывает про сходимость при a=0):
In[1]:= Integrate[Sin[x]*Erf[a*x], {x, 0, Infinity}]
Integrate::idiv: Integral of Erf[a x] Sin[x] does not converge on {0, Infinity}.
Out[1]= Integrate[Erf[a x] Sin[x], {x, 0, Infinity}]
А в версии 5.2 под Windows (а также в версиях 6.02 и 5.2 под MacOSX 10.5.2) выдаётся ложный ответ без каких-либо предупреждений:
In[1]:=Integrate[Sin[x]*Erf[a*x],{x,0,Infinity}]
Out[1]=If[Re[a] > 0 && Re[a^2] > 0, E^(-1/(4*a^2)),
Integrate[Erf[a*x]*Sin[x], {x, 0, Infinity}, Assumptions -> Re[a^2] <= 0 || Re[a] <= 0]]

"Нос вытащишь - хвост увязнет, хвост вытащишь - нос увязнет"...

Приятная новость!
Теперь для того, чтобы проверить, как Mathematica берёт конкретный неопределённый интеграл, совсем не обязательно устанавливать Mathematica! Достаточно зайти на
http://integrals.wolfram.com/

Например, проверим, как она берёт интеграл
Integrate[Sin[(m*Pi*x)]*Sin[(n*Pi*x)], x]
Вот результат:
Sin[(m - n)*Pi*x]/(2*(m - n)*Pi) - Sin[(m + n)*Pi*x]/(2*(m + n)*Pi)

А теперь возьмём этот же интеграл при m=n:
Integrate[Sin[(n*Pi*x)]*Sin[(n*Pi*x)], x]
Получаем:
x/2 - Sin[2*n*Pi*x]/(4*n*Pi)

Очевидно, подставив в первый из результатов m=n, мы получаем вовсе не второй, а неопределённость 0/0:
Indeterminate

Вот мы и обнаружили баг, даже не устанавливая Mathematica!

Добавлено:
Совершенно аналогичным образом можно убедиться, что Mathematica вообще "не видит" нулей (не умеет выделять условия, при которых функция вырождается)! Это - действительно крупная недоработка, особенно если учесть, что разработчики претендуют на то, что в программе по умолчанию всегда реализуется именно наиболее общий подход к задаче, а не частные случаи! Примеры ниже могут показаться безобидными, но в более сложных случаях ответ будет становиться просто непредсказуемым!

Попробуйте интегралы (для их взятия вам таблицы не потребуются!):

Integrate[E^((a-b)*x),x]
ответ:
E^((a - b)*x)/(a - b)
неверен при a=b (легко проверить самостоятельно).

Integrate[Cos[(a-b)*x], x]
ответ
Sin[(a - b)*x]/(a - b)
также неверен при a=b...

... думаю, список нетрудно продолжить самостоятельно...

Добавлено:
И ещё один замечательный пример из той же серии, но уже с определённым интегралом:

Integrate[(a - b)^x, {x, -1, 0}] /. a -> b
ответ:
Indeterminate

Даже двоечник решит задачу правильно, а Mathematica не справилась...

Однако
Integrate[(a - b)^x, {x, 0, 1}] /. a -> b
даёт правильный ответ 0. Вот и пример недоделанных алгоритмов...

Добавлено:
Трудно остановиться:
Integrate[Cos[a x]/Sin[x], x] /. a -> 1
ответ
ComplexInfinity

popkov writes:


Цитата:

Трудно остановиться:
Integrate[Cos[a x]/Sin[x], x] /. a -> 1
ответ
ComplexInfinity

Еще хуже вот что. Даже предельный переход порождает мусор

Limit[Integrate[Cos[a z]/Sin[z], z], a -> 1]

Infinity

то есть от z больше ничего не зависит... вместо

Log[Sin[z]] (* = Integrate[Cos[z]/Sin[z], z] *)

.... "Вот такие, понимашь, политицские расколбасы"

Best wishes,

Vladimir Bondarenko

VM and GEMM architect
Co-founder, CEO, Mathematical Director

http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing



Добавлено:
А вот еще:

Limit[Integrate[Exp[a z] Sinh[z], z], a -> 1]

-Infinity

хотя

In[1] := Integrate[Exp[1 z] Sinh[z], z]

Out[1] = E^(2*z)/4 - z/2


Или

Limit[Integrate[Exp[z] Sinh[a z], z], a -> 1]

E^z*DirectedInfinity[E^((-I)*Im[z])]

при

In[1] := Integrate[Exp[z] Sinh[1 z], z]

Out[1] = E^(2*z)/4 - z/2