Hi Gordon,

Thanks for the very thorough comments.

In my own use of limma, I never subset topTable output by rowname, so it
> isn't clear to me why ReportTools needs to do this.  To me, topTable
> already does the desired subsetting, so further subsetting should never be
> required.
>

We actually don't do any subsetting of the topTable or topTableF results,
and are instead taking those results and further decorating them, with e.g.
some simple plots of expression levels in the different treatment groups.


> More generally, I am unclear why ReportTools needs to operate on a
> MArrayLM object.  Why not operate on the topTable() output directly?
>
>
In prior versions, it was nice to be able to do dispatch on the object that
represented the statistical test that was being done. So, for microarray
differential expression we would dispatch on the MArrayLM object. This
allowed the methods to have some basic functionality for the different
types of analysis that we were using. Currently, it should be possible to
dispatch on the topTable results directly, though with the addition of a
couple of methods on our side. This is likely more in line with the
direction we've been headed, since so many of the results we'd like to
dispatch on don't actually have explicitly classed outputs.

Now as to your suggestions from your previous e-mail:

Here is my tentative solution:


> 1. lmFit() will start enforcing unique row names in MArrayLM objects.  If
> no row names are provided, then row names will be set to 1:N.  If the row
> names of the expression matrix are not unique, then they will be made
> unique by makeUnique().


> 2. lmFit() will no longer create an annotation column called 'ID'. Instead
> the relevant information will be held in the row.names.


> 2. topTable() will preserve the row.names found in the MArrayLM fit
> object, same as topTableF does currently.


> How does that sound?


This sounds totally reasonable to me. I'm currently just tracking what
you're doing with topTable and topTableF, and have no particularly strong
preference on whether you rewrite them to be consistent in row.names or
not. It simplifies our code a small amount, but I'm happy to either
maintain as is, or to move forward with this solution. Our use cases tend
to be heavily eSet-based, so our main concerns are how to provide
annotation for genes when it's not available in the fData or 'genes'
data.frame.


> Possible cons:  when rownames are non-unique, the makeUnique() function
> will create rownames previously unknown to the user.  Also I wonder how
> many people with miss the numerical row numbers currently output by
> topTable?


I can see how this might be problematic when dealing with array designs
with replicated features, but since we're so heavily eSet-based, it's more
of a theoretical concern for us, since you can't have duplicate row.names
for assay data in an eSet.

Thanks again for your comments, and let me know when/if you decide to make
these changes. We'll likely follow suit fairly quickly, since our package
unit tests should fail once this is changed.

Cheers,

Jason

-- 
Jason A. Hackney, Ph.D.
Bioinformatics and Computational Biology
Genentech
hackney.jason@gene.com
650-467-5084

	[[alternative HTML version deleted]]

