Pourquoi NaN^0 == 1

Question

A la suite d'un code de golf antérieur, pourquoi le feraient-ils ?

>NaN^0
[1] 1

C'est tout à fait logique pour NA^0 à 1 parce que NA est une donnée manquante, et cualquier un nombre porté à 0 donne 1, y compris -Inf y Inf . Cependant NaN est censé représenter pas un numéro Pourquoi en est-il ainsi ? C'est d'autant plus déroutant et inquiétant que la page d'aide de ?NaN États :

Dans R, toutes les fonctions mathématiques (y compris les fonctions de base de la Arithmetic ), sont censés fonctionner correctement avec +/- Inf y NaN comme d'entrée ou de sortie.

La règle de base devrait être que les appels et les relations avec les Inf sont vraiment avec une limite mathématique appropriée.

Calculs impliquant NaN renverra NaN ou peut-être NA : lequel de ces deux n'est pas n'est pas garanti et peut dépendre de la plate-forme R (puisque compilateurs peuvent réordonner les calculs).

Y a-t-il une raison philosophique à cela, ou est-ce simplement lié à la façon dont R représente ces constantes ?

Answer 1

Ceci est référencé dans la page d'aide référencée par ?'NaN'

"La norme IEC 60559, également connue sous le nom de norme ANSI/IEEE 754 pour la virgule flottante.

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

C'est là que l'on trouve cette déclaration concernant ce qui devrait créer un NaN :

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

Il s'agit probablement d'un problème lié au compilateur C, comme l'indique la note à laquelle vous avez fait référence. C'est ce que dit la documentation GNU C :

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

" NaN, en revanche, infecte tout calcul qui l'implique. À moins que le calcul ne produise le même résultat quelle que soit la valeur réelle qui remplace NaN, le résultat est NaN."

Il semble donc que les gens de GNU-C aient une norme différente à l'esprit lorsqu'ils écrivent leur code. Et la version 2008 de la norme ANSI/IEEE 754 pour la virgule flottante est signalée comme faisant cette suggestion :

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

La norme publiée n'est pas gratuite. Si vous avez des droits d'accès ou de l'argent, vous pouvez donc consulter cette page :

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

Answer 2

La réponse se résume à "pour des raisons historiques".

Il semble que l'IEEE 754 ait introduit deux différentes fonctions de puissance - pow y powr , ce dernier préservant NaN dans le cas du PO et en retournant également les NaN para Inf^0 , 0^0 , 1^Inf mais cette dernière a finalement été abandonnée en tant que expliquée brièvement ici .

D'un point de vue conceptuel, je suis dans la NaN Je pense que les conventions actuelles sont un peu plus faciles à gérer, même si elles n'ont pas beaucoup de sens dans certains cas (par exemple, les conventions de l'Union européenne). sqrt(-1)^0 étant égale à 1 alors que toutes les opérations portent sur des nombres réels n'a que peu de sens, voire aucun).

Answer 3

Oui, je suis en retard, mais en tant que membre du R Core qui a été impliqué dans cette conception, permettez-moi de rappeler ce que j'ai commenté plus haut. La préservation de NaN et la préservation de NA fonctionnent de manière "équivalente" dans R, donc si vous êtes d'accord que NA^0 devrait donner 1, NaN^0 |-> 1 est une conséquence.

En effet (comme d'autres l'ont dit), vous devriez vraiment lire les pages d'aide de R et non celles de C ou de IEEE, pour répondre à de telles questions, et SimonO101 a correctement cité

1 ^ y et y ^ 0 sont 1, toujours

et je suis presque sûr que j'ai été fortement impliqué (si ce n'est l'auteur) dans ce projet. Notez qu'il s'agit de bon Il n'est donc pas mauvais de pouvoir fournir des réponses non NAN, même dans les cas où d'autres langages de programmation agissent différemment. La conséquence d'une telle règle est que davantage de choses fonctionnent automatiquement et correctement ; dans l'autre cas, le programmeur R aurait été incité à faire lui-même plus de casses spéciales.

En d'autres termes, une règle aussi simple que celle décrite ci-dessus (qui renvoie un résultat non NaN dans tous les cas) est une bonne règle, car elle propage la continuité au sens mathématique : lim_x f(x) = f(lim x). Nous avons eu quelques cas où il était clairement avantageux (c'est-à-dire qu'il n'était pas nécessaire d'utiliser des caractères spéciaux, je répète ) d'adhérer à la règle "= 1" ci-dessus, plutôt que de propager NaN. Comme je l'ai dit plus haut, le sqrt(-1)^0 est également un tel exemple, car 1 est le résultat correct dès que l'on passe au plan complexe.

Answer 4

Voici un raisonnement. A partir de Goldberg :

Dans la norme IEEE 754, les NaN sont souvent représentés par des flottants. l'exposant e_max + 1 et des significateurs non nuls.

Donc NaN est un nombre à virgule flottante, mais avec une signification particulière. L'élévation d'un nombre à la puissance zéro met son exposant à zéro, ce qui fait qu'il n'est plus NaN.

À noter également :

> 1^NaN
[1] 1

Un est un nombre dont l'exposant est déjà nul.

Answer 5

D'un point de vue conceptuel, le seul problème avec NaN^0 == 1 est que les valeurs zéro peuvent être obtenues d'au moins quatre manières différentes, mais que le format IEEE utilise la même représentation pour trois d'entre elles. La formule ci-dessus a un sens pour le cas le plus courant (qui est l'un des trois), mais pas pour les autres.

BTW, les quatre cas que je reconnaîtrais seraient les suivants :

• Un zéro littéral
• Zéro non signé : différence entre deux nombres indiscernables
• Infinitésimale positive : Le produit ou le quotient de deux nombres de signe correspondant, qui est trop petit pour être distingué de zéro.
• Infinitésimal négatif : Le produit ou le quotient de deux nombres de signe opposé, qui est trop petit pour être distingué de zéro.

Certains d'entre eux peuvent être produits par d'autres moyens (par exemple, le zéro littéral pourrait être produit par la somme de deux zéros littéraux ; l'infinitésimal positif par la division d'un très petit nombre par un très grand, etc.)

Si une virgule flottante reconnaissait ce qui précède, elle pourrait utilement considérer qu'élever NaN à un zéro littéral donne un, et l'élever à tout autre type de zéro donne NaN ; une telle règle permettrait de supposer un résultat constant dans de nombreux cas où quelque chose qui pourrait être NaN serait élevé à quelque chose que le compilateur pourrait identifier comme un zéro constant, sans que cette supposition n'altère la sémantique du programme. Sinon, je pense que le problème est que la plupart des codes ne vont pas se préoccuper de savoir si x^0 pourrait serait NaN si x es NaN et il n'y a pas beaucoup d'intérêt à ce que le compilateur ajoute du code pour des conditions dont le code ne se préoccupe pas. Notez que le problème n'est pas seulement le code de calcul des x^0 mais pour tous les calculs basés sur ce qui serait constant si x^0 était.