[BioC] Integrating Codelink data with bioconductor (using affyand limmafunctions)

[Gordon Smyth]

At 09:35 PM 25/04/2005, Diego Díez Ruiz wrote:
>Dear Gordon,
>
>Thanks for your response. I will use the data as early but, What do you 
>think it could affect more to normalization process: Some points assigned 
>as NA values or some point with lowers A values as one of the intensitues 
>was assigned a value of say 0.01?

Unless you're doing much more than I think you are, you must avoid NAs at 
all costs. If you have to live with low intensities, then so be it.

>I'd let you see my class definition and parser of course. This is really 
>the first time a make use of classes and store all things as an R package 
>so I thought that the best way to make something usable and quick without 
>having to read completly "writting R extensions" was using others packages 
>to learn (that is one of the greatness of opensource :). Of course I will 
>have to read it one day.
>Briefly:
>1. The parser read exported txt files from codelink software.

I've never seen Codelink output, but my understanding is that it is 
essentially just ImaGene output. Is that not correct?

Gordon

>  It works fine with 3 different chips so I think it should work fine with 
> all types. A problem is that exported text data have custom fields (and 
> you can chose within all fields including Raw_intensity, 
> Median_foreground, etc) So it could be possible to found files with 
> missing fields not exported. I know that it is possible to export as XML 
> but a didn't try that yet.
>
>2. The class definition is very simple. I based it in RGlist and used 
>almost all redefinitions of dim() as.matrix() etc... that you use in 
>limma. I also based a subsetting system in the one used in AffyBatch 
>objects in affy. A Codelink object stores as a list 3 matrices. One of 
>intensities, one of Flags and one last with probe name and probe type. I 
>actually named it "val" "flags" and "info" slots but i don't thing they 
>are appropiate so this week I want to import all possible fields and name 
>it as they are called in the exported files. I probably too make 
>comprobation about the fields present and warn or error if a *must have* 
>field is missing.
>
>When I have a more clear and clean code I will not have any problems in 
>let you see it.
>
>D