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 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
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