[Bioc-devel] RFC: xy2i and i2xy in *cdf packages

Continuing the discussion, I have just played with a custom CDF  
package (without these functions) and gcrma, and I can confirm that  
gcrma does use the xy2i in "compute.affinities" and the functions  
"base.profiles*". What are the plans regarding storing the chip  
dimensions somewhere?

Kasper

On Mar 26, 2007, at 5:16 PM, Laurent Gautier wrote:

2007/3/27, Henrik Bengtsson <hb at stat.berkeley.edu>:

Hi,

may I suggest to leave the package framework for "CDF package" an  
move
to an object-oriented framework.  Define a class AffyCdf class that
provide various access methods, e.g. indexToCoordinate() and
coordinateToIndex().  Let subclass AffyCdfPackage extend AffyCdf such
that its methods queries existing CDF package. Yet another class
AffyCdfFile works directly towards CDF files.  AffyCdfDb works  
towards
a data base, and so on.  All provide the same API.

In the object-oriented world, I think that this would make "AffyCdf"
an interface
that classes that AffyCdfFile would implement. I am not certain of  
how S4 offers
this kind of pattern.

What about having AffyCdfEnvironment rather than AffyCdfPackage ?
The idea is that Cdf definitions can exist inside and outside  
packages:
one may want to modify and try out a Cdf during an R session without
having to create / install / load the package.

Migration: First step would be add an object of class AffyCdfPackage
inside CDF packages, alternatively provide an additional way of
loading CDF packages, such that there is an object, say with the same
name as the "clean" chip type (CDF) name, e.g. 'hgu133a'.
Then packages start using the AffyCdfPackage API (instead of  
accessing
the CDF package environment directly), e.g. cdf <- hgu133a; idx <-
coordinateToIndex(cdf, xy).  Both CDF package and AffyCdf object
coexists for the price of one until all packages migrated.  When that
is done, we have much more flexibility.

An intermediate step would be to have AffyCdfEnvironment inherit from
"environment",
and just define methods "coordinateToIndex" and inverse with an
"environment" signature.
This way one could both have an environment the old way for the
transition period, as
well as a class.
(OO in R is not quite like in Java, as methods work through "generic"
functions.)


L.

With the above design it would be a piece of a cake to add a
AffyCdfFile class to query CDF files on the fly using affxparser.

/Henrik


On 3/26/07, Wolfgang Huber <huber at ebi.ac.uk> wrote:

Hi Jim,

I think Francesco's point is valid.
The chip design is independent of particular instances of data, and
includes the size of the chip. That the chip size resides in the  
data
container (AffyBatch) and all the other geometry annotation in  
the CDF
is incoherent. So, when the i2xy and xy2i functions go, can't we  
have
this annotation constant defined in the CDF package as well, so  
that you
can say, for example

  xy <- indices2xy(i, cdf=hgu133acdf)

Btw, the reason for putting the xy2i and i2xy functions into the CDF
packages was that these mapping functions are really a chip-geometry
annotation. It was a mistake to export them like that, though, they
should always only have been visible as hgu133acdf::xy2i() or
hgu133acdf$xy2i().

  Best wishes
  Wolfgang

Hi Francesco,

Francesco Ferrari wrote:

PS: I know that no package uses these functions, but we use  
them to
produce data for another package (work is still in progress).  
We could
use indices2xy() and xy2indices() functions from affy package,  
but the
value for "nr" parameter is required.

I'm confused by this. What does your package do with a cdf  
package that
doesn't explicitly involve an AffyBatch?

Best,

Jim