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

[Kasper Daniel Hansen]

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
>>>
>>> _______________________________________________
>>> Bioc-devel at stat.math.ethz.ch mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> _______________________________________________
>> Bioc-devel at stat.math.ethz.ch mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel