Skip to content
Prev 185 / 21312 Next

[Bioc-devel] eset.Rnw revised in Biobase, please review

Hi Kasper,
Kasper Daniel Hansen wrote:
I doubt that such a comprehensive approach will be useful, especially 
since we do not yet have a markup, or intended mechanism for display or 
managing the history mechanism. I suspect that at least initially less 
is going to be more helpful. Perhaps tracking changes to the 
expressions, or a few other slots would be a good first cut.
Vince answered this - we are not yet sure that they would be, and 
would appreciate examples where they are not.
I think that these should be checked in many different ways. Any 
place that they can be assigned they should be scrutinized and if 
present we should check that they are the same, and in the same order as 
those in the phenoData (whether row names on the dataframe or in a 
special slot).
I don't see the inefficiencies you are mentioning? A data.frame is 
merely a list of vectors and since I don't think we will solve all 
problems with a single vector of reporterInfo then data.frame is the 
natural data structure. If you have some other data indicating specifice 
inefficiencies please provide it. Your example, and others, are what we 
had in mind.
Not sure what you are worried about here, but we do envisage some 
general uses of splitting parts, or all of eSets via different variables 
that are being made available. Again, it is probably best to see what 
the real usage patterns are before we commit to the implementation.
I don't see how you could every realistically parse a label and get 
back what you want (or even know, in some programmatic way that there is 
valuable information there), your experience may be different.
We try not to force much of anything onto developers. Lists and 
environments are essentially equivalent here, and there is probably no 
need to impose one or the other. Users/developers need to store things 
together and to access them by name - lists and environments both 
provide that capability. If you, or someone else, wants to do some 
careful time and space comparisons, we would certainly take that under 
advisement, but for now, we think we have the resources to get this new 
data structure in place for the next release.
That would be one use, Martin already pointed out one set of 
problems, let me suggest that the need to sort seems wrong, as does the 
notion that only red and green are valid names ( %in%, toupper, and a 
few other functions might make any user of such a class much happier). 
You probably also want to run the eSet validity checker.

   Thanks again for all the comments,
     Robert