ggtitle - ¿Por qué NaN ^ 0== 1

ggtitle position (6)

Aquí hay un razonamiento. De Goldberg :

En IEEE 754, los NaN a menudo se representan como números de coma flotante con el exponente e_max + 1 y significandos distintos de cero.

Entonces NaN es un número de coma flotante, aunque con un significado especial. Elevar un número al cero de potencia establece su exponente a cero, por lo tanto, ya no será NaN.

También tenga en cuenta:

> 1^NaN [1] 1

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

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

>NaN^0 [1] 1

Tiene mucho sentido que NA^0 sea 1 porque a NA le faltan datos, y cualquier número elevado a 0 dará 1, incluidos -Inf e Inf . Sin embargo, se supone que NaN representa no-un-número , entonces, ¿por qué sería así? Esto es aún más confuso / preocupante cuando la página de ayuda para ?NaN dice:

En R, básicamente se supone que todas las funciones matemáticas (incluida la Aritmética básica) funcionan correctamente con +/- Inf y NaN como entrada o salida.
La regla básica debería ser que las llamadas y las relaciones con Infs realmente son declaraciones con un límite matemático adecuado.
Los cálculos que involucren a NaN devolverán NaN o quizás NA : cuál de esos dos no está garantizado y puede depender de la plataforma R (ya que los compiladores pueden reordenar los cálculos).

¿Hay alguna razón filosófica detrás de esto, o solo tiene que ver con cómo R representa estas constantes?

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

Por cierto, los cuatro casos que reconocería serían:

Un literal cero
Cero sin signo: la diferencia entre dos números que son indistinguibles
Infinitesimal positivo: el producto o cociente de dos números de signo coincidente, que es demasiado pequeño para ser distinguido de cero.
Infinitesimal Negativo: El producto o cociente de dos números de signo opuesto, que es demasiado pequeño para ser distinguido de cero.

Algunos de estos pueden producirse por otros medios (por ejemplo, el cero literal podría producirse como la suma de dos ceros literales, infinitesimal positivo por la división de un número muy pequeño por uno muy grande, etc.).

Si un punto flotante reconociera lo anterior, podría considerar útil elevar NaN a un cero literal como el rendimiento de uno, y elevarlo a cualquier otro tipo de cero como rendimiento NaN; dicha regla permitiría suponer un resultado constante en muchos casos donde algo que podría ser NaN se elevaría a algo que el compilador podría identificar como un cero constante, sin tal supuesto que altere la semántica del programa. De lo contrario, creo que el problema es que a la mayoría de los códigos no les va a importar si x^0 podría NaN si x es NaN , y no tiene mucho sentido que a un compilador no le importe el código de las condiciones. Tenga en cuenta que el problema no es solo el código para calcular x^0 , sino para cualquier cálculo basado en eso que sería constante si x^0 fuera.

Esto se menciona en la página de ayuda a la que hace referencia ?''NaN''

"El estándar IEC 60559, también conocido como Estándar de punto flotante ANSI / IEEE 754.

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

Y allí encuentras esta afirmación con respecto 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.

Probablemente sea del compilador particular de C, como lo indica la Nota a la que se hace referencia. Esto es lo que dice la documentación de GNU C:

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

"NaN, por otro lado, infecta cualquier cálculo que lo involucre. A menos que el cálculo produzca el mismo resultado, sin importar el valor real que reemplace NaN, el resultado es NaN".

Entonces, parece que las personas de GNU-C tienen en mente un estándar diferente al escribir su código. Y se informa que la versión 2008 de ANSI / IEEE 754 Floating-Point Standard hace esa sugerencia:

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

El estándar publicado no es gratis. Entonces, si tiene derechos de acceso o dinero, puede mirar aquí:

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

La respuesta se puede resumir por "por razones históricas".

Parece que el IEEE 754 introdujo dos funciones de potencia diferentes : pow y powr , con este último conservando NaN en el caso OP y también devolviendo NaN para Inf^0 , 0^0 , 1^Inf , pero eventualmente este último se eliminó como explicado brevemente aquí .

Conceptualmente, estoy en el campo de la preservación de NaN , porque estoy llegando al tema desde el punto de vista de los límites, pero desde el punto de vista de la conveniencia, espero que las convenciones actuales sean un poco más fáciles de tratar, incluso si no hacen mucho de sentido en algunos casos (por ejemplo, sqrt(-1)^0 es igual a 1, mientras que todas las operaciones son en números reales tiene poco sentido si hay alguno).

Sí, llegué tarde aquí, pero como miembro de R Core que participó en este diseño, permítanme recordar lo que comenté anteriormente. NaN conservando y NA preservando el trabajo "equivalentemente" en R, por lo que si acepta que NA ^ 0 debería dar 1, NaN ^ 0 | -> 1 es una consecuencia.

De hecho (como otros dijeron) realmente debería leer las páginas de ayuda de R y no las normas C o IEEE, para responder tales preguntas, y SimonO101 citó correctamente

1 ^ yy ^ 0 son 1, siempre

y estoy bastante seguro de que estaba muy involucrado (si no es el autor) de eso. Tenga en cuenta que es bueno , no está mal, poder proporcionar respuestas que no sean de NaN, también en casos en que otros lenguajes de programación lo hagan de manera diferente. La consecuencia de tal regla es que más cosas funcionan automáticamente de manera correcta; en el otro caso, se habría pedido al programador R que hiciera más cajas especiales ella misma.

O dicho de otro modo, una regla simple como la anterior (devolver non-NaN en todos los casos) es una buena regla, porque propaga la continuidad en un sentido matemático: lim_x f (x) = f (lim x). Hemos tenido algunos casos en los que era claramente ventajoso (es decir, no necesitaba una cubierta especial, estoy repitiendo ...) adherirme a la regla "= 1" anterior, en lugar de propagar NaN. Como dije más arriba, el sqrt (-1) ^ 0 también es un ejemplo, ya que 1 es el resultado correcto tan pronto como se extiende al plano complejo.

Si observa el tipo de NaN, sigue siendo un número, simplemente no es un número específico que puede representarse mediante el tipo numérico.

EDITAR:

Por ejemplo, si tomas 0/0. Cual es el resultado? Si trataste de resolver esta ecuación en papel, te quedas atascado en el primer dígito, ¿cuántos cero caben en otro 0? Puedes poner 0, puedes poner 1, puedes poner 8, todos encajan en 0 * x = 0, pero es imposible saber cuál es la respuesta correcta. Sin embargo, eso no significa que la respuesta ya no sea un número, simplemente no es un número que pueda representarse.

Independientemente, cualquier número, incluso un número que no puedas representar, con el poder de cero sigue siendo 1. Si desglosas algunas matemáticas, x^8 * x^0 se puede simplificar aún más con x^(8+0) que equivale a x^8 , ¿a dónde fue el x^0 ? Tiene sentido si x^0 = 1 porque entonces la ecuación x^8 * 1 explica por qué x^0 simplemente desaparece de la existencia.