Thank you Tomas for detailed explanation. Such a nice description deserves
to be included somewhere in documentation, R-internals maybe.
Regards
Jan
On 18 Jul 2018 18:24, "Tomas Kalibera" wrote:
Yes, the performance overhead of fixing this at R level would be too
large and it would complicate th
Yes, the performance overhead of fixing this at R level would be too
large and it would complicate the code significantly. The result of
binary operations involving NA and NaN is hardware dependent (the
propagation of NaN payload) - on some hardware, it actually works the
way we would like - NA
On Tue, Jul 3, 2018 at 10:12 AM, Jan Gorecki wrote:
> Thank you for interesting examples.
> I would find useful to document this behavior also in `?mean`, while `+`
> operator is also affected, the `sum` function is not.
`sum` is "affected" on my system, if you mean:
> sum(c(NA,NaN))
[1] NA
> su
Thank you for interesting examples.
I would find useful to document this behavior also in `?mean`, while `+`
operator is also affected, the `sum` function is not.
For mean, NA / NaN could be handled in loop in summary.c. I assume that
performance penalty of fix is the reason why this inconsistency
And for a starker example of this (documented) inconsistency,
arithmetic addition is not commutative:
> NA + NaN
[1] NA
> NaN + NA
[1] NaN
On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch wrote:
> On 02/07/2018 11:25 AM, Jan Gorecki wrote:
>> Hi,
>> base::mean is not consistent in terms of h
On 02/07/2018 11:25 AM, Jan Gorecki wrote:
Hi,
base::mean is not consistent in terms of handling NA/NaN.
Mean should not depend on order of its arguments while currently it is.
The result of mean() can depend on the order even with regular numbers.
For example,
> x <- rep(c(1, 10^(-15)), 100
The current behavior is as documented. See ?NA, which says
"Numerical computations using ‘NA’ will normally result in ‘NA’: a
possible exception is where ‘NaN’ is also involved, in which case
either might result"
--Ista
On Mon, Jul 2, 2018 at 11:25 AM, Jan Gorecki wrote:
> Hi,
> base:
Hi,
base::mean is not consistent in terms of handling NA/NaN.
Mean should not depend on order of its arguments while currently it is.
mean(c(NA, NaN))
#[1] NA
mean(c(NaN, NA))
#[1] NaN
I created issue so in case of no replies here status of it can be looked up
at:
https://bugs.r-p
