[Bioc-devel] RFC: xy2i and i2xy in *cdf packages
Kasper Daniel Hansen
khansen at stat.Berkeley.EDU
Sat Apr 7 20:23:56 CEST 2007
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
On Mar 26, 2007, at 5:16 PM, Laurent Gautier wrote:
> 2007/3/27, Henrik Bengtsson <hb at stat.berkeley.edu>:
>> may I suggest to leave the package framework for "CDF package" an
>> 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
>> 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
> 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
>> 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
> 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"
>> 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.
>> 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
>>> container (AffyBatch) and all the other geometry annotation in
>>> the CDF
>>> is incoherent. So, when the i2xy and xy2i functions go, can't we
>>> 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
>>> Best wishes
>>>> 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?
>>> Bioc-devel at stat.math.ethz.ch mailing list
>> Bioc-devel at stat.math.ethz.ch mailing list
> Bioc-devel at stat.math.ethz.ch mailing list
More information about the Bioc-devel