Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Wolfram Mathematica | Математика

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Открыть новую тему     Написать ответ в эту тему

xy



ХУдератор
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Wolfram Mathematica 14

Загрузка и поиск "лекарств"в "Варезнике"


 
Здесь обсуждаем вопросы языка Mathematica и программы, которая ИМХО лучше других выполняет свою задачу и, кроме, того очень точно соответствует своему названию, хотя там не забыли и про физиков и химиков и всех остальных:)

Всего записей: 10530 | Зарегистр. 28-05-2003 | Отправлено: 16:00 01-12-2003 | Исправлено: zAlAn711, 18:21 10-01-2024
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

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

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

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

In[1]:= s = NSum[(Cos[n]/n)^2, {n, 1, Infinity}];
In[2]:= Precision[s]
Out[2]= MachinePrecision
In[3]:= Accuracy[s]
Out[3]= 16.1968

И при этом в расчётах по умолчанию 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}

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

Цитата:
popkov  

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

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

Первый ряд - это Sum[Cos[n]/n, {n, 1, Infinity}]. Он "знакопеременный", как вы сказал.
Выше же вы писали:

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

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

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 12:58 02-04-2008 | Исправлено: popkov, 13:24 02-04-2008
Alex_B



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 это только задача, над достижением которой Математика начинает работать, но это не значит, что она ее обязательно достигнет в каждом конкретном случае. По крайней мере, такие реалии на сегодняшний день.
 
Теперь о вашем втором замечании.
 

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

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

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

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

Всего записей: 1088 | Зарегистр. 10-01-2002 | Отправлено: 00:46 03-04-2008 | Исправлено: Alex_B, 01:30 03-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
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-м, к примеру, шаге на него случайно натыкается, но потом снова уходит от него далеко, и выдаёт в конечном счёте абсурдный ответ.

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 05:42 03-04-2008
yasteff

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 3 | Зарегистр. 03-04-2008 | Отправлено: 13:12 03-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
yasteff
Ответил.

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 18:27 03-04-2008
Alex_B



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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, чтобы получить точный результат.
 
Другие сообщения об ошибках Математики посмотрю позже.

Всего записей: 1088 | Зарегистр. 10-01-2002 | Отправлено: 23:09 04-04-2008 | Исправлено: Alex_B, 05:28 05-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Вот ещё парочка действительно опасных багов 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

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

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 11:32 11-04-2008 | Исправлено: popkov, 13:39 11-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

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]]

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

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 07:34 12-04-2008 | Исправлено: popkov, 09:07 12-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Приятная новость!
Теперь для того, чтобы проверить, как 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

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 12:22 13-04-2008 | Исправлено: popkov, 13:36 13-04-2008
vb2008

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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

Всего записей: 38 | Зарегистр. 28-03-2008 | Отправлено: 16:39 13-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Давайте упростим ещё дальше:
Integrate[E^(a*x), x]
ответ:
E^(a*x)/a
неверен при a=0... хоть вешайся - Mathematica не видит нулей! Это подлежащая фундаментальная недоработка, из которой растёт целый веер багов! Зная это простое правило, нетрудно найти тысячи багов, и хуже того - в более сложных случаях эта недоработка должна приводить именно к появлению совершенно непредсказуемых случайных частных решений, которые будут вводить в заблуждение пользователя! Причём именно тогда, когда ответ труднее всего проверить независимыми методами, а вручную - чрезвычайно трудоёмко!

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 20:00 13-04-2008
vb2008

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
popkov writes
 

Цитата:
Давайте упростим ещё дальше:  
Integrate[E^(a*x), x]  
ответ:  
E^(a*x)/a  
неверен при a=0

 
А вот что дает мой любимчик Derive
 
LIM(INT(EXP(a*z),z),a,0)
 
z
 
..............................................
 
LIM(INT(EXP(a*z)*SINH(z),z),a,1)
 
#e^(2*z)/4-(2*z+1)/4
 
..............................................
 
LIM(INT(EXP(z)*SINH(a*z),z),a,1)
 
#e^(2*z)/4-(2*z+1)/4
 
..............................................
 
и, на закуску,  
 
LIM(INT(COS(a*z)/SIN(z),z),a,1)
 
LN(SIN(z))

Всего записей: 38 | Зарегистр. 28-03-2008 | Отправлено: 21:27 13-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
vb2008

Цитата:
А вот что дает мой любимчик Derive  

Выходит, Derive круче! По крайней мере, в отношении интегрирования простых функций.

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 21:54 13-04-2008
mumbojumbo

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Еще хуже вот что. Даже предельный переход порождает мусор  
 
Limit[Integrate[Cos[a z]/Sin[z], z], a -> 1]  
 
Infinity  

 
Этот предел и не обязан существовать. Дело в том что неопределенный интеграл представляет собой целый класс функций, а не одну функцию. Intergrate дает лишь одного из представителей этого класса, который не обязан непрерывно зависеть от параметра. Чтобы получить правильный результат нужно переходить к пределу в определенном интеграле, например, выполнив
 
Limit[Assuming[a > 0 && z > Pi/2 && z < Pi,  
  Integrate[Cos[a t]/Sin[t], {t, Pi/2, z}]], a -> 1]
 
получим выражение эквивалентное Log[Sin[z]].
 
Почему при вычислении  
Limit[Integrate[E^(a x), x],a->0]
Derive дает x для меня загадка, ведь предел
Exp[a x]/a при a->0 не существует.

Всего записей: 345 | Зарегистр. 02-03-2004 | Отправлено: 05:34 17-04-2008 | Исправлено: mumbojumbo, 05:46 17-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
mumbojumbo

Цитата:
выполнив
 
Limit[Assuming[a > 0 && z > Pi/2 && z < Pi,  
  Integrate[Cos[a t]/Sin[t], {t, Pi/2, z}]], a -> 1]
 
получим выражение эквивалентное Log[Sin[z]].  

Что-то уж очень сложный ты пример приводишь. По-хорошему, следуя твоей логике и объяснениям Daniel Lichtblau (Wolfram Research), всё должно работать правильно при следующей записи:
Limit[Integrate[Cos[a*t]/Sin[t], {t, m, n}], a -> 1]
Однако на моём компьютере MathKernel после 23 минут работы над этой задачей отожрал 80Мб оперативки, и я его вырубил...  
Сам Daniel Lichtblau в своём последнем сообщении на comp.soft-sys.math.mathematica заметил, что этот случай является "исключением", и связан с ограничениями функции Limit[].
 
Добавлено:
Хотя при указании конкретных пределов интегрирования ответ всё же правильный:
int1 = Limit[Integrate[Cos[a*t]/Sin[t], {t, 2, 3}], a -> 1]
int2 = Integrate[Cos[t]/Sin[t], {t, 2, 3}]
N[int1 - int2, 30]

ответ:
0.*10^-76 + 0.*10^-77*I

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 12:37 17-04-2008 | Исправлено: popkov, 13:04 17-04-2008
mumbojumbo

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
popkov

Цитата:
Что-то уж очень сложный ты пример приводишь. По-хорошему, следуя твоей логике и объяснениям Daniel Lichtblau (Wolfram Research), всё должно работать правильно при следующей записи:  
Limit[Integrate[Cos[a*t]/Sin[t], {t, m, n}], a -> 1]  
Однако на моём компьютере MathKernel после 23 минут работы над этой задачей отожрал 80Мб оперативки, и я его вырубил...  

 
Правильно, должно, но  только при определенных ограничениях на интервал (m,n). Так, если внутри этого интервала лежит хоть один нуль синуса, то интеграл расходится. А если мы хотим получить ответ побыстрее, то нужно "помочь" прогамме указав как можно больше информации о параметрах. Поэтому мой пример выполняется около минуты, а не полчаса. Вообще то глупо требовать от этой, равно как и любой другой программы интеллектуальных способностей, это всего лишь инструмент и голову он никогда не заменит.
 

Всего записей: 345 | Зарегистр. 02-03-2004 | Отправлено: 07:38 18-04-2008 | Исправлено: mumbojumbo, 07:42 18-04-2008
amv



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Может кому интересно:
The Russia, Belarus, and Ukraine Mathematica Tour 2008
http://www.wolfram.com/russia2008

Всего записей: 762 | Зарегистр. 19-03-2004 | Отправлено: 20:33 23-04-2008 | Исправлено: amv, 01:59 24-04-2008
Demon251

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Люди, плиз, скажите, а можнт Математика6 выводить не только результат, но и само решение?

Всего записей: 1 | Зарегистр. 28-04-2008 | Отправлено: 20:32 28-04-2008
Cheery



.:МордератоР:.
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Demon251

Цитата:
но и само решение?

нет
http://www.wolfram.com/products/student/mathforstudents/qa.html

Цитата:
I'm searching for a program that will show step by step how my equations are solved. Does Mathematica for Students have this capability?
Unfortunately, Mathematica will not provide step-by-step explanations for your solutions. However, a program could be written in Mathematica's high-level programming language to provide this feature.
 
Calculus WIZ, an interactive homework helper based on the most widely used calculus textbooks, will show you the steps for each calculus problem. Calculus WIZ is for use with Mathematica for Students and can be purchased at your local campus bookstore or directly from Wolfram Research.  


----------
Away/DND

Всего записей: 52737 | Зарегистр. 04-04-2002 | Отправлено: 20:38 28-04-2008
popkov

Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Comparison of mathematical programs for data analysis

Всего записей: 1833 | Зарегистр. 22-03-2003 | Отправлено: 09:07 04-05-2008
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Компьютерный форум Ru.Board » Компьютеры » Программы » Wolfram Mathematica | Математика


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru