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

Wolfgang Huber huber at ebi.ac.uk
Tue Mar 27 11:42:41 CEST 2007

Hi Henrik, Benilton, Rafa,

who has the energy to do this and how does this concord with the work on
oligo? Is oligo intended to replace affy (and if yes, when)? If yes, I
am not sure it would be worthwhile to spend much time improving affy,
and we'd just maintain it with existing functionality for a few more
releases. If no, then of course, further developing affy is an important

Best wishes

PS: Btw, one can argue that packages are objects, since they offer
aspects of modularity, encapsulation and inheritance. I agree with
Henrik that a design using the S4 object system could be more extensible
- but basic OOP ideas underlie the annotation package system, which in
addition offers good tools for distribution, versioning and documentation.

Wolfgang Huber  EBI/EMBL  Cambridge UK  http://www.ebi.ac.uk/huber

Henrik Bengtsson wrote:
> 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.
> 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.
> 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

More information about the Bioc-devel mailing list