Re: [Rd] Inconsistency in treating NaN-results?

2015-11-30 Thread William Dunlap
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
>  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-8LC_COLLATE=en_US.UTF-8
>>  [5] LC_MONETARY=nl_NL.UTF-8LC_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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Inconsistency in treating NaN-results?

2015-11-30 Thread Greg Snow
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
 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-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=nl_NL.UTF-8LC_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