48 votos

¿Por qué NaN^0 == 1

Le pregunte por un punto de código anterior de golf, ¿por qué:

>NaN^0
[1] 1

Tiene perfecto sentido para NA^0 1 porque NA falta de datos, y cualquier número elevado a 0 va a dar 1, incluyendo -Inf y Inf. Sin embargo, NaN , se supone que representa no es un número, entonces, ¿por qué habría de ser esto así? Esto es aún más confuso/preocupante cuando la página de ayuda para ?NaN estados:

En R, básicamente todas las funciones matemáticas (incluyendo básica Aritmética), se supone que para que funcione correctamente con +/- Inf y NaN como de entrada o de salida.

La regla básica debería ser que las llamadas y las relaciones con los archivos Inf que realmente son las declaraciones con un adecuado matemático de límite.

Cálculos que implican NaN volverá NaN o quizás NA: que de los dos no está garantizada y puede depender de la R de la plataforma (desde los compiladores pueden volver a ordenar los cálculos).

Hay una razón filosófica detrás de esto, o es sólo que ver con la forma R representa estas constantes?

25voto

BondedDust Puntos 105234

Esta es la que se hace referencia en la página de ayuda que hace referencia ?'NaN'

"La IEC 60559 estándar, también conocido como el ANSI/IEEE 754 Estándar de Punto Flotante.

http://en.wikipedia.org/wiki/NaN."

Y allí encontramos esta declaración relativa a lo que debería crear un NaN:

 "There are three kinds of operations that can return NaN:[5]
       Operations with a NaN as at least one operand.

Es que, probablemente, es de la particular, compilador de C, tal como indica la Nota que hace referencia. Esto es lo que la de C de GNU de documentación dice:

http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html

"NaN, por otro lado, infecta a cualquier cálculo que implica. A menos que el cálculo se iba a producir el mismo resultado sin importar lo que el valor real sustituido NaN, el resultado es NaN."

Así que parece que la GNU-C de la gente tiene un estándar diferente en mente al escribir su código. Y la versión 2008 de la norma ANSI/IEEE 754 Estándar de Punto Flotante se informó a hacer la sugerencia:

http://en.wikipedia.org/wiki/NaN#Function_definition

La norma publicada, no es gratuito. Así que si usted tiene los derechos de acceso o de dinero que usted puede mirar aquí:

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4610933

16voto

eddi Puntos 17947

La respuesta puede resumirse en "por razones históricas".

Parece que el IEEE 754 introdujo dos diferentes funciones de energía - pow y powr, con el último de preservar NaNs'en la OP caso y también regresan NaN para Inf^0, 0^0, 1^Inf, pero, finalmente, el último cayó como explica brevemente aquí.

Conceptualmente, estoy en el NaN de preservar el campamento, porque estoy entrando en el tema desde el punto de vista de los límites, pero con la comodidad punto de vista espero que las convenciones actuales son un poco más fáciles de tratar, incluso si no tienen mucho sentido en algunos casos (por ejemplo, sqrt(-1)^0 siendo igual a 1, mientras que todas las operaciones sobre los números reales tiene poco sentido si los hubiere).

4voto

Martin Mächler Puntos 977

Sí, estoy tarde aquí, pero como R Core miembro que estaba involucrado en este diseño, permítanme recordar lo que he comentado anteriormente. NaN preservar y NA preservación de trabajo "equivalente" en R, por lo que si usted está de acuerdo que el NA^0 debe dar 1, NaN^0 |-> 1 es una consecuencia.

De hecho (como otros dicen) que realmente debería leer R las páginas de ayuda y no C o Normas de la IEEE, para responder a tales preguntas, y SimonO101 correctamente citado

1 ^ y y y ^ 0 son 1, siempre

y estoy bastante seguro de que estaba muy involucrada (si no el autor) de que. Tenga en cuenta que es buena, no está mal, para ser capaz de proporcionar la no-NaN respuestas, también en los casos de otros lenguajes de programación hacen de manera diferente. La consecuencia de esta regla es que las cosas funcionan de forma automática; en el otro caso, el R programador se les ha instado a hacer más especial de la carcasa de la misma.

O dicho de otra forma, una regla sencilla como la de arriba (la devolución de los no-NaN en todos los casos) es una buena regla, debido a que se propaga la continuidad en un sentido matemático: lim_x f(x) = f(lim x). Hemos tenido un par de casos donde claramente se adavantageous (es decir, no necesita de carcasa especial, estoy repitiendo..) se adhieran a los de arriba "= 1" regla, en lugar de propagar NaN. Como he dicho más arriba, la función sqrt(-1)^0 es también un ejemplo de ello, ya que 1 es el resultado correcto tan pronto como ampliar el plano complejo.

3voto

James Puntos 24725

He aquí un razonamiento. De Goldberg:

En IEEE 754, Nan son a menudo representados como números de punto flotante con el exponente e_max + 1 y distinto de cero significands.

Así, NaN es un número de punto flotante, aunque con un significado especial. Elevar un número a la potencia cero establece su exponente cero, por lo tanto, no será NaN.

Tenga en cuenta también:

> 1^NaN
[1] 1

Uno es un número cuyo exponente es cero ya.

2voto

supercat Puntos 25534

Conceptualmente, el único problema con NaN^0 == 1 es que los valores cero se puede producir al menos cuatro formas diferentes, pero el formato de IEEE utiliza la misma representación para tres de ellos. La fórmula anterior igualdad sentido para el caso más común (que es uno de los tres), pero no para los demás.

Por CIERTO, los cuatro casos a los que me gustaría reconocer, sería:

  • Un literal de cero
  • Unsigned cero: la diferencia entre dos números que son indistinguibles
  • Positivo infinitesimal: El producto o el cociente de dos números de la coincidencia de signo, que es demasiado pequeño para distinguirse de cero.
  • Negativo infinitesimal: El producto o el cociente de dos números de signo opuesto, que es demasiado pequeño para distinguirse de cero.

Algunos de estos pueden ser producidos a través de otros medios (por ejemplo, literal cero podría ser producida como la suma de dos literal ceros; positivo infinitesimal por la división de un número muy pequeño por una muy grande, etc.).

Si un punto flotante reconocido lo anterior, se podría considerar elevar NaN literal cero como ceder el paso uno, y elevarlo a cualquier otro tipo de cero como ceder el paso NaN; una regla de este tipo permitiría un resultado constante que ser asumido en muchos casos en los que algo que podría ser NaN sería elevado a algo que el compilador podría identificar como una constante cero, sin que tal hipótesis de la alteración del programa de la semántica. De lo contrario, creo que el problema es que la mayoría de los códigos no se va a cuidar si x^0 podría hubiera NaN si x es NaN, y no hay mucho punto a tener un compilador de agregar código para las condiciones de los códigos no se va a preocupar. Tenga en cuenta que el problema no es sólo el código para calcular x^0, pero para los cálculos basa en lo que sería constante si x^0 fue.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X