similar to: max and pmax of NA and NaN

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 >prob <- c(0.5,0.4,0.3,0.1,0.0) >cal <- prob * log(prob,base=2) >cal [1] -0.5000000 -0.5287712 -0.5210897 -0.3321928 NaN Is there any way to change NaN to zero ? I did come up with this by applying Ripley's relpy to my previous question cal <-prob*log(pmax(prob,0.00000001),base=2) Any suggestion ? Thank you Taka

Hi, Please consider the following : x = c(1,3,NA,5) y = c(2,NA,4,1) min(x,y,na.rm=TRUE) # ok [1] 1 max(x,y,na.rm=TRUE) # ok [1] 5 sum(x,y,na.rm=TRUE) # ok [1] 16 pmin(x,y,na.rm=TRUE) # ok [1] 1 3 4 1 pmax(x,y,na.rm=TRUE) # ok [1] 2 3 4 5 psum(x,y,na.rm=TRUE) [1] 3 3 4 6 # expected result Error: could not find function "psum" # actual result

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 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?: >

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 <murdoch.duncan at gmail.com> wrote: > 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

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

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 >

"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, I'm trying to override pmin and pmax for my own matrix. These two functions have ... as an argument. I tried to override them as follows: setMethod("pmax", class_name, function(x, ..., na.rm) { ... }) I use this way to override primitive functions such as min/max and it works fine. But it doesn't work for pmin and pmax. I guess because they are regular functions? How

The documentation says, "pmax and pmin take several vectors as arguments and return a single vector giving the parallel maxima (or minima) of the vectors." I discovered that, if you use a matrix or array instead of a vector, pmax returns a matrix or array, respectively. This makes pmax and pmin much more useful, and should not be left to people to discover on their own! For example:

I see that base::pmax() does not support long vectors. Is R-devel interested in reports like this; ie. is there a goal of full support for long vectors in "basic" functions, something I at least would greatly appreciate? MRE: > pmax(rep(1L, 3*10^9), 0) Error in pmax(rep(1L, 3 * 10^9), 0) : long vectors not supported yet: ../../../R-devel-src/src/include/Rinlinedfuns.h:522 Best,

Kasper, If you're not interested or dont have time to create said patch yourself let me know and i can do it. Best, ~G On Mon, Jan 21, 2019, 11:36 AM Duncan Murdoch <murdoch.duncan at gmail.com wrote: > On 21/01/2019 12:35 p.m., Kasper Daniel Hansen wrote: > > I see that base::pmax() does not support long vectors. > > > > Is R-devel interested in reports like this;

Hello R users, I am relatively new to R and cannot seem to crack a coding problem. I am working with substance abuse data, and I have a variable called "primary.drug" which is considered the drug of choice for each subject. I have just a few missing values on that variable. Instead of using a multiple imputation method like chained equations, I would prefer to derive these

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

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,

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

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