I hope you don’t mind us using this mailing list for a small advertisement, but
we think it is most relevant for this group:
We'd like to invite you to RIOT 2017 - the 3rd workshop on R Implementation,
Optimization and Tooling [1].
It will take place co-located with, and during, useR! 2017 in Br
This caught us yesterday when a string that we assumed to be in UTF-8 was actually using
CP1252. (This came from an internal web based service, so the root cause is not R's
fault.) The help page for iconv states that the result of an invalid conversion is NA
only when the toRaw argument is TRU
In R 3.3.3, I observe the following on Ubuntu 16.04 (when building
from source as well as for the sudo apt r-base build):
> x <- c(NA, NaN)
> mean(x)
[1] NA
> mean(rev(x))
[1] NaN
> rowMeans(matrix(x, nrow = 1, ncol = 2))
[1] NA
> rowMeans(matrix(rev(x), nrow = 1, ncol = 2))
[1] NaN
> .rowMeans(
From ?NA
Numerical computations using ‘NA’ will normally result in ‘NA’: a
possible exception is where ‘NaN’ is also involved, in which case
either might result.
and ?NaN
Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
which of those two is not guarantee
On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley
wrote:
> From ?NA
>
> Numerical computations using ‘NA’ will normally result in ‘NA’: a
> possible exception is where ‘NaN’ is also involved, in which case
> either might result.
>
> and ?NaN
>
> Computations involving ‘NaN’ w
Although help("is.nan") says:
"Computations involving NaN will return NaN or perhaps NA: ..."
it might not be obvious that this is also why one may get:
> mean(c(-Inf, +Inf, NA))
[1] NaN
> mean(c(-Inf, NA, +Inf))
[1] NA
This is because internally the intermediate sum +Inf + -Inf is NaN in
t
