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

[lgautier at altern.org]

Thanks for having the time and energy to fix that.

If S4 allows one to create a class that inherits directly from
"environment", that might be an elegant way to go for a first step.
The dimensions can be stored as attributes.
(Across R versions, it used to be allowed, not allowed, then allowed
again... I do not know the current status).

Storing attributes directly in a package can lead to complications
(like dealing with the case where people want to use mapping environments
that are not in a package).

Cheers,


Laurent


> I will be modifying makecdfenv probably next week to store the chip
> dimensions in each cdf package. However, since gcrma depends on affy it
> is probably more logical to simply use indices2xy() and xy2indices().
>
> Best,
>
> Jim
>
> Kasper Daniel Hansen wrote:
>> 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
>>
>> _______________________________________________
>> Bioc-devel at stat.math.ethz.ch mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> James W. MacDonald, MS
> Biostatistician
> UMCCC cDNA and Affymetrix Core
> University of Michigan
> 1500 E Medical Center Drive
> 7410 CCGC
> Ann Arbor MI 48109
> 734-647-5623
>
>
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should not
> be used for urgent or sensitive issues.
>
> _______________________________________________
> Bioc-devel at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> !DSPAM:461821d8315331217419413!
>
>
>