[Bioc-devel] Biobase / eSet changes for this release
sfalcon at fhcrc.org
Tue Apr 18 18:12:16 CEST 2006
I'm going to answer out of order...
Rafael A Irizarry <ririzarr at jhsph.edu> writes:
> 2) It seems that in general we will be storing an esimate (expression,
> calls, copynumber) and some kind of measure of uncertainty (SE for
> expression, p-value fo calls, etc..). However, a big chunk fo the apps
> will not use uncertainty. It would be a shame to have to store a matrix
> of NAs every single time. How hard would be to have eSet take NULL for
> some matrices? The validity check can look at everything that is not NULL.
> Notice that the alternative is to define a new class which means, in my
> case, Ill need two classes for every class Im defining or having a
> matrix of NAs, which, given the size of data these days, will be very
I think we should define an EmptyMatrix class:
* new("EmptyMatrix") is small (no elements)
* We can dispatch on it. I think we might be able to get some
propagation of empty similar to how NA works. This can keep the
code from having to do lots of explicit type checking.
* NULL can happen by accident and should be an error. EmptyMatrix
won't just "appear" from a calculation.
* It will also mean that these values could go in a proper slot of
type "matrix" without having to create the matrixOrNull class
> 1) SNPset as it is will not be useful. As far as I know only Rob and me
> are developing software that will use snpSet. Both of us need a slot
> for copynumber. Otherwise we will need to create a new class, which will
> be the only one used, and we wont get to use the name SnpSet.
There is something to be said for reserving the general class names
for things that will be general. Perhaps it makes sense to choose a
slightly more specific name while sorting out the all-purpose use
Your RafaSnpSet can become SnpSet. But if you start with SnpSet and
go off in a direction that is not useful to others, then there is no
More information about the Bioc-devel