I'd like to suggest a merge function for MAlists be implemented in limma, since (I think) their are potential problems with the use of merge.RGlist and print-tip normalisation of the merged RG list. Within an experiment, I have slides spanning two print runs, in which spot locations where changed between runs. Limma provides the merge function for RGlist objects to allow merging data so that each row of the RGlist is the same gene ie the rows of RG2 are rearranged to match the rows of RG1. However when you come to doing print-tip normalisation, my understanding is that we really want the genes back in the original order, since the print- tip groups are calculated by checking which row we are and how it fits into the layout specifications. Otherwise we are doing print-tip normalisation on groups of genes that are not in the same print-tip (for those that were re- arranged) So I'd like to suggest that the merge function be implemented for MAlist objects. Then when one has arrays from different print runs, you can read in data from each print run into seperate RG objects, normalise them seperately, then merge the normalised data together. 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 (CR2 52A) Ph: 8161 6363 Christopher.Wilkinson@adelaide.edu.au http://mag.maths.adelaide.edu.au/crwilkinson.html

Hi Chris, You're absolutely right that there's a need for merge at the normalized level for exactly the reason that you say, and I guess that we'll add it in. The reason that limm doesn't have a merge method for MALists is that I use a different method to solve the, often arising, problem that you mention. I find that there are sometimes small differences in gene IDs between different print runs, and there is always a certain indeterminacy associated with repeated ProbeIDs as row names. So I tend the sort all the normalized MAList objects according to the DNA 384-well plate position from which each spot was printed rather than using the ProbeIDs. If the different print runs use the same set of 384-well plates library but with different numbers of pins etc, etc, try this. po1 <- printorder(RG1, set appropriate arguments) o1 <- order(po1$plateposition) po2 <- printorder(RG2, set appropriate arguments) o2 <- order(po2$plateposition) MA <- cbind(MA1[o1,], MA2[o2,] ) Normally the arguments for printorder() are set in the $printer component of the MAList. For this to work, you need to know what was different about the print runs which caused the probes to land in different positions on the array - e.g., different number of pins, different duplicate spacing etc. Cheers Gordon At 11:20 AM 26/02/2004, Christopher Wilkinson wrote: >I'd like to suggest a merge function for MAlists be implemented in limma, >since >(I think) their are potential problems with the use of merge.RGlist and >print-tip normalisation of the merged RG list. > >Within an experiment, I have slides spanning two print runs, in which spot >locations where changed between runs. Limma provides the merge function for >RGlist objects to allow merging data so that each row of the RGlist is the >same >gene ie the rows of RG2 are rearranged to match the rows of RG1. > >However when you come to doing print-tip normalisation, my understanding is >that >we really want the genes back in the original order, since the print- tip >groups >are calculated by checking which row we are and how it fits into the layout >specifications. Otherwise we are doing print-tip normalisation on groups of >genes that are not in the same print-tip (for those that were re- arranged) > >So I'd like to suggest that the merge function be implemented for MAlist >objects. Then when one has arrays from different print runs, you can read in >data from each print run into seperate RG objects, normalise them seperately, >then merge the normalised data together. > >Cheers >Chris