[Rd] Inconsistency in treating NaN-results?
wdunlap at tibco.com
Tue Dec 1 00:09:03 CET 2015
As a side note, Splus makes sin(x) NA, with a warning, for
4.51e+14) because more than half the digits are incorrect in sin(x)
for such x. E.g.,
in R we get:
> sin(mpfr(4.6e14, precBits=500))
1 'mpfr' number of precision 500 bits
If R did make sin(4.6e14) NaN, would you want a warning?
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:
>  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
>> # this is expected:
>>  NaN
>> # but this gives a warning
>>  NaN
>> Warning message:
>> In sin(Inf) : NaNs produced
>> # and this again does not
>>  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
>> 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?
>> R version 3.2.2 (2015-08-14)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 14.04.3 LTS
>>  LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>>  LC_TIME=nl_NL.UTF-8 LC_COLLATE=en_US.UTF-8
>>  LC_MONETARY=nl_NL.UTF-8 LC_MESSAGES=en_US.UTF-8
>>  LC_PAPER=nl_NL.UTF-8 LC_NAME=C
>>  LC_ADDRESS=C LC_TELEPHONE=C
>>  LC_MEASUREMENT=nl_NL.UTF-8 LC_IDENTIFICATION=C
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
> Gregory (Greg) L. Snow Ph.D.
> 538280 at gmail.com
> R-devel at r-project.org mailing list
More information about the R-devel