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,
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
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 somethin
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 produc
