Is this not just an indication that normalize is now a poor choice of a function name?
LEo On 20 Feb 2013, at 16:14, Wolfgang Huber wrote: > Hi > > is it clear that all these different functions (methods) share similar > semantics and enough (conceptually) of their interface? > > Wouldn't the implication be that preemptively every possible string of > characters should already be defined as a generic function in BiocGenerics? > > Best wishes > Wolfgang > > Il giorno Feb 20, 2013, alle ore 11:04 AM, Laurent Gatto <lg...@cam.ac.uk> ha > scritto: > >> On 19 February 2013 22:44, Hervé Pagès <hpa...@fhcrc.org> wrote: >>> Hi Laurent, and maintainers of packages with a normalize() function, >>> >>> >>> On 02/15/2013 04:28 AM, Laurent Gatto wrote: >>>> >>>> A quick (and incomplete) manual search using >>>> http://search.bioconductor.jp/ suggest the following usage of >>>> normalize: >>>> >>>> As a function: >>>> xps::normalize >>>> codelink::normalize >>>> EBImage::normalize >>>> diffGeneAnalysis::normalize >>>> >>>> Defining a generic and methods: >>>> oligo::normalize >>>> flowCore::normalize >>>> MSnbase::normalize >>>> isobar::normalize >>>> >>>> and >>>> >>>> several normalize\.[*+] functions >>>> >>>> Would it be reasonable to add a normalize generic definition to >>>> BiocGenerics? The generic definitions in the above packages differ, >>>> however. >>> >>> >>> Sounds good to me. >>> >>> However, since the various normalize() functions have different >>> signatures, we need to agree on what the signature of the generic >>> in BiocGenerics should be. >>> >>> Here is a summary of the situation: >>> >>> ** xps package: normalize() is an ordinary function with the >>> following arg list: >>> >>> normalize(xps.data, filename=character(0), filedir=getwd(), >>> tmpdir="", update=FALSE, select="all", method="mean", >>> option="transcript:all", logbase="0", exonlevel="", >>> refindex=0, refmethod="mean", params=list(0.02, 0), >>> add.data=TRUE, verbose=TRUE) >>> >>> The package also defines normalize.constant(), normalize.lowess(), >>> normalize.quantiles(), normalize.supsmu(), which are also ordinary >>> functions (not S3 methods), and have similar but slightly >>> different arg lists. >>> >>> ** codelink package: Ordinary function with the following args: >>> >>> normalize(object, method="quantiles", log.it=TRUE, >>> preserve=FALSE, weights=NULL, verbose=FALSE) >>> >>> ** EBImage package: Ordinary function with the following args: >>> >>> normalize(x, separate=TRUE, ft=c(0, 1)) >>> >>> ** diffGeneAnalysis package: Ordinary function with the following >>> args: >>> >>> normalize(rawdata, numSlides, ctrl, expm, ctrlbg=0.30, >>> expmbg=0.30) >>> >>> ** deepSNV package: S4 generic with the following args: >>> >>> normalize(test, control, ...) >>> >>> ** isobar package: S4 generic with the following args: >>> >>> normalize(x, f=median, target="intensity", exclude.protein=NULL, >>> use.protein=NULL, f.doapply=TRUE, log=TRUE, >>> channels=NULL, na.rm=FALSE, per.file=TRUE, ...) >>> >>> ** affy package: S4 generic with the following args: >>> >>> normalize(object, ...) >>> >>> ** flowCore package: S4 generic with the following args: >>> >>> normalize(data, x, ...) >>> >>> ** MSnbase package: S4 generic with the following args: >>> >>> normalize(object, method, ...) >>> >>> ** oligo package: S4 generic with the following args: >>> >>> normalize(object, method=normalizationMethods(), >>> copy=TRUE, subset=NULL, >>> target='core', verbose=TRUE, ...) >>> >>> So it looks like the greatest common factor is normalize(x, ...). >>> Not too surprising for a generic that covers such a wide range of >>> related but slightly different concepts / algorithms. >>> >>> One technical difficulty though is that, even though almost all these >>> functions seem to take an S4 object as their 1st arg, some of them >>> don't: >>> >>> (a) For EBImage::normalize(), 'x' can be an ordinary array in >>> addition to an Image object. >>> >>> (b) For diffGeneAnalysis::normalize(), 'rawdata' is an ordinary >>> matrix. >>> >>> (c) For deepSNV::normalize(), 'test' can be an ordinary matrix >>> in addition to a deepSNV object. >>> >>> (d) For oligo::normalize(), 'object' can be an ordinary matrix >>> in addition to a FeatureSet object. >>> >>> So how can we disambiguate when the first arg is an ordinary matrix? >>> IMO normalize() should fail in that case i.e. no package should define >>> methods for ordinary arrays or matrices. Not ideal but better than the >>> current situation where what is returned depends on which package was >>> loaded last. >>> >>> I could put normalize(x, ...) in BiocGenerics if nobody objects, but >>> that's all. I don't have time to fix the 10 packages that this change >>> will affect. However, I'd rather wait the beginning of the Bioc 2.13 >>> devel cycle (April) for such a change. For some packages like >>> diffGeneAnalysis (which doesn't use S4 at all), that will probably >>> require a significant amount of changes since it will need to pass >>> the data to normalize in an S4 container instead of an ordinary matrix. >>> >>> Comments and suggestions are welcome. >> >> Fine by me. >> >> Laurent >> >>> Thanks, >>> H. >>> >>>> >>>> Best wishes, >>>> >>>> Laurent >>>> >>>> _______________________________________________ >>>> Bioc-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>>> >>> >>> -- >>> Hervé Pagès >>> >>> Program in Computational Biology >>> Division of Public Health Sciences >>> Fred Hutchinson Cancer Research Center >>> 1100 Fairview Ave. N, M1-B514 >>> P.O. Box 19024 >>> Seattle, WA 98109-1024 >>> >>> E-mail: hpa...@fhcrc.org >>> Phone: (206) 667-5791 >>> Fax: (206) 667-1319 >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel