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

Displaying 20 results from an estimated 6000 matches similar to: "aggregate() function and na.rm = TRUE"

2008 Nov 10
1
Combing xyplot and curve() plot via print
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)
2002 Apr 25
4
sum() with na.rm=TRUE, again
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
2008 Jun 25
1
tiff() causes R to crash on WinXP (PR#11804)
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:
2008 Jul 24
1
Error - unable to load shared library
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
2007 Aug 29
0
sum(data.frame(),na.rm=TRUE) still throws an Error
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
2008 May 02
0
Using option na.rm=True in function SD does not work for matrix with complete columns of NAs (PR#11364)
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
2009 Oct 29
1
weighted.mean uses zero when na.rm=TRUE (PR#14032)
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
2006 Aug 01
1
Global setting for na.rm=TRUE
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
2010 Jul 23
1
na.rm=TRUE
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.
2011 May 12
1
do.call and applying na.rm=TRUE
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]]
2007 Jun 20
2
Expected behavior from: all(c(NA, NA, NA) < NA, na.rm = TRUE)?
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
2009 Jul 24
1
Aggregate, max and time of max
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
2011 Aug 12
2
rollapply.zoo() with na.rm=TRUE
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
2003 Apr 28
2
sum(..., na.rm=TRUE) oddity
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
2007 Dec 11
1
[Kurt.Hornik@wu-wien.ac.at: Re: range( <dates>, na.rm = TRUE )] (PR#10508)
------- 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
2008 Aug 12
2
Possible buglet (wart ?) of odfWeave 0.7.6 (with workaround)
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
2007 Dec 11
2
range( <dates>, na.rm = TRUE ) (PR#10508)
(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(
2008 Oct 09
1
Error when reading a SAS transport file
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) :
2019 May 10
0
[R] approx with NAs --> new argument 'na.rm=TRUE' ?!
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
2019 May 08
3
[R] approx with NAs --> new argument 'na.rm=TRUE' ?!
>>>>> 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