similar to: base::mean not consistent about NA/NaN

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 is returned - but on some hardware you get NaN or sometimes NA and sometimes NaN. Also there are C

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-project.org/bugzilla/show_bug.cgi?id=17441 Best, Jan [[alternative HTML version deleted]]

On Tue, Jul 3, 2018 at 10:12 AM, Jan Gorecki <j.gorecki at wit.edu.pl> 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 > sum(c(NaN,NA)) [1] NaN oh, maybe you mean:

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 still exists. Jan On Mon, Jul 2, 2018 at 8:28 PM, Barry Rowlingson < b.rowlingson at

"nana" is meant to express "NA, really NA". Your suggestion sounds good. On Thu 2 Jan, 2020, 3:38 AM Pages, Herve, <hpages at fredhutch.org> wrote: > Happy New Year everybody! > > The name (is.nana) doesn't make much sense to me. Can you explain it? > > One alternative would be to add an extra argument (e.g. 'strict') to > is.na(). FALSE by

Hello R-devel, Best wishes in the new year. I am writing to kindly request new R function so NA_real_ can be more easily detected. Currently if one wants to test for NA_real_ (but not NaN) then extra work has to be done: `is.na(x) & !is.nan(x)` Required functionality is already at C level so to address my request there is not that much to do. Kevin Ushey made a nice summary of current R C api

Hi guys. Check this out: > NaN +NA [1] NaN > NA + NaN [1] NA I thought "+" was commutative by definition. What's going on? > R.version _ platform powerpc-apple-darwin6.8 arch powerpc os darwin6.8 system powerpc, darwin6.8 status major 1 minor 9.0 year 2004 month 04 day 12 language R > (Both give NA under linux, so it looks

On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk> 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? will return ?NaN? or perhaps ?NA?: >

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(x, m = 1, n = 2) [1] NA > .rowMeans(rev(x), m = 1, n = 2) [1] NaN >

On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for

Extremes.Rd, that documents 'max' and 'pmax', has this in "Details" section, in the paragraph before the last. By definition the min/max of a numeric vector containing an NaN is NaN, except that the min/max of any vector containing an NA is NA even if it also contains an NaN. ------------------ >>>>> Michal Burda <michal.burda at centrum.cz>

Dear R users, is the following OK? > max(NA, NaN) [1] NA > max(NaN, NA) [1] NA > pmax(NaN, NA) [1] NA > pmax(NA, NaN) [1] NaN ...or is it a bug? Documentation says that NA has a higher priority over NaN. Best regards, Michal Burda [[alternative HTML version deleted]]

Happy New Year everybody! The name (is.nana) doesn't make much sense to me. Can you explain it? One alternative would be to add an extra argument (e.g. 'strict') to is.na(). FALSE by default, and ignored (with or w/o a warning) when the type of 'x' is not "numeric". H. On 12/31/19 22:16, Jan Gorecki wrote: > Hello R-devel, > > Best wishes in the new

Dear R developers, I spotted that R_isNA and R_IsNaN could be improved when applied on a vector where we could take out small part of their logic, run it once, and then reuse inside the loop. I setup tiny plain-C experiment. Taking R_IsNA, R_IsNaN from R's arithmetic.c, and building R_vIsNA and R_vIsNaN accordingly. For double input of size 1e9 (having some NA and NaN) I observed following

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 guaranteed and may depend on the R platform (since compilers may re-order computations).

I'm having trouble grokking complex NaN's. This first set examples using complex(re=NaN,im=NaN) give what I expect > Re(complex(re=NaN, im=NaN)) [1] NaN > Im(complex(re=NaN, im=NaN)) [1] NaN > Arg(complex(re=NaN, im=NaN)) [1] NaN > Mod(complex(re=NaN, im=NaN)) [1] NaN > abs(complex(re=NaN, im=NaN)) [1] NaN and so do the following > Re(complex(re=1,

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

The help page for function identical says: 'identical' sees 'NaN' as different from 'as.double(NA)', but all 'NaN's are equal (and all 'NA' of the same type are equal). However, we have x <- NaN y <- as.double(NA) x # [1] NaN y # [1] NA identical(x,y) # [1] TRUE In my opinion, NaN and as.double(NA) should be distinguished as the

Hi! I noticed that cumsum behaves different than the other cumulative functions wrt. NaN values: > values <- c(1,2,NaN,1) > for ( f in c(cumsum, cumprod, cummin, cummax)) print(f(values)) [1] 1 3 NA NA [1] 1 2 NaN NaN [1] 1 1 NaN NaN [1] 1 2 NaN NaN The reason is that cumsum (in cum.c:33) contains an explicit check for ISNAN. Is that intentional? IMHO, ISNA would be better