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

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в 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 | Цитировать | Сообщить модератору
TomasVercetti
karl_karlsson
У вас 64-битня система или 32-битная?
Всего записей: 1834 | Зарегистр. 22-03-2003 | Отправлено: 15:02 08-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
popkov,
64.
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 15:07 08-01-2011
popkov

Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
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-битными системами.
Всего записей: 1834 | Зарегистр. 22-03-2003 | Отправлено: 15:09 08-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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}].
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 15:19 08-01-2011 | Исправлено: TomasVercetti, 23:43 08-01-2011
karl_karlsson



Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
popkov
У меня система 32-битная.
Воспроизводится на 5 и 7, а вот на 8 уже нет.
Всего записей: 2027 | Зарегистр. 14-03-2007 | Отправлено: 16:56 08-01-2011
popkov

Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Баг в 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
 
оправдания не имеют...
Всего записей: 1834 | Зарегистр. 22-03-2003 | Отправлено: 11:35 09-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В принципе, в хелпе написано "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." Так что такое поведение ожидаемо. То, что функцию можно (наверное, можно) написать иначе — более «гибкой» — вопрос уже другой... Имхо.
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 14:17 09-01-2011 | Исправлено: TomasVercetti, 14:17 09-01-2011
popkov

Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
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
 
Может кто-нибудь это объяснить?
Всего записей: 1834 | Зарегистр. 22-03-2003 | Отправлено: 15:45 09-01-2011 | Исправлено: popkov, 17:35 09-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 (в соответствии с хелпом) переводит целые в реальные с по умолчанию машинной точностью. Так что следует.
 
Я как-то так понимаю.
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 19:12 09-01-2011 | Исправлено: TomasVercetti, 21:52 09-01-2011
popkov

Advanced Member		Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
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
 
Всего записей: 1834 | Зарегистр. 22-03-2003 | Отправлено: 11:10 10-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 работает?
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 13:57 10-01-2011 | Исправлено: TomasVercetti, 13:59 10-01-2011
r_green



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

Цитата:
In[19]:=  
1.00000000000000003`18 == 1
1.00000000000000003`18 - 1 == 0
0.00000000000000003`18 == 0
 
Out[19]= True
 
Out[20]= False
 
Out[21]= False
 
Может кто-нибудь это объяснить?

 
Это поведение чётко документировано:

Цитата:
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).  
 
For numbers below machine precision the required tolerance is reduced in proportion to the precision of the numbers.

 
В случае

Код:
 
In[1]:= 1.00000000000000003`18 == 1
 
Out[1]= True
 

последняя цифра (3) находится вне диапазона, который рассматривается Equal[] (т.е. вписывается в last seven binary digits).
 
А в случае

Код:
 
In[2]:= 0.00000000000000003`18 == 0
 
Out[2]= False
 

за счёт убирания первой единицы эта 3-ка становится первой цифрой мантиссы и, конечно, становится значимой для Equal[] при заданной точности.
Даже:

Код:
 
In[3]:= 0.00000000000000003`1 == 0
 
Out[3]= False
 

 
 
 
Всего записей: 145 | Зарегистр. 17-09-2004 | Отправлено: 14:32 10-01-2011
karl_karlsson



Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
r_green
Проблема в том, что Precision в нуля не определен. У него там деление на ноль получается.

Цитата:
Precision is not defined at zero, so use Accuracy as a goal.

 
2All
Подробнее...
Всего записей: 2027 | Зарегистр. 14-03-2007 | Отправлено: 16:52 10-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
karl_karlsson,
«Table evaluates its arguments in a nonstandard way.» А вы нигде не встречали, что это за «nonstandard way» (для сравнения чисел)? Как я понимаю, сам код Table в бинарном mx, поэтому не посмотреть.
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 18:00 10-01-2011 | Исправлено: TomasVercetti, 18:02 10-01-2011
r_green



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

Цитата:
Table evaluates its arguments in a nonstandard way.  

Дело в том, что представление действительного числа (x.y`p``a) не является структурным выражением. Т.е. нельзя в качестве элементов этого представления (в частности, precision) использовать вычислимые объекты (переменные), а также использовать эти элементы для pattern matching.  
Так, запись a.b есть не действительное число с целой частью а и дробной b, а Dot[a,b] (т.е. скалярное произведение).
Также, запись 1.00000000000000003`n интерпретируется, как  
1.00000000000000003` * n или 1.00000000000000003`$MachinePrecision * n.
Из-за этого Table[] и даёт такой результат в Вашем примере.
 
Для получения ожидаемого результата нужно так:
Table[SetPrecision[1.00000000000000003, n] == 1, {n, 1, 23}]
Всего записей: 145 | Зарегистр. 17-09-2004 | Отправлено: 18:40 10-01-2011 | Исправлено: r_green, 18:45 10-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
2 All,
А можно ли тогда реализовать функцию, сравнивающую 2 числа так, что если точность(?) одного меньше, то она повышается?
 
Пример:
 
In[5]:= CompareWithA[a_, b_] := {a > b, a == b};
CompareWithA[1.000000000000000036, 1.]
Out[6]= {False, True}
 
In[9]:= SetPrecision[1.000000000000000036, 19] > SetPrecision[1., 19]
SetPrecision[1.000000000000000036, 19] == SetPrecision[1., 19]
Out[9]= True
Out[10]= False
 
Но
 
In[13]:= CompareWithA2[a_, b_] := Module[{}, SetPrecision[a, 19]; SetPrecision[b, 19];
   {a > b, a == b}];
CompareWithA2[1.000000000000000036, 1.]
Out[14]= {False, True}
 
Добавлено:
Можно
In[13]:= CompareWithA3[a_, b_] := Module[{},
    {SetPrecision[a, Precision[a] + 1] > SetPrecision[b, Precision[a] + 1],  
    SetPrecision[a, Precision[a] + 1] == SetPrecision[b, Precision[a] + 1]}];
CompareWithA3[1.000000000000000036, 1.]
Out[14]= {True, False}
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 18:54 10-01-2011 | Исправлено: TomasVercetti, 19:26 10-01-2011
r_green



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

Цитата:
А можно ли тогда реализовать функцию, сравнивающую 2 числа так, что если точность(?) одного меньше, то она повышается?  


Код:
MyEqual[a_, b_] :=  
 Module[{p = Max[Precision[a], Precision[b]]},  
  SetPrecision[a, p] == SetPrecision[b, p]]

 
А если Вы имете в виду "улучшенный" Equal, работающий без отбрасывания "хвостика", то, думаю, вот так:

Код:
MyEqual[a_, b_] := SetPrecision[a, Precision[a] + 1] == SetPrecision[b, Precision[b] + 1]

Всего записей: 145 | Зарегистр. 17-09-2004 | Отправлено: 19:24 10-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
r_green,
Спасибо! То, что нужно! Код в копилку
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 19:29 10-01-2011 | Исправлено: TomasVercetti, 19:39 10-01-2011
r_green



Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
TomasVercetti
Я ошибся - для полной гарантии, что хвостик вылезет в значащий диапазон для Equal[], нужно прибавлять к precision не 1, а хотя бы Log10[2^8] (~2.5).  
Т.е.:

Код:
MyEqual[a_, b_] := SetPrecision[a, Precision[a] + 3] == SetPrecision[b, Precision[b] + 3]
Всего записей: 145 | Зарегистр. 17-09-2004 | Отправлено: 01:49 11-01-2011 | Исправлено: r_green, 01:50 11-01-2011
TomasVercetti

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
r_green,
Как я понимаю, 8 — количество двоичных цифр, но в хелпе по equal сказано "differ in at most their last seven binary digits". «+1» — это для запаса или более глубокий смысл? Спасибо.
Всего записей: 319 | Зарегистр. 09-01-2006 | Отправлено: 12:39 11-01-2011
Открыть новую тему     Написать ответ в эту тему

Страницы: 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