[Rd] Inconsistency in treating NaN-results?
Mark van der Loo
mark.vanderloo at gmail.com
Tue Dec 1 10:43:15 CET 2015
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
while mathematical functions generating NaN's do (as noted by Greg):
In sin(Inf) : NaNs produced
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 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.
Op di 1 dec. 2015 om 00:09 schreef William Dunlap <wdunlap at 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)
>  -0.792253849684354
> > sin(mpfr(4.6e14, precBits=500))
> 1 'mpfr' number of precision 500 bits
>  -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)
> >  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,
> >> I'm just wondering.
> >> The behavior of R on calculations that result in NaN seems a bit
> >> inconsistent.
> >> # this is expected:
> >>> 0/0
> >>  NaN
> >> # but this gives a warning
> >>> sin(Inf)
> >>  NaN
> >> Warning message:
> >> In sin(Inf) : NaNs produced
> >> # and this again does not
> >>> exp(NaN)
> >>  NaN
> >> Conceptually, I like to think that R computes over the real line
> >> 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
> >> functions (following the IEEE standard on double precision). If that's
> >> 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
> >> 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:
> >>  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
> >> 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
[[alternative HTML version deleted]]
More information about the R-devel