Regarding the limma vs marray issue, I would support the choice of limma. I'm currently analysing data from a 2 colour long oligo (CompuGen M22k) experiment using 126 slides so I thought I'd share my experiences over the last few months. I've played around with both limma and marray packages for data checking and normalisation and have found that both can do pretty much the same thing. My bias is towards limma since I'm interested in the linear modelling approach (post norm) and limma is under active development (at least more than I perceive marray is). Things I've used marray for is to get diagnostic plots (eg maRawPlots and maDiagPlots) but I find these two cluttered so I've gone to my own functions to produce summary plots (some of which call limma functions). I've also had some slides with large spatial biases (eg well defined regions of very strong dye bias over 20-50% of the array) so I've been looking at 2D spatial norm and scale normalisation within array. With regards to 2D spatial norm, I've actually taken the limma code for print-tip-loess and modified it to do a loess on M~SpotRow*SpotColumn*A (ie within grid location and intensity are predictor variables) which appears to work quite well. So in summary I've found having both packages useful (since its easy to convert data between marray and limma classes, as well as take the code from one package and convert it to work on data in the other format). However given the overlap, I do think it would be beneficial to merge the two packages into a single package, which at this stage I think should be limma. Cheers Chris -- Dr Chris Wilkinson Research Officer (Bioinformatics) | Visiting Research Fellow Child Health Research Institute (CHRI) | Microarray Analysis Group 7th floor, Clarence Rieger Building | Room 121 Women's and Children's Hospital | School of Applied Mathematics 72 King William Rd, North Adelaide, 5006 | The University of Adelaide,5005 Math's Office (Room 121) Ph: 8303 3714 CHRI Office (2nd floor) Ph: 8161 6363 Christopher.Wilkinson@adelaide.edu.au http://mag.maths.adelaide.edu.au/crwilkinson.html On Wed, 2004-01-28 at 21:47, bioconductor-request@stat.math.ethz.ch wrote: > ---------------------------------------------------------------------- > Message: 5 > Date: Wed, 28 Jan 2004 17:59:38 +1100 (EST) > From: "Gordon K Smyth" <smyth@wehi.edu.au> > Subject: [BioC] [Fwd: Bioc Book Chapter] > To: <bioconductor@stat.math.ethz.ch> > Message-ID: > <1392.192.168.97.213.1075273178.squirrel@homebase.wehi.edu.au> > Content-Type: text/plain; charset=iso-8859-1 > > -------- Original Message -------- > Subject: Bioc Book Chapter > From: "Rafael A. Irizarry" <ririzarr@jhsph.edu> > Date: Wed, January 28, 2004 7:43 am > To: Gordon Smyth <smyth@wehi.edu.au> > > Dear Gordon, > > The deadline for deciding on the bioc book chapter titles and authors is > fast approaching. As we discussed earlier, it seems two chapters could > be written for the chapter on cDNA (two color) > pre-processing. One about limma and one about marray*. I need to > decide on one. I've been looking at both packages closely and it seems > limma would be my choice. > > It is likely that whatever package goes in this book will probably > become the "default" bioc package for two color preprocessing and it is > possible that the other would eventually be removed from > Bioconductor. However, I discussed this with other Bioconductor core > developers and some are concerned about limma not integrating well with > other Bioc packages. In particular Robert and others were hoping that > limma would use the exprSet class as its main data storage > entity. This would make data exchange to and from other packages much > easier. The exprSet class has recently been remodeled to better > reflect the needs of cDNA (two-color) arrays. See > bioC/madman/Rpacks/Biobase/R/eset.R. > > This is not a discussion for you and I to have but rather Bioconductor as a whole. The main point is that if Bioconductor is willing to > accept limma as a default, and it appears the usage of exprSets will be > the requirement, I definetely would like to include a short chapter on > pre-processing cDNA arrays with limma as the package of > choice. Would you (or one of the grad students that helps you maintain > it) be willing to take the lead on such a chapter? > > I am aware that the capabilities of limma extend far beyond > pre-processing. It is planned that the book will also contain "case > studies", from raw-data to result, and there, some of these further > capabilities should be demonstrated. But here, we are talking about > pre-processing. > > If in fact we consolidate packages, for the users sake, the > functionality in marray that is not in limma (it does not appear to be > much) will need to be exported. I will also be contacting Jean who I > hope will be willing to collaborate with you in writing the chapter. > > Best Regards, > Rafael > > > > ------------------------------