Can someone tell me where toptable() code resides on an OSX installation? I just upgraded my R and Bioconductor. Apparently, some rows were renamed in toptable(). I would like to change the row called "logFC" back to "M". I searched my system and can not find where any of the limma functions are defined. Limma seems to be installed in: /Library/Frameworks/R.framework/Versions/2.4/Resources/library/limma/ However I do not see any actual functions defined there. I installed using the command: getBioC(). Perhaps that installed "binary" rather than "source" version of limma? I don't want to create a new function called my.toptable(). I just want all of my scripts to simply work again with a single edit of the true toptable(). As an aside, I can't imagine why the column names in ANY function would be changed. These column names are essentially the external interface to the function. It seems like a very bad design decision to just one day change "M" to "logFC." I appreciate the help. This is a great user community. - Bobby

When you install an R package (where from source or binary), it installs an image so to speak of the package. You need to grab the source version of limma, change the toptable code inside that package and install it from source. You could also try to just define a new toptable function in the global namespace, which would likely do what you want, since it is for display purposes. You can get the function definition just by R> toptable and you can also dump the function to a file by R> dump("toptable", file = "toptable.R") which you edit and later source. Kasper On Mar 8, 2007, at 3:24 PM, Bobby Prill wrote: > Can someone tell me where toptable() code resides on an OSX > installation? > > I just upgraded my R and Bioconductor. Apparently, some rows were > renamed in toptable(). I would like to change the row called "logFC" > back to "M". > > I searched my system and can not find where any of the limma > functions are defined. Limma seems to be installed in: > > /Library/Frameworks/R.framework/Versions/2.4/Resources/library/limma/ > > However I do not see any actual functions defined there. > > I installed using the command: getBioC(). Perhaps that installed > "binary" rather than "source" version of limma? > > I don't want to create a new function called my.toptable(). I just > want all of my scripts to simply work again with a single edit of the > true toptable(). > > As an aside, I can't imagine why the column names in ANY function > would be changed. These column names are essentially the external > interface to the function. It seems like a very bad design decision > to just one day change "M" to "logFC." > > I appreciate the help. This is a great user community. > > - Bobby > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/ > gmane.science.biology.informatics.conductor

"James W. MacDonald" <jmacdon at="" med.umich.edu=""> writes: > Bobby Prill wrote: >> As an aside, I can't imagine why the column names in ANY function >> would be changed. These column names are essentially the external >> interface to the function. It seems like a very bad design decision >> to just one day change "M" to "logFC." > > What has been changed is the output of a function (which is _not_ the > external interface to the function), and IIRC the change was made to > better reflect what the column contained. > > The version of limma that had the columns labeled M and A still does > exist, and a simple downgrade to R-2.3.1 and a biocLite() will get you > there. > > Anyway, I'm not sure I follow your logic. Are you saying that the output > of _all_ functions once written should be inviolate? So no change, no > matter how incremental is allowed? Personally, I couldn't disagree more > with this stance. You cannot improve things if you are not allowed to > make changes to both the API and the output. There is a real tension between backward compatibility and forward progress in software development. And "progress" is in the eye of the beholder. I certainly understand the point of view that a code change that breaks _my_ code is a bad design decision :-) Perhaps it is also worth mentioning that rules for good software design also apply to simple scripts for carrying out an analysis. Reducing duplication and magic words can make recovering from such nefarious changes of upstream packages much easier. Anything in "" is a so-called magic word. If it appears many times, then putting it in a variable tends to be a win because if the magic changes, you have just a single place to change your script. More generally, any time you see the same pattern of code in your script, there is an opportunity to create a small helper function to remove/reduce that duplication. Again, the idea is to have one place to make a change, not 10. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org

Bobby Prill wrote: > As an aside, I can't imagine why the column names in ANY function > would be changed. These column names are essentially the external > interface to the function. It seems like a very bad design decision > to just one day change "M" to "logFC." What has been changed is the output of a function (which is _not_ the external interface to the function), and IIRC the change was made to better reflect what the column contained. The version of limma that had the columns labeled M and A still does exist, and a simple downgrade to R-2.3.1 and a biocLite() will get you there. Anyway, I'm not sure I follow your logic. Are you saying that the output of _all_ functions once written should be inviolate? So no change, no matter how incremental is allowed? Personally, I couldn't disagree more with this stance. You cannot improve things if you are not allowed to make changes to both the API and the output. Best, Jim -- James W. MacDonald, M.S. Biostatistician Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623 ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues.

Yes, I agree it is a little annoying to have to modify existing code to take into account the recent renaming of some columns. So far I've done just that: modifying my code. However, I suppose we could just insert a tiny section after we apply the "offending" functions, where it finds the columns that have been renamed, and change them back to what we were used to. I intended to do that, but I haven't had the need yet. That should be a lot easier than reinstalling limma from source... Jose Quoting Bobby Prill <rprill at="" jhu.edu="">: > Can someone tell me where toptable() code resides on an OSX > installation? > > I just upgraded my R and Bioconductor. Apparently, some rows were > renamed in toptable(). I would like to change the row called "logFC" > back to "M". > > I searched my system and can not find where any of the limma > functions are defined. Limma seems to be installed in: > > /Library/Frameworks/R.framework/Versions/2.4/Resources/library/limma/ > > However I do not see any actual functions defined there. > > I installed using the command: getBioC(). Perhaps that installed > "binary" rather than "source" version of limma? > > I don't want to create a new function called my.toptable(). I just > want all of my scripts to simply work again with a single edit of the > true toptable(). > > As an aside, I can't imagine why the column names in ANY function > would be changed. These column names are essentially the external > interface to the function. It seems like a very bad design decision > to just one day change "M" to "logFC." > > I appreciate the help. This is a great user community. > > - Bobby > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: > http://news.gmane.org/gmane.science.biology.informatics.conductor > > -- Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6513374 Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360 Swann Building, Mayfield Road University of Edinburgh Edinburgh EH9 3JR UK

Hi Bobby, Yes there is a much better way to get what you want. Note that the MArrayLM object returned by eBayes() is just a list. The M values are held in the 'coefficients' list member (or whatever the technical term is), and the A values are in the 'Ameans' list member. So to get what you want, you would do this: M <- fit$coefficients[,1] ## we get coef = 1 A <- if(ncol(fit$Ameans) > 1) rowMeans(fit$Ameans) else fit$Ameans Best, Jim Bobby Prill wrote: > Jim, > > I understand what you're saying. My problem is more with the "R way of > doing things," which takes some getting used to. > > Perhaps you can recommend a better way for me to do the following: I > want the M and A values for every probe on a chip. This is what I do, > which has always looked ugly to me: > > ## the number of probes > N = dim(exprs(eset))[1] > > ## ask topTable to return for every probe > T = topTable(fit, coef=1, adjust="fdr", n=N) > > ## put back in original probe order > ord = order(as.integer(rownames(T))) > T = T[ord,] > > T$A > T$M > > There must be a better way? > > - Bobby > > > On Mar 9, 2007, at 8:44 AM, James W. MacDonald wrote: > >> Bobby Prill wrote: >> >>> As an aside, I can't imagine why the column names in ANY function >>> would be changed. These column names are essentially the external >>> interface to the function. It seems like a very bad design >>> decision to just one day change "M" to "logFC." >> >> >> What has been changed is the output of a function (which is _not_ the >> external interface to the function), and IIRC the change was made to >> better reflect what the column contained. >> >> The version of limma that had the columns labeled M and A still does >> exist, and a simple downgrade to R-2.3.1 and a biocLite() will get >> you there. >> >> Anyway, I'm not sure I follow your logic. Are you saying that the >> output of _all_ functions once written should be inviolate? So no >> change, no matter how incremental is allowed? Personally, I couldn't >> disagree more with this stance. You cannot improve things if you are >> not allowed to make changes to both the API and the output. >> >> >> Best, >> >> Jim >> >> -- >> James W. MacDonald, M.S. >> Biostatistician >> Affymetrix and cDNA Microarray Core >> University of Michigan Cancer Center >> 1500 E. Medical Center Drive >> 7410 CCGC >> Ann Arbor MI 48109 >> 734-647-5623 >> >> >> ********************************************************** >> Electronic Mail is not secure, may not be read every day, and should >> not be used for urgent or sensitive issues. -- James W. MacDonald, M.S. Biostatistician Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623 ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues.