Numpy: DOC: la cadena de documentos para numpy.finfo.eps es incorrecta
La cadena de numpy.finfo actualmente define el atributo eps como:
El número positivo representable más pequeño, tal que 1.0 + eps! = 1.0. [...]
Esa definición no es correcta, al menos en el caso común de los formatos binarios IEEE 754. Por ejemplo, con el formato IEEE 754 binary64 bajo el modo habitual de redondeo de lazos a pares, la definición indicada da un valor de 2**-53 + 2**-105 (aprox. 1.1102230246251568e-16 ), que es un poco más de la mitad del valor correcto de 2**-52 (aproximadamente 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
Algunas posibles reformulaciones:
El número positivo más pequeño tal que 1.0 + eps es representable.
O:
La diferencia entre 1.0 y el flotador representable más pequeño mayor que 1.0.
O podría definirse en términos de nextafter como:
El valor de
np.nextafter(1.0, np.inf) - 1.0.
A modo de comparación, la sección 5.2.4.2.2, párrafo 11 del estándar C99 define las diversas macros *_EPSILON ( DBL_EPSILON , FLT_EPSILON , ...) como:
la diferencia entre 1 y el valor mínimo mayor que 1 que es representable en el tipo de punto flotante dado, b 1− p
La cadena de documentación de epsneg es igualmente incorrecta.
mdickinson
Todos 5 comentarios
Ah, mirando la fuente , veo que eps realidad se calcula como la _potencia más pequeña de 2_ tal que 1 + eps != eps . Eso no es lo mismo que la diferencia entre 1.0 y el siguiente flotante representable desde 1.0 , aunque las dos cosas coinciden para IEEE 754 y el redondeo de empates a pares. modo. Así que las reformulaciones que he sugerido anteriormente no son válidas. Quizás algo como:
La potencia más pequeña de 2 tal que 1.0 + eps es representable.
¿seria mejor? Técnicamente, ese 2 debería reemplazarse con la base de punto flotante, pero probablemente sea innecesariamente pedante. ¿NumPy tiene actualmente algún soporte para radix 10 o radix 16 flotantes?
[Aparte, prefiero la definición de épsilon al estilo C99, ya que solo involucra el formato y no depende de la semántica de la suma de punto flotante. En particular, la definición de C99 no depende del modo de redondeo actualmente en vigor, mientras que la definición de 1 + eps != 1 sí.]
mdickinson
en 5 ene. 2016
Un puntero a np.spacing y np.nextafter en la sección "Ver también" también sería potencialmente útil.
joferkington
en 5 ene. 2016
Aquí estamos casi 4 años después y esto no se ha solucionado. No creo que https://github.com/numpy/numpy/pull/14618 sea suficiente para cerrar este problema.
Para aclarar el informe de error, la definición actual de eps en la cadena de documentos está desviada en aproximadamente un factor de 2 del valor de eps devuelto por np.finfo. (Los números que doy a continuación son para implementaciones con el estándar de coma flotante de 64 bits IEEE-754).
np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16
Sin embargo, la cadena de documentos define eps como
"El número positivo representable más pequeño, tal que 1.0 + eps! = 1.0".
El valor real de eps que satisfaría la definición 1.0 + eps_min! = 1.0 es:
eps_min = 2-53 + 2-105 = 1.1102230246251568e-16
que es casi la mitad del valor actual de np.finfo (1.0) .eps. Probablemente no queramos cambiar el valor de np.finfo (1.0) .eps para mantener la compatibilidad con versiones anteriores, pero la definición de la cadena de documentos de eps debe corregirse para que coincida con lo que se calcula. El código fuente de np.finfo (1.0) eps usa numpy.MachAr, y mirando la documentación allí, que permite otras bases además de 2, creo que la mejor definición de eps es una de las primeras opciones que @mdickinson sugirió anteriormente. También agregaría un valor de ejemplo a la descripción:
"La diferencia entre 1.0 y el flotante representable más pequeño mayor que 1.0. (Para flotantes binarios de 64 bits en el estándar IEEE-754, eps = 2 ** - 52 ≅ 2.22e-16)".
La cadena de documentación para epsneg es igualmente incorrecta.
gwhammett
en 8 dic. 2019
También acabo de tropezar con esta inexactitud. Esto debería arreglarse.
Como referencia, Matlab documenta su eps (que tiene el mismo valor) como: "la distancia desde 1.0 hasta el siguiente número más grande de doble precisión, es decir, 2 ^ -52".
c-f-h
en 12 feb. 2020
La definición actual es incorrecta y confusa debido a problemas de redondeo. @gwhammett, la definición propuesta es correcta y más descriptiva y anima a un RP a cerrar este problema.
rossbar
en 26 feb. 2020
Temas relacionados
perezpaya
·
4Comentarios
toddrjen
·
4Comentarios
dmvianna
·
4Comentarios
MorBilly
·
4Comentarios
ghost
·
4Comentarios
Comentario más útil
Aquí estamos casi 4 años después y esto no se ha solucionado. No creo que https://github.com/numpy/numpy/pull/14618 sea suficiente para cerrar este problema.
Para aclarar el informe de error, la definición actual de eps en la cadena de documentos está desviada en aproximadamente un factor de 2 del valor de eps devuelto por np.finfo. (Los números que doy a continuación son para implementaciones con el estándar de coma flotante de 64 bits IEEE-754).
np.finfo (1.0) .eps = 2 ** - 52 = 2.220446049250313e-16
Sin embargo, la cadena de documentos define eps como
El valor real de eps que satisfaría la definición 1.0 + eps_min! = 1.0 es:
eps_min = 2-53 + 2-105 = 1.1102230246251568e-16
que es casi la mitad del valor actual de np.finfo (1.0) .eps. Probablemente no queramos cambiar el valor de np.finfo (1.0) .eps para mantener la compatibilidad con versiones anteriores, pero la definición de la cadena de documentos de eps debe corregirse para que coincida con lo que se calcula. El código fuente de np.finfo (1.0) eps usa numpy.MachAr, y mirando la documentación allí, que permite otras bases además de 2, creo que la mejor definición de eps es una de las primeras opciones que @mdickinson sugirió anteriormente. También agregaría un valor de ejemplo a la descripción:
La cadena de documentación para epsneg es igualmente incorrecta.