Numpy: DOC: строка документации для numpy.finfo.eps неверна

Созданный на 5 янв. 2016  ·  5Комментарии  ·  Источник: numpy/numpy

Строка документации для numpy.finfo настоящее время определяет атрибут eps как:

Наименьшее представимое положительное число такое, что 1.0 + eps! = 1.0. [...]

Это определение неверно, по крайней мере, в общем случае двоичных форматов IEEE 754. Например, в формате двоичного 64 стандарта IEEE 754 в обычном режиме округления до четного указанное определение дает значение 2**-53 + 2**-105 (приблизительно 1.1102230246251568e-16 ), что немного более половины правильного значения 2**-52 (приблизительно 2.220446049250313e-16 ).

In [36]: eps = 2**-53 + 2**-105

In [37]: eps
Out[37]: 1.1102230246251568e-16

In [38]: 1.0 + eps != 1.0
Out[38]: True

In [39]: 1.0 + np.nextafter(eps, -np.inf) != 1.0
Out[39]: False

In [40]: np.finfo(float).eps
Out[40]: 2.2204460492503131e-16

Некоторые возможные переформулировки:

Наименьшее положительное число такое, что представимо 1.0 + eps.

Или же:

Разница между 1.0 и наименьшим представимым числом с плавающей запятой больше 1.0.

Или это может быть определено в терминах nextafter как:

Значение np.nextafter(1.0, np.inf) - 1.0 .

Для сравнения, параграф 11 раздела 5.2.4.2.2 стандарта C99 определяет различные макросы *_EPSILON ( DBL_EPSILON , FLT_EPSILON , ...) как:

разница между 1 и наименьшим значением больше 1, которое может быть представлено в данном типе с плавающей запятой, b 1− p

Строка документации для epsneg также неверна.

00 - Bug Triaged Documentation

Самый полезный комментарий

Вот и прошло почти 4 года, и это не исправлено. Я не думаю, что https://github.com/numpy/numpy/pull/14618 будет достаточным, чтобы закрыть эту проблему.

Чтобы прояснить отчет об ошибке, текущее определение eps в строке документации отличается примерно в 2 раза от значения eps, возвращаемого np.finfo. (Числа, которые я привожу ниже, относятся к реализациям с 64-битным стандартом с плавающей запятой IEEE-754.) То есть,

np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16

Однако строка документации определяет eps как

«Наименьшее представимое положительное число такое, что 1.0 + eps! = 1.0».

Фактическое значение eps, которое удовлетворяет определению 1.0 + eps_min! = 1.0, составляет:

eps_min = 2-53 + 2-105 = 1,1102230246251568e-16

что составляет почти половину текущей стоимости np.finfo (1.0) .eps. Вероятно, мы не хотим изменять значение np.finfo (1.0) .eps, чтобы сохранить обратную совместимость, но определение строки документации eps необходимо скорректировать, чтобы оно соответствовало расчетам. Исходный код для np.finfo (1.0) eps использует numpy.MachAr, и, глядя на документацию, которая позволяет использовать другие базы, кроме 2, я думаю, что лучшее определение eps - это один из ранних вариантов, которые ранее предлагал @mdickinson . Я бы также добавил в описание пример значения:

«Разница между 1.0 и наименьшим представимым числом с плавающей запятой больше 1.0. (Для 64-битных двоичных чисел с плавающей запятой в стандарте IEEE-754 eps = 2 ** - 52 2.22e-16.)»

Строка документации для epsneg также неверна.

Все 5 Комментарий

Ах, глядя на исходный код , я вижу, что eps фактически вычисляется как наименьшая _power из 2_, так что 1 + eps != eps . Это не то же самое, что разница между 1.0 и следующей представимой плавающей точкой вверх от 1.0 , хотя эти две вещи действительно совпадают для IEEE 754 и округления от равного до равного. режим. Так что предложенные мной выше переформулировки недействительны. Возможно что-то вроде:

Наименьшая степень двойки, позволяющая представить 1,0 + eps.

было бы лучше? Технически, это 2 следует заменить на систему счисления с плавающей запятой, но это, вероятно, излишне педантично. Поддерживает ли NumPy в настоящее время числа с плавающей точкой с основанием 10 или 16?

[Кстати, я предпочитаю определение epsilon в стиле C99, поскольку оно включает только формат и не зависит от семантики сложения с плавающей запятой. В частности, определение C99 не зависит от текущего режима округления, в то время как определение 1 + eps != 1 зависит.]

Также может быть полезен указатель на np.spacing и np.nextafter в разделе «См. Также».

Вот и прошло почти 4 года, и это не исправлено. Я не думаю, что https://github.com/numpy/numpy/pull/14618 будет достаточным, чтобы закрыть эту проблему.

Чтобы прояснить отчет об ошибке, текущее определение eps в строке документации отличается примерно в 2 раза от значения eps, возвращаемого np.finfo. (Числа, которые я привожу ниже, относятся к реализациям с 64-битным стандартом с плавающей запятой IEEE-754.) То есть,

np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16

Однако строка документации определяет eps как

«Наименьшее представимое положительное число такое, что 1.0 + eps! = 1.0».

Фактическое значение eps, которое удовлетворяет определению 1.0 + eps_min! = 1.0, составляет:

eps_min = 2-53 + 2-105 = 1,1102230246251568e-16

что составляет почти половину текущей стоимости np.finfo (1.0) .eps. Вероятно, мы не хотим изменять значение np.finfo (1.0) .eps, чтобы сохранить обратную совместимость, но определение строки документации eps необходимо скорректировать, чтобы оно соответствовало расчетам. Исходный код для np.finfo (1.0) eps использует numpy.MachAr, и, глядя на документацию, которая позволяет использовать другие базы, кроме 2, я думаю, что лучшее определение eps - это один из ранних вариантов, которые ранее предлагал @mdickinson . Я бы также добавил в описание пример значения:

«Разница между 1.0 и наименьшим представимым числом с плавающей запятой больше 1.0. (Для 64-битных двоичных чисел с плавающей запятой в стандарте IEEE-754 eps = 2 ** - 52 2.22e-16.)»

Строка документации для epsneg также неверна.

Я тоже только что наткнулся на эту неточность. Это должно быть исправлено.

Для справки, Matlab документирует свое eps (которое имеет то же значение) как: «расстояние от 1,0 до следующего большего числа с двойной точностью, то есть 2 ^ -52».

Текущее определение неверно и сбивает с толку из-за проблем с округлением. @gwhammett: предлагаемое определение является правильным и более

Была ли эта страница полезной?
0 / 5 - 0 рейтинги