ошибка с нулевым делением в пакете неопределенностей python

Question

Почему возникает следующая ошибка с нулевым делением?

>>> from uncertainties import ufloat 
>>> a = ufloat((0,0)) 
>>> x = ufloat((0.3,0.017)) 
>>> a**x 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/uncertainties/__init__.py", line 601, in f_with_affine_output 
    if arg.derivatives 
    File "<string>", line 1, in <lambda> 
ZeroDivisionError: 0.0 cannot be raised to a negative power 
>>> 0.0**x 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/uncertainties/__init__.py", line 601, in f_with_affine_output 
    if arg.derivatives 
    File "<string>", line 1, in <lambda> 
ValueError: math domain error 

Не должны ли они оба вернуть 0.0?

Answer 1

Ситуация довольно тонкая:

1. С одной стороны, вы правы, оба результата должны быть математически 0.

   В самом деле, поведение должно быть таким же, как в Python:

   >>> 0.**0.3 
   0.0 
   

   Когда показатель имеет неопределенность результат не должен быть таким образом точно 0 (нет неопределенности), так как результат Python всегда равен 0.

   Случай a = 0±0 является особенным: a**x равно 0 для положительного x, даже если x имеет неопределенность (результат не определен на ноль или отрицательное x значения). С другой стороны, если a=0±0.1 значение a**x является неопределенным, потому что один не может взять (реальную) мощность отрицательного числа (и a может быть отрицательным, если она имеет ненулевую неопределенность) (если кто не использует комплексные числа, что не является целью неопределенности ).

2. С другой стороны, модуль неопределенностей позволяет пользователям изменять неопределенности чисел в любое время и получать правильные результаты. Это столкновение с «идеальными» математическими результатами выше: если a = 0±0, то результат a**xпозже может быть не определен; взаимно, если a = 0±0.3, результат должен быть определен, но должен каким-то образом стать 0, если неопределенность a позже изменено на 0.

Технически, все это сводится к тому, что a**x с 0 < < х 1 определяется в a = 0, но там не дифференцируемо: случай неопределенности нуля должен работать (функция определена), но неопределенная неопределенность должна давать ошибку (производная не определена). Оба эти случая должны каким-то образом обрабатываться динамически, поскольку неопределенность может быть изменена пользователем «на лету».

Это интересная ситуация, поэтому я еще раз подумаю о том, можно ли модифицировать модуль неопределенности каким-либо изящным способом и разместить эту проблему.

PS: Начиная с версии 2.3.5, the uncertainties package правильно обрабатывает случаи вопроса, и вообще все случаи, когда число с неопределенностью на самом деле имеет нулевую неопределенность (даже если такое же количество но с неопределенностью даст неопределенную ошибку при линейном распространении ошибки, как в вопросе).

Answer 2

Я думаю, что ZeroDivisionError будет происходить всякий раз, когда показатель меньше 1. Раздел кода, который задыхается, пытается взять производную. Мое туманное воспоминание об исчислении в средней школе говорит мне, что производная от x ** y равна y * x ** (y - 1).

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