Thank you very much, Greg and Bill for clearing things up. As said, it was more out of curiosity then anything else.
I think my examples were not completely inconsistent (as Greg mentioned) since arithmetic operations that generate NaN's do so without warning: > Inf - Inf [1] NaN > 0/0 [1] NaN, while mathematical functions generating NaN's do (as noted by Greg): > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced > log(-1) [1] NaN > gamma(-1) [1] NaN Warning message: In gamma(-1) : NaNs produced And this was what surprised me. The rule thus seems to be: arithmetic operations do it without warning, standard math functions do it with a warning. I think that is totally fine. As long as we can reason about what to expect, we're good. To answer Bill's question >> If R did make sin(4.6e14) NaN, would you want a warning? I think I like the behavior as it is (not producing NaN), but that's because I feel I have a reasonable working knowledge about numerical precision issues. I'm not an expert, but I believe that at least my internal alarm bells start ringing at the right time, and my old copy of Stoer and Bulirsch[1] is never much more then an arm's length away. So it all depends on what user you're aiming at when implementing such things. A (switchable) warning about loss of precision without returning NaN would probably be a reasonable compromise. Best, Mark [1] https://books.google.nl/books?id=1oDXWLb9qEkC Op di 1 dec. 2015 om 00:09 schreef William Dunlap <wdun...@tibco.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 <538...@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.vander...@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@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > -- > > Gregory (Greg) L. Snow Ph.D. > > 538...@gmail.com > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel