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

Pavel80
это не глюк.
от -1 до 1 корень с отрицательного числа - комплексный
Plot[Re[x/(x^2 - 1)^(1/3)], {x, -10, 10}]

terminat0r

Цитата:

от -1 до 1 корень с отрицательного числа - комплексный
Plot[Re[x/(x^2 - 1)^(1/3)], {x, -10, 10}]

Какой комплексный? Корень третьей степени?

Pavel80
Это так нормальным и является.
Как сделать его в Mathematica не знаю, а вот в Maple делается так:

Код:
plot(x/surd(x^2-1,3),x = -10 .. 10)

Pavel80
Можно легко обойти проблему, определив свою собственную функцию кубического корня, которая для действительных чисел всегда возвращает действительное значение:

realCubicRoot[expr_?(Element[#, Reals] &)] := (Sign[expr]*Power[Abs[expr], 1/3])
Plot[x/realCubicRoot[x^2 - 1], {x, -10, 10}]

Однако в этом случае функция оказывается разрывной...

[удалено]

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

Pavel80

Цитата:

я разочаровался.(((

Рано разочаровываетесь! Я прошел куда более длиный путь, чтобы разочароваться. Главная проблема - фактическое отсутствие спецификации для всех встроенных функций! Они ведут себя непредсказуемо именно в результате политики документирования.

Pavel80

Цитата:

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

В данном случае нет оснований для разочарования - результат достоверный.

popkov

Цитата:

Однако в этом случае функция оказывается разрывной...

Функция на самом деле разрывной и является. У Maple не получается разрывной, но думаю это какой то недостаток графической системой.

Pavel80
Все системы, которые понимают комплексные числа сделают то же.
Например есть такие программы как GraphCalc, которые больше подходят для несложных графиков.

popkov

Цитата:

Главная проблема - фактическое отсутствие спецификации для всех встроенных функций! Они ведут себя непредсказуемо

Любопытно. Видимо вы это уже много раз здесь демонстрировали. Не могли бы вы еще раз привести наиболее поучительный пример?

Alex_B
Например, вышеупомянутая на данной странице функция [no]Power[][/no], которая при извлечении корня нечетной степени из отрицательного числа возвращает т.н. "principal root" (термин, отчетливого определения которого я так и не нашел. К примеру, для квадратного корня на том же сайте подчеркивается произвольность определения этого понятия, как и на Википедии). Да, в разделе EXAMPLES/Possible Issues  (13) это упоминается в 7-ке (хотя в 5-ке, к примеру, и вовсе нет этой информации). Но примеры работы - не спецификация! Замечание "For complex numbers x and y, Power gives the principal value of e^(y log (x))." относится к комплексным числам, а не к отрицательным. Можно, конечно, утверждать, что действительные числа - подмножество комплексных, но это скорее демагогия, поскольку в Mathematica это совершенно разные объекты. См., напр., на стр. ref/Complex: "Complex is the head used for complex numbers.", что опровергает предположение, что разработчики имели в виду под комплексными числами также и действительные.

Собственно, документация к Mathematica даже и не претендует на то, что в ней содержится спецификация встроенных функций: в ней, кроме краткого описания вверху страницы, есть только разделы "MORE INFORMATION" и "EXAMPLES". Уже названия этих разделов намекают, что часть важной информации просто скрывается...

Кстати, рекомендую интересный анализ работы функции Plot[] в версиях MMa >=6:

http://stackoverflow.com/questions/4572183/strange-sinx-graph-in-mathematica/4572266#4572266

Для меня лично этот анализ был открытием. Похоже, в 5-й версии был более умный Plot[].

Серьезный баг в функции Clip[] (проверил в версиях 5.2 и 7.0.1):

In[1]:=
Clip[1.00000000000000036, {0., 1.}]
Clip[1.00000000000000036, {0, 1}]
Clip[1.00000000000000036`17, {0, 1}]

Out[1]=
1.0000000000000004

Out[2]=
1.0000000000000004

Out[3]=
1.0000000000000004

Привет.
Может кто-нибудь внятно объяснить, почему это не работает (M8):

Код:
n = 3; incx = 2; incy = 1;
x = {2., 2., 2.};
y = {1., 1., 1.};

FindLibrary[ "c:\\mkl_core.dll"];
fun = LibraryFunctionLoad["c:\\mkl_core.dll",
"mkl_blas_sdot", {Integer, {Real, 1, "Shared"},
Integer, {Real, 1, "Shared"}, Integer}, Real];

res = fun[n, x, incx, y, incy]

eriik
Работа с внешними библиотеками в нестандарнтых случаях похожа на шаманство. Думаю, лучше задать этот вопрос разработчику (навернаяка это Todd Gayley tgayley<-"at"->wolfram.com - разработчик NetLink и MathLink, вполне адекватный человек). Только стоит, вероятно, поподробнее рассказать о "c:\\mkl_core.dll" и определенной в ней функции. А потом расскажите нам, если откроется что-то полезное...

Добавлено:
eriik
На всякий случай задам стандартный вопрос №1: а вызвать
Needs["NETLink`"]
перед упомянутым куском кода Вы не забыли?

popkov,
M8

In[5]:= Clip[1.00000000000000036, {0., 1.}]
Clip[1.00000000000000036, {0, 1}]
Clip[1.00000000000000036`17, {0, 1}]

Out[5]= 1.

Out[6]= 1

Out[7]= 1

eriik
насколько я понимаю, оно и не должно работать. математика не может вызывать с пом. LibraryLink любую библиотеку а только специально написанную под математику
смотрите примеры в SystemFiles/Links/LibraryLink/LibraryResources/Source

popkov
Похоже в Mathematica 8 этот баг исправили.

Зато появился новый багофич. Была у меня функция — ещё с 5.2 — типа f[x_]:=FindRoof[NIntegrate[...x, y...]+NIntegrate[...x, y...]==0, {y, 0, 500}]. Работала себе и работала (проверено аналитически), до m8. Сейчас всегда выдаёт в качестве решения y=500, и никакие настройки или изменение этого предела не помогают. Сижу пока, разбирвюсь.

TomasVercetti
karl_karlsson
У вас 64-битня система или 32-битная?

popkov,
64.

TomasVercetti

Цитата:

Зато появился новый багофич. Была у меня функция — ещё с 5.2 — типа f[x_]:=FindRoof[NIntegrate[...x, y...]+NIntegrate[...x, y...]==0, {y, 0, 500}]. Работала себе и работала (проверено аналитически), до m8.

Обязательно напишите о результатах исследования! Весьма подозреваю, что проблема, как обычно, в "symbolic preprocessing" числовых функций. Искусственное отключение его может помочь, хотя и снизит скорость. Также можно поэкспериментировать с Compile[]. Удачи!

Добавлено:
TomasVercetti

Цитата:

64

Пока еще не было сообщений, что под 32-битной 8-кой проблема не воспроизводится. Вполне возможно, что она "исправлена" лишь под 64-битными системами.

popkov,
Спасибо за советы! Обязательно отпишусь

Добавлено
Отписываюсь. До конца не выяснил, что и в каком месте перестало или, наоборот, стало работать, но «решение» найдено: пометить все аргументы как численные — f[x_?NumericQ, p1_?NumericQ, p2_?NumericQ,...].

Добавлено
В 5-7 версиях вложенные функции типа FindRoot[NIntegrate[]] могли выдавать ошибки (а могли и нет) типа NIntegrate::inumr, которые связаны с тем, что внутренняя функция рассчитвается (Evaluate) в первый раз перед расчётом внешней. Т.е., с символьными аргументами, так как численные значения внешней функции ещё не подставлены (нормальный порядок расчёта) При этом всё рассчитывалось нормально. В 8й версии при наличии таких ошибок FindRoot работает некорректно в принципе (ещё одно сообщение).

Полное «решение» проблемы — позволить внутренней (и, для вызова из других функций, внешней) функции быть рассчитываемой только с численными значениями. Например, InternalF[x_?NumericQ, y_?NumericQ]:=NIntegrate[x y z, {z,0,1}], WrappingF[x_?NumericQ]:=FindRoot[InternalF[x,y],{y,0,1}].

popkov
У меня система 32-битная.
Воспроизводится на 5 и 7, а вот на 8 уже нет.

Баг в Clip[] в 8-ке воспроизводится, если добавить немного нулей:

Цитата:

Hi,

the bug seems to be handled in v8.0:

In[1]:= Clip[1.00000000000000036, {0., 1.}]

Out[1]= 1.

But comes back if I add one more zero before 36:

In[2]:= Clip[1.000000000000000036, {0., 1.}]

Out[2]= 1.00000000000000004

Однако Leonid Shifrin считает, что такое поведение корректно:

Цитата:

This behavior is correct, and there is nothing to warn about. You use
machine-precision arithmetic,
and your result is within machine epsilon of 1:

In[1]:=Chop[Clip[1.00000000000000036,{0,1}]-1]

Out[1] = 0

If you want exact result, you need fixed higher precision, and exact bounds
in Clip, such as:

In[2]:= Clip[N[1+36*10^(-17),20],{0,1}]

Out[2]= 1


Regards,
Leonid

Мне, тем не менее, кажется, что случаи вроде

In[6]:= Clip[1.00000000000000003`18, {0, 1}]

Out[6]= 1.00000000000000003

оправдания не имеют...

В принципе, в хелпе написано "For exact numeric quantities, Clip internally uses numerical approximations to establish its result. This process can be affected by the setting of the global variable $MaxExtraPrecision." Так что такое поведение ожидаемо. То, что функцию можно (наверное, можно) написать иначе — более «гибкой» — вопрос уже другой... Имхо.

TomasVercetti
Вот именно, что "в принципе". Из этой фразы никак не следует, что готовое число с указанием его точности должно по неясной причине рассматриваться как имеющее значительно меньшую точность. И это я лишь очень-очень мягко характеризую очевидное надувательство!

Правда, глюк глубже, на самом деле:

In[19]:=
1.00000000000000003`18 == 1
1.00000000000000003`18 - 1 == 0
0.00000000000000003`18 == 0

Out[19]= True

Out[20]= False

Out[21]= False

Может кто-нибудь это объяснить?

popkov,
Это уже тоже следствия и особенность Equal. Причина в этом:

N[1.00000000000000003`18] (*Precision=MachinePrecision*)
N[0.00000000000000003`18]
1.
3.*10^-17

$MachinePrecision
15.9546
$MachineEpsilon
2.22045*10^-16
$MachineEpsilon == 2/10^MachinePrecision
True

N[1.00000000000000003`18, 18]
N[0.00000000000000003`18, 18]
1.00000000000000003
3.00000000000000000*10^-17

Отсюда же сразу видно, что машина хранит второе число в другом виде — теперь мантисса равна тройке, а «аккуратность» числа значительно выше:
Precision[N[1.00000000000000003`18, 18]]
Precision[N[0.00000000000000003`18, 18]]
Accuracy[N[1.00000000000000003`18, 18]]
Accuracy[N[0.00000000000000003`18, 18]]
18.
18.
18.
34.5229

Так как «точный» 0 представляется как-то специально (в машинном float в смещенный порядок записываются нули, в математике, по-моему, также), то сразу видна разница даже Equal'у. Он сравнивает числа следующим образом: "Approximate numbers with machine precision or higher are considered equal if they differ in at most their last seven binary digits (roughly their last two decimal digits)."

А вот то, что это нельзя контролировать и не написано, как поступать в таких случаях — это явный минус. (Видимо, можно притянуть RealDigits для сравнения «содержимого» чисел.)

С Clip'ом всё решается следующим образом:
Clip[1.000000000000000036, {0, 1}]
1.00000000000000004
Clip[1.000000000000000036, {0.`18, 1.`18}]
1.00000000000000000
Так как Clip (в соответствии с хелпом) переводит целые в реальные с по умолчанию машинной точностью. Так что следует.

Я как-то так понимаю.

TomasVercetti

Цитата:

С Clip'ом всё решается следующим образом:
Clip[1.000000000000000036, {0, 1}]
1.00000000000000004
Clip[1.000000000000000036, {0.`18, 1.`18}]
1.00000000000000000
Так как Clip (в соответствии с хелпом) переводит целые в реальные с по умолчанию машинной точностью. Так что следует.

У меня не решается:

In[18]:= Clip[1.000000000000000036, {0, 1}]
Clip[1.000000000000000036, {0.`18, 1.`18}]
Clip[1.000000000000000036`18, {0.`18, 1.`18}]
Clip[1.000000000000000036, {0.`20, 1.`20}]

Out[18]= 1.00000000000000004

Out[19]= 1.00000000000000004

Out[20]= 1.00000000000000004

Out[21]= 1.00000000000000004

popkov,

Интересно.

In[108]:= TestClip2[x_, {xmin_, xmax_}] := Module[{},
{x, xmin, xmax, x > xmax}
]

In[109]:= TestClip2[1.000000000000000036, {0., 1.}]
TestClip2[1.000000000000000036`18, {0.`18, 1.`18}]
TestClip2[1.000000000000000036, {0.`19, 1.`19}]
TestClip2[1.000000000000000036`19, {0., 1.}]
TestClip2[1.000000000000000036`19, {0.`19, 1.`19}]

Out[109]= {1.00000000000000004, 0., 1., False}
Out[110]= {1.00000000000000004, 0., 1.00000000000000000, False}
Out[111]= {1.00000000000000004, 0., 1.000000000000000000, False}
Out[112]= {1.000000000000000036, 0., 1., False}
Out[113]= {1.000000000000000036, 0., 1.000000000000000000, True}

А последний вариант у вас с Clip работает?