Prompted by a spot of earlier code golfing why would:
>NaN^0 [1] 1
It makes perfect sense for NA^0
to be 1 because NA
is missing data, and any number raised to 0 will give 1, including -Inf
and Inf
. However NaN
is supposed to represent not-a-number, so why would this be so? This is even more confusing/worrying when the help page for ?NaN
states:
In R, basically all mathematical functions (including basic
Arithmetic
), are supposed to work properly with+/- Inf
andNaN
as input or output.The basic rule should be that calls and relations with
Inf
s really are statements with a proper mathematical limit.Computations involving
NaN
will returnNaN
or perhapsNA
: which of those two is not guaranteed and may depend on the R platform (since compilers may re-order computations).
Is there a philosophical reason behind this, or is it just to do with how R represents these constants?
Bookmark this question. Show activity on this post.
Easily the strangest thing about floating-point numbers is the floating-point value “NaN”. Short for “Not a Number”, even its name is a paradox. Only floating-point values can be NaN, meaning that from a type-system point of view, only numbers can be “not a number”.
"Why does NaN exist at all, rather than resulting in an exception or error?" Because it is neither an exception nor an error. It is a perfectly valid result for a calculation. You have several use cases in mathematics where you are receiving the equivalent to "NaN", i.e., something that cannot be measured.
Binary format NaNs are represented with the exponential field filled with ones (like infinity values), and some non-zero number in the significand field (to make them distinct from infinity values).
This is referenced in the help page referenced by ?'NaN'
"The IEC 60559 standard, also known as the ANSI/IEEE 754 Floating-Point Standard.
http://en.wikipedia.org/wiki/NaN."
And there you find this statement regarding what should create a NaN:
"There are three kinds of operations that can return NaN:[5] Operations with a NaN as at least one operand.
It is probably is from the particular C compiler, as signified by the Note you referenced. This is what the GNU C documentation says:
http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
" NaN, on the other hand, infects any calculation that involves it. Unless the calculation would produce the same result no matter what real value replaced NaN, the result is NaN."
So it seems that the GNU-C people have a different standard in mind when writing their code. And the 2008 version of ANSI/IEEE 754 Floating-Point Standard is reported to make that suggestion:
http://en.wikipedia.org/wiki/NaN#Function_definition
The published standard is not free. So if you are have access rights or money you can look here:
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4610933
The answer can be summed up by "for historical reasons".
It seems that IEEE 754 introduced two different power functions - pow
and powr
, with the latter preserving NaN
's in the OP case and also returning NaN
for Inf^0
, 0^0
, 1^Inf
, but eventually the latter was dropped as explained briefly here.
Conceptually, I'm in the NaN
preserving camp, because I'm coming at the issue from viewpoint of limits, but from convenience point of view I expect current conventions are slightly easier to deal with, even if they don't make a lot of sense in some cases (e.g. sqrt(-1)^0
being equal to 1 while all operations are on real numbers makes little sense if any).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With