[Rd] Inconsistency in treating NaN-results?

[William Dunlap]

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]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Gregory (Greg) L. Snow Ph.D.
> 538280 at gmail.com
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel