similar to: aggregate() function and na.rm = TRUE

All, I'm trying to put an xyplot and a plot produced via curve() on the same page. It seems that mfrow and layout don't work, and now I'm trying print but that does not work either. Any suggestions much appreciated. Cheers, David p.11 = xyplot(1:10 ~ 1:10) curve(sin, 0,3, ylim=c(-3,3), ylab="sin and cos", lty = 1) curve(cos, 0,3, ylim=c(-3,3), lty = 5, add=TRUE)

Hi: I remember a post several days ago by Jon Baron, concerning the behavior of sum() when one sets na.rm=TRUE: the result will be a zero sum for a vector of all NA's, as here, for the second row: > ss<- data.frame(x=c(1,NA,3,4),y=c(2,NA,4,NA)) > ss x y 1 1 2 2 NA NA 3 3 4 4 4 NA > apply(ss,1,sum,na.rm=TRUE) 1 2 3 4 3 0 7 4 I am rather alarmed by that zero, because

Full_Name: Gustaf Rydevik Version: 2.7.1 OS: Win XP professional Submission from: (NULL) (130.237.97.254) The following lines of code crash R 2.7.1 (=cause R to show "The R gui has encountered a problem and needs to close"....). Replicated on two WinXp professional machines, as well as by Uwe Ligges. > sessionInfo() R version 2.7.1 (2008-06-23) i386-pc-mingw32 locale:

Hi, I'm trying to use fastICA package but I only get an error message like following. > library(fastICA) Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/usr/lib/R/library/fastICA/libs/fastICA.so': /usr/lib/R/library/fastICA/libs/fastICA.so: undefined symbol: sgesdd_ Error: package/namespace load failed for 'fastICA' Here's the

Hello, sum(data.frame(),na.rm=TRUE) still throws an Error, is this really the intended behavior? > sum(data.frame()) Error in FUN(X[[1L]], ...) : only defined on a data frame with all numeric or complex variables > sum(data.frame(),na.rm=TRUE) Error in FUN(X[[1L]], ...) : only defined on a data frame with all numeric or complex variables The context is # x is a data frame generated from

Dear R-developers, =20 according to the "what's new"-section in version R 2.7.0, there has been = a change in the working of co[rv] and so also in sd and var. =20 I am afraid, that the use of function sd with option "na.rm=3DT" has not = been changed appropriately. So the following problem exists with missing = data: =20 > sessionInfo() R version 2.7.0 (2008-04-22)=20

The weighted.mean() function replaces NA values with 0.0 when the user specifies na.rm=TRUE: x <- c(101, 102, NA) mean(x, na.rm=TRUE) # 101.5, correct weighted.mean(x, na.rm=TRUE) # 67.66667, wrong weighted.mean(x, w=c(1,1,1), na.rm=TRUE) # 67.66667, wrong weighted.mean(x, w=c(1,1,1)/3, na.rm=TRUE) # 67.66667, wrong The weights are

Hello! Is it possible to set na.rm=TRUE in a global way? I'am constantly forgeting on this when performing analyses. I agree that one should be carefull with this when developing some code, but not necesarilly so in data analysis. Lep pozdrav / With regards, Gregor Gorjanc ---------------------------------------------------------------------- University of Ljubljana PhD student

POS=sum(x[-1][x[-1]>0],na.rm=TRUE) is this the correct syntax? -- View this message in context: http://r.789695.n4.nabble.com/na-rm-TRUE-tp2299596p2299596.html Sent from the R help mailing list archive at Nabble.com.

Hi all! I need to do something really simple using do.call. If I want to call the mean function inside do.call, how do I apply the condition na.rm=TRUE? So, I use do.call(mean, list(x)) where x is my data. This works fine if there are no NAs. Thanks, John [[alternative HTML version deleted]]

All, For data consisting of serial measurements on subjects, one may use the aggregate function to say compute the peak response for each subject for each design condition. Is there a way to alter this or another one-liner to also retain the time at which the peak occurred and thus avoid writing a doing this via a loop? I suppose one could attempt to employ the split function but that's

Hi all, Came across this curious behavior in: R version 2.5.0 Patched (2007-06-05 r41831) A simplified example is: > all(c(NA, NA, NA) > NA, na.rm = TRUE) [1] TRUE Is this expected by definition? If one reduces this to individual comparisons, such as : > NA > NA [1] NA > all(NA > NA) [1] NA > all(NA > NA, na.rm = TRUE) [1] TRUE the initial comparison on the 3

Hi. I'm comparing output from rollapply.zoo, as produced by two versions of R and package zoo. I'm illustrating with an example from a R-help posting 'Zoo - bug ???' dated 2010-07-13. My question is not about the first version, or the questions raised in that posting, because the behaviour is as documented. I'm puzzled as to why na.rm no longer is passed to mean, i.e. why

Hi all, I get two different results when using sum() and the switch na.rm. The result is correct when na.rm=FALSE. Linux Redhat 7.3, R version 1.6.1. I've had no luck searching the mail archives, so I was hoping somebody could explain/check this one for me. I will need to apply the function to missing data, simple as it is. Code: x<-matrix(runif(20,0,5)%/%1,4,5) # random matrix

------- Start of forwarded message ------- Date: Tue, 13 Nov 2007 21:44:57 +0100 To: Steve Mongin <sjm at ccbr.umn.edu> Cc: cran at r-project.org Subject: Re: range( <dates>, na.rm = TRUE ) In-Reply-To: <200711062044.OAA14064 at minnow.ccbr.umn.edu> Reply-To: Kurt.Hornik at wu-wien.ac.at From: Kurt Hornik <Kurt.Hornik at wu-wien.ac.at> X-AntiVirus: checked by AntiVir

Dear List, I have had problems inserting some (not all !) figures via odfWeave (using print(someLatticeFunction)...). The figure was correctly displayed in a R device window but the resulting ODF document displayed the correct space for the figure and an empty frame with a "broken image" icon and a "read error" mention. Exploration of the odf (.odt, in my case) file showed

Dear All, I get the following error when using either SASxport or Hmisc to read an .xpt file: > w <- read.xport("D:/consult/Trophos/dnp/base/TRO_ds_20081006.xpt") Erreur dans factor(x, f$value, f$label) : invalid labels; length 15 should be 1 or 14 > z<- sasxport.get("D:/consult/Trophos/dnp/base/TRO_ds_20081006.xpt") Erreur dans factor(x, f$value, f$label) :

(Drats! Jitterbug is playing tricks with the PR# again. Attempting to refile so that we can kill PR#10509) Peter Dalgaard wrote: > Kurt.Hornik at wu-wien.ac.at wrote: > =20 >> ------- Start of forwarded message ------- >> Date: Tue, 13 Nov 2007 21:44:57 +0100 >> To: Steve Mongin <sjm at ccbr.umn.edu> >> Cc: cran at r-project.org >> Subject: Re: range(

I have now committed a version "fulfilling" your wish, partly at least, to R-devel . In the new approx(*, na.rm=FALSE) cases, the result of how NA's are treated does depend on the 4 different extrapolation rules {1, 2, 1:2, 2:1} The main reason was that I kept the low level code in C to do +- what it did before which automatically was using 'rule' to determine these

>>>>> Robert Almgren >>>>> on Fri, 3 May 2019 15:45:44 -0400 writes [ __ to R-help __ -- here diverted to R-devel on purpose] > There is something I do not think is right in the approx() > function in base R, with method="constant" and in the > presence of NA values. I have 3.6.0, but the behavior > seems to be the same in