[Rd] Inconsistency in treating NaN-results?

[Mark van der Loo]

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

	[[alternative HTML version deleted]]