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

Griefin

Цитата:

В общем случае, при p = q + 1 ряд сходится только при abs(z) < 1, за исключением неких частных значений параметров.

Аналитическое продолжение ряда - как "некое частное значение параметров"? - интересная математика...
А аналитическое продолжение при p = q + 1 и |z| >=1 можно получить, например, с помощью интеграла Меллина-Барнса.
(ИМХО не есть гут править пост, на который уже ответили)

Так написано в справочнике. Также приведены формулы для этих частных значений. При чем тут аналитическое продолжение? Если оно возможно, то флаг вам в руки, пишите.

Igorr

Цитата:

А аналитическое продолжение при p = q + 1 и |z| >=1 можно получить,

да, это я тоже припоминаю. Справочник Градштейна и Рыжика.
Igorr

Цитата:

Если по приведенным мной ссылкам, то он много случаев не считает, например, при ((p>q && abs(z)>1) && p > 2),

именно. Но его очень просто модифицировать именно для таких случаев с помощью формул с упомянутого справочника.

Интересный глюк 7-й Mathematica, превращающий её буквально в настоящий random bug generator!
Попробуйте выполнить несколько раз следующий код, и сами в этом убедитесь:

myMod := Module[{p}, Dot[
{0.5018839897852984567457648, 0.544293499215831476457645674576, 0.67220312964800834576456745674567},
{-0.5359693986690249`, -0.41257352636613975`, -0.736559494563862`}
]*{-0.5359693986690249`, -0.41257352636613975`, -0.736559494563862`} - {0.5579131132707782`, 0.2715072333003815`, 0.7842300557273234`}]

For[ii = 1, ii <= 250, ii++,
If[myMod =!= myMod,
Print["Iteration " <> ToString[ii] <> " fails comparison "]];]

В операторе сравнения функция myMod вызывается 2 раза, и результаты её выполнения сравниваются. Они должны бы быть строго одинаковы, однако совершенно непредсказуемым образом оказываются вдруг разными. Самый настоящий генератор случайных багов!
Глюк критически зависит от присутствия в Module[] неиспользуемой локальной переменной и присутствует, видимо, только в 32-битных системах (подтверждено для 32-bit Windows XP и 32-bit MacOS, в 64-bit'ных системах вроде не наблюдается).

popkov
Баг-то есть, но сам код какой-то неграмотный. Зачем делать p локальной переменной, если она вообще в функции не используется? Плохо другое: я иногда вижу, что в Mathematica внешне правильный код приводит к неправильному результату. Если перенабрать то же самое заново, то все приходит в порядок.

Цитата:

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

В некоторых случаях, вероятно, может помочь удаление форматирования: выделить ячейку и Format :: Clear Formatting (в Mathematica 6 и 7) или Format :: Remove Options :: Recursively (в Mathematica 5).

Griefin
Только что получил письмо от некоего Marcelo Ribeiro с интересными примерами как раз "внешне правильного кода". Попробуй следующее:

Создай новую ячейку в ноутбуке, выдели её, нажми Ctrl+Shift+E и вставь туда следующее:
Цитата:

[no]Cell[BoxData[
RowBox[{
RowBox[{"451", "/", "24"}], " ",
FormBox[
RowBox[{"-",
FractionBox["185", "24"]}],
TraditionalForm]}]], "Input"][/no]

Теперь снова нажми Ctrl+Shift+E. Содержимое ячейки отображается как разность между 451/24 и 185/24. Однако её выполнение приводит к ответу -83435/576, что явный абсурд.

Andrzej Kozlowski прокомментировал это следующим образом:
Цитата:

If I copy your input, enclose it in Hold and convert to InputForm I get

Hold[451/24 -(185/24)]//InputForm
Hold[(451/24)*(-(185/24))]

In words, there is actually multiplication hidden in your input, and when I simply type in the correct in my Mathematica everything works fine:

In[37]:= 451/24-185/24
Out[37]= 133/12

I have no idea how you managed to produce these strange inputs, perhaps you copied them from Mathematica 2?

Добавлено:
Я даже решил выложить оба письма в общий доступ (предварительно удалив из них все E-Mail), поскольку они могут прояснять некоторые вещи:
Письмо Marcelo Ribeiro
Ответ Andrzej Kozlowski

popkov
Я тоже подозревал, что дело в скрытых умножениях и пробовал редактировать сложные куски кода в текстовом редакторе, чтобы избегать подобных ошибок. Есть ли во frontend возможность разрешить умножение, только если явно указан знак *, отредактировав какие-то свойства ячейки?

Griefin

Цитата:

Есть ли во frontend возможность разрешить умножение, только если явно указан знак *, отредактировав какие-то свойства ячейки?

Как я догадываюсь, можно в Option Inspector указать другой вид новой ячейки по умолчанию. Например, InputForm.
Возможно также, что это делается перенастройкой стилей самого ноутбука по умолчанию: открой Default.nb, и там в соответствующем подразделе выдели ячейку, нажми Ctrl+Shift+E, и редактируй опции. Возможно, именно этот путь наиболее верный.

Если не получится, можно ещё задать этот вопрос в группе новостей.

За тип ячейки ввода отвечает опция (Global Preferences): "Input" (CommonDefaultFormatTypes). Её значение по умолчнию StandardForm. Однако и в InputForm всё равно пробел рассматривается как знак умножения. Ещё интересная опция "InputInline" (CommonDefaultFormatTypes). Её значение по умолчанию также StandardForm. Однако если установить его в InputForm, то знак пробела автоматически превращается в крестик: x. Это мне очень понравилось, так что оставлю это поведение по умолчанию. За стиль новой ячейки отвечает опция DefaultNewCellStyle со значением "Input" по умолчанию. Есть ещё опция DefaultNewInlineCellStyle со значением {} по умолчанию.

Есть ещё функция CellEventActions. С её помощью можно, например, создать ячейку, которая будет автоматически конвертироваться в InputForm при клике по ней, нажатии определённой комбинации клавиш, выполнении и т.п. Или же InputForm этой ячейки можно поместить в Tooltip к ней же... В общем простор для фантазии.

Но прямого пути сделать то, что ты хочешь, я не нашёл.

Интересные опции также нарыл:
DefaultNotebook: "DefaultTemplate.nb"
DefaultStyleDefinitions: "Default.nb"
PrintPrecision: по умолчанию значение 6 (видимо, точность позиционирования векторных объектов 6 значащих цифр)
"PrintingMargins" (PrintingOptions): по умолчанию значение {{54,54},{72,72}} - это в типографских точках (printer's points, pt): 1 pt = 127/360 mm
"RasterizationResolution" (PrintingOptions): по умолчанию значение "Automatic"
"ScreenResolution" (FontProperties): 72 (я выставил в 96, и шрифт в ноутбуке стал крупнее и немного более гладким)
EmphasizeSyntaxErrors: False

popkov
Спасибо. Приму к сведению.

Кстати, полезно почитать следующий раздел справки:
tutorial/StructuralElementsAndKeyboardCharacters
Оказывается, существует даже невидимый пробел, который также интерпретируется как знак умножения: \[InvisibleSpace], уж не говоря о множестве форм пробела, включая \[NegativeVeryThinSpace].

Цитата:

Баг-то есть, но сам код какой-то неграмотный.

Сегодня глюк удалось обнаружить уже и для абсолютно правильного кода. Это сделал
Daniel Lichtblau (Wolfram Research), за что ему Respect!

Попробуй следующее):

[more]In[1]:= myMod5 := Dot[{0.50188398978529847, 0.54429349921583148,
0.67220312964800832}, {-0.53596939866902493, -0.41257352636613975, \
-0.73655949456386205}]

In[2]:= InputForm[myMod5]

Out[2]//InputForm=
-0.9886731459742619

In[3]:= InputForm[myMod5]

Out[3]//InputForm=
-0.9886731459742619

In[4]:= InputForm[myMod5]

Out[4]//InputForm=
-0.988673145974262

In[5]:= InputForm[myMod5]

Out[5]//InputForm=
-0.9886731459742619

In[6]:= InputForm[myMod5]

Out[6]//InputForm=
-0.9886731459742619

In[7]:= InputForm[myMod5]

Out[7]//InputForm=
-0.9886731459742619

In[8]:= InputForm[myMod5]

Out[8]//InputForm=
-0.988673145974262

In[9]:= InputForm[myMod5]

Out[9]//InputForm=
-0.988673145974262

In[10]:= InputForm[myMod5]

Out[10]//InputForm=
-0.988673145974262

In[11]:= InputForm[myMod5]

Out[11]//InputForm=
-0.988673145974262

In[12]:= InputForm[myMod5]

Out[12]//InputForm=
-0.988673145974262[/more]

Обрати внимание, что два варианта ответа случайным образом чередуются друг с другом...

Еще я несколько разочарован в функции ParallelTable из 7-ки. Мне казалось, что она разрезает список на части, каждую из них отдает на исполнение отдельному ядру и потом склеивает. А на деле -- ничего подобного. Если в аргументе стоит нетривиальная функция, все тупо вертится на одном ядре.

Griefin writes:


Цитата:

Еще я несколько разочарован в функции ParallelTable из 7-ки.

Ваше разочарование было бы намного глубже, если бы Вы попробовали, к примеру, 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: +380-953-866-894
fax: +380-652-668-356

3/4 Zadorozhny Str, Simferopol
Crimea 95047, Ukraine

vb2008

Цитата:

то ли построить нечто типа Mathematica Bugs Encyclopaedia - обновляемой в реальном масштабе времени...

Наверное, уже пора!

Больше всего меня убило то, что лишь совсем недавно разработчики раскрыли "страшную тайну" Mathematica: как отключить добавление совершенно ненужных белых полей в Graphics[] и Graphics3D[]! Оказывается для этого существует недокументированная опция Method->{"ShrinkWrap"->True}, которая решает столь тривиальную и (по-хорошему, само собой разумеющуюся и необходимую как поведение по-умолчанию) "задачу"!
... и раскрыли они её лишь после того, как появилась функция ImageCrop[], которая эти поля умеет удалять - но по-умолчанию делает это идиотским способом (из-за недокументированного поведения функции Graphics[], см. подробности здесь), сильно снижая качество исходного изображения.

По-хорошему, из ценного в Mathematica 7 добавлена только функция Image[], которая ведёт себя именно так, как (по всей логике вещей) должна была бы с самого начала вести себя функция Graphics[]: то есть отображать растровую графику наиболее подходящим способом (масштабируя её в зависимости от контекста и размера окна, в котором отображается данный Notebook), но экспортировать её, ясное дело (для всех, кроме Wolfram Research!) полностью, без искажений и снижения качества! Однако функция Image[] при преобразовании Graphics[] в свой формат всегда создаёт изображение именно столь сниженного качества, как функция Graphics[] всегда создавала по-умолчанию! Издевательство этого умолчания (= замалчивания!) не лезет ни в какие ворота. Но до сих пор это было "нормой", с которой никто не спорил, поскольку в Mathematica не было даже функций для проверки адекватности поведения (таких, как ImageDimensions[] и ImageData[], которые есть ни что иное как простое преобразование посредством старых функций FullForm[Image[data]]). Теперь, когда Wolfram Research наконец-то добавило функции обработки изображений, появилась возможность средствами Mathematica оценить качество работы графических функций. И результаты потрясают: уже очень давно функция Graphics[] откровенно издевалась над всеми пользователями Mathematica, портя генерируемую ими растровую (и векторную во многих случаях) графику! Уже тех примеров, что приведены в этой теме, достаточно.

The year of Cyber Tester

http://groups.google.com/group/sci.math.symbolic/msg/73e2b812ef378e86

vb2008
Спасибо. Вы действительно планируете сделать сайт Mathematica Bugs Encyclopaedia, аналогичный уже имеющемуся для Maple? Wolfram Research вряд ли сподобится на исправление ошибок, и людям все-таки лучше знать о них. Только лучше без бегущей строки и фреймов с фиксированными размерами. В современном веб-дизайне это моветон, да и в самом деле не очень удобно.

"vb2008
Спасибо. Вы действительно планируете сделать сайт Mathematica Bugs Encyclopaedia, аналогичный уже имеющемуся для Maple?"

Для Mathematica 7 мы рассчитали автоматически (без участия человека в процессе
вычислений) тысячи разных багов в наиболее востребованных функциях, таких как Limit, Integrate, NIntegrate, Solve, DSolve, LaplaceTransform, FourierTransform,
InverseLaplaceTransform, InverseLaplaceFourierTransform etc

Этот материал существует в некоторой сыроватой форме в нашем внутреннем представлении. В принципе, по объему это уже вроде бы тянет на Mathematica Bugs Encyclopaedia?

Конечно, никто не мешает нам пополнять такую энциклопедию в реальном масштабе времени новыми багами в Mathematica 7, идентифицированными the VM machine.

Кроме того, можно значительно расширить набор тестируемых функций. Скажем, взять не 10 самых используемых функций, а 100 или 500, может и 1000.

"Wolfram Research вряд ли сподобится на исправление ошибок"

Я начал активно использовать Mathematica 2.2 в 1996. Затем были многочисленные Mathematica 3, 4, 5, 6. Недавно мы купили Mathematica 7.

Каков же общий вывод?

Увы, в целом, несмотря на многие тысячи багфиксов от WRI, похоже, с годами, багов в Mathematica становится все больше.

Мы прикидываем, не пообщаться ли Cyber Tester Ltd. с Wolfram Research Inc. на тему совместных усилий в плане улучшения качества Mathematica?

В частности, мы могли бы им предоставить наши высокопроизводительные QA сервисы, но не только...

Конечно, все вышесказанное применимо и для Maple/MATLAB.

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

То есть, что вообще, по мелкому и крупному калибру можно сделать для улучшения Mathematica?

("Wolfram Research вряд ли сподобится на исправление ошибок"

Идет мужчина по лесу, вышел на полянку. Там стоит бабка с ружьем. Она ему: “Ты чего, милок, небось меня изнасиловать хочешь? “Что вы, бабушка, как можно, даже в мыслях не было...” Бабка, поднимая ружье: “А ведь придется, придется!!”



Best,

Vladimir Bondarenko
CEO, Mathematical Director


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

phone: +380-953-866-894
fax: +380-652-668-356

3/4 Zadorozhny Str, Simferopol
Crimea 95047, Ukraine

Чтобы при установленной версии 7 .nb открывались в версии 5.2, надо не только ассоциировать .nb со старой версией, но ещё в реестре добавить недокументированный ключ командной строки -directlaunch в качестве первой опции вызова FrontEnd.

Вот примеры .reg-файлов для переключения файловых ассоциаций между установленными в директории по умолчанию версиями 5.2 и 7.0:

[more=Переключение на версию 5.2][no]REGEDIT4

[HKEY_CLASSES_ROOT\.ma]
@="MathematicaMA"

[HKEY_CLASSES_ROOT\.nb]
@="MathematicaNB"

[HKEY_CLASSES_ROOT\MathematicaNB]
@="Mathematica 5.2 for Students Notebook"
"EditFlags"=dword:00000000
"BrowserFlags"=dword:00000008

[HKEY_CLASSES_ROOT\MathematicaNB\DefaultIcon]
@="\"C:\\Program Files\\Wolfram Research\\Mathematica\\5.2\\Mathematica.exe\",-102"

[HKEY_CLASSES_ROOT\MathematicaNB\shell]
@="open"

[HKEY_CLASSES_ROOT\MathematicaNB\shell\open]
@="Open with Mathematica 5.2"

;Здесь ключевая фишка - недокументированный параметр -directlaunch.
;http://groups.google.ru/group/comp.soft-sys.math.mathematica/browse_frm/thread/99d3c9176b70aa8f#
[HKEY_CLASSES_ROOT\MathematicaNB\shell\open\command]
@="\"C:\\Program Files\\Wolfram Research\\Mathematica\\5.2\\Mathematica.exe\" -directlaunch \"%1\""

[-HKEY_CLASSES_ROOT\MathematicaNB\shell\print][/no][/more]
[more=Переключение на версию 7.0.0][no]REGEDIT4

[HKEY_CLASSES_ROOT\.m]
@="Mathematica.M.7.0.0.1148351"

[HKEY_CLASSES_ROOT\.ma]
@="Mathematica.MA.7.0.0.1148351"

[HKEY_CLASSES_ROOT\.nb]
@="Mathematica.NB.7.0.0.1148351"

[HKEY_CLASSES_ROOT\.nbp]
@="Mathematica.NBP.7.0.0.1148351"

[/no][/more]

Сия страшная тайна была раскрыта только на этой неделе.

P.S. Для того, чтобы одновременно установленные разные версии Mathematica использовали независимые настройки (а не хранили настройки в одном общем файле, как происходит по умолчанию), нужно в старшей версии Mathematica в Options Inspector выставить параметр VersionedPreferences в True. При этом настройки младших версий будут сброшены (источник).

Скажите, пожалуйста, а какая практика есть для решения уравнений следующего типа: NIntegrate[ f(x, y), {x, a, b} ] == 1 относительно y? Интеграл аналитически не берётся. Если решать как FindRoot[ NIntegrate[ f(x, y), {x, a, b} ] == 1, {y, ...} ], то часто получаются неправильные значения.

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

shefyla
Используй команду
[no]On[][/no]
Только пользы от неё, на самом деле, не много: внутренняя логика систем символьной математики мало похожа на человеческие методы решения. Есть ещё платный пакет, который делает эту логику похожей на человеческую. Но я его в доступном виде не встречал.

..спасибо.... действительно пользы мало

А можно как-нибудь сделать, чтобы в If [expr, true, false] в качестве true/false выполнялось не одно действие, а несколько?

TomasVercetti

Цитата:

А можно как-нибудь сделать, чтобы в If [expr, true, false] в качестве true/false выполнялось не одно действие, а несколько?

Само собой - просто перечисляешь через точку с запятой команды и всё! Или можно задать процедуру и вызывать её из If[].

popkov,
Вот спасибо - снова выручили! А я и скобочки попробовал, и точку с запятой, но не в том месте В help'е для If это не написано - если не секрет, где вы про это прочитали?

TomasVercetti

Цитата:

где вы про это прочитали?

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

А как в математике наиболее правильно сделать функции локальными? То есть, в одном Notebook'е есть функция, которая использует другие функции, определённые в нём же. Желательно, чтобы после evaluation'а только конечная функция стала глобальной, а имена остальных остались бы (глобально) свободными. Использовать context'ы? Или можно определять функции локально, как переменные - в Module?