Inconsistency in treating NaN-results?

Inf - Inf

0/0

sin(Inf)

log(-1)

gamma(-1)

If R did make sin(4.6e14) NaN, would you want a warning?

As a side note, Splus makes sin(x) NA, with a warning, for
abs(x)>1.6*2^48 (about
4.51e+14) because more than half the digits are incorrect in sin(x)
for such x.  E.g.,
in R we get:

options(digits=16)
library(Rmpfr)
sin(4.6e14)

[1] -0.792253849684354

sin(mpfr(4.6e14, precBits=500))

1 'mpfr' number of precision  500   bits
[1] -0.7922542110462653250609291646717356496505801794010...

If R did make sin(4.6e14) NaN, would you want a warning?

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Nov 30, 2015 at 2:38 PM, Greg Snow <538280 at gmail.com> wrote:

R and the S language that it is based on has evolved as much as it has
been designed, so there are often inconsistencies due similar
functionality evolving from different paths.  In some cases these
inconsistencies are resolved, but generally only once someone notices
and care enough to do something about it.  In some other cases the
inconsistencies are left for historical reasons and for back
compatibility (for example some functions use the na.rm option and
other use the na.action option for how to deal with missing values).

That said, your report inconsistencies in some function calls, but
your calls are not completely consistent.  Consider:

sin(NaN)

[1] NaN

See, no warning, just like your other cases.  Also consider the
difference between log(-1) and log(NaN).  It looks like the warning
comes mainly when going from one type of exception (Inf) to another
(NaN), but not when propagating an NaN.

The 'sin' function (and others) do not know whether the argument was
typed in as Inf, or if it is the result of another function returning
Inf (well technically it could be made to figure out some common
cases, but I for one don't see it worth the effort).  So you could
have typed something like 'sin(myfun(x))' and sin looks like it
assumes that if myfun would have warned about creating an NaN value,
so a second warning is not needed, but myfun may legitimately return
Inf, so sin feels it helpful to warn in that case.  And warnings can
always be turned off and/or ignored.

The only real exception that you show is 0/0 is does not start with
NaN, but produces NaN.  But infix operator functions tend to behave a
bit differently.

On Thu, Nov 26, 2015 at 2:07 AM, Mark van der Loo
<mark.vanderloo at gmail.com> wrote:

This question is more out of curiosity than a complaint or suggestion,

but

I'm just wondering.

The behavior of R on calculations that result in NaN seems a bit
inconsistent.

# this is expected:

0/0

[1] NaN

# but this gives a warning

sin(Inf)

[1] NaN
Warning message:
In sin(Inf) : NaNs produced

# and this again does not

exp(NaN)

[1] NaN


Conceptually, I like to think that R computes over the real line

augmented

with NaN, Inf, -Inf, NaN, and NA (which is technically also NaN). As

far as

I know, this set is closed under R's arithmetic operations and

mathematical

functions (following the IEEE standard on double precision). If that's

the

case, the result sin(Inf)=NaN seems normal to me and a warning is
unnecessary.

So why the choice to have warning on sin(Inf), but not on 0/0 or

exp(Nan)?

Is it just historical or am I missing a reasoning or some standard?


Best,
Mark

sessionInfo()

R version 3.2.2 (2015-08-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.3 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=nl_NL.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=nl_NL.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=nl_NL.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=nl_NL.UTF-8 LC_IDENTIFICATION=C

        [[alternative HTML version deleted]]

--
Gregory (Greg) L. Snow Ph.D.
538280 at gmail.com