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 <[email protected]> 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 > <[email protected]> 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]] >> >> ______________________________________________ >> [email protected] mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Gregory (Greg) L. Snow Ph.D. > [email protected] > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
