Bug in function i2xy
1
0
Entering edit mode
@wolfgang-huber-3550
Last seen 5 weeks ago
EMBL European Molecular Biology Laborat…
Hi all, there is a bug in the function i2xy() that is contained in each cdf package. This function (as well as another function, indices2xy) is not currently used in any of the code of the affy package. Thus, the bug will only affect user programs that explicitely call this function. You may savely ignore this message if you have never heard about this function. Background: ----------- cdf packages are used in conjunction with the affy package and contain chip-type specific layout information. The function is intended to convert the row index i that addresses the data within an AffyBatch object into the x- and y-coordinates of that probe on the chip. For example, for an hgu95av2 chip, x=0..639, y=0..639 and i=1..409600. There is a 1:1 mapping between each (x,y)-pair and the index i. The bug affects the return value of that function for i=n, 2n, 3n, etc., where n is the number of rows on the chip (n=640 in the example above). What to do: ----------- For the time being, please do not use this function, or overwrite it manually with i2xy = function(i) cbind((i-1) %% n, (i-1) %/% n) where n is the number of rows for your chip. We will put up new CDF packages with the correct function on the website, but this may be a couple of days. Furthermore: ------------ The present, defective definition of the function is i2xy = function (i) cbind(i %% n - 1, i %/% n) A similar bug has also been found in the indices2xy() function from the package affy. The inverse function xy2i() is correct. My apologies to everyone whose work has been affected by this bug. Many thanks to Brian Peyser who reported the bug! Best regards ------------------------------------- Wolfgang Huber Division of Molecular Genome Analysis German Cancer Research Center Heidelberg, Germany Phone: +49 6221 424709 Fax: +49 6221 42524709 Http: www.dkfz.de/mga/whuber
Cancer cdf probe affy Cancer cdf probe affy • 678 views
ADD COMMENT
0
Entering edit mode
Laurent Gautier ★ 2.3k
@laurent-gautier-29
Last seen 9.7 years ago
I owe my share of 'sorry-sorry-sorry-for-the-buggy-functions' too... The fix suggested for xy2i does not make it for xy2indices. For xy2indices the patch should be: indices2xy <- function(i, nr = NULL, cel = NULL, abatch = NULL) { if (any(i) <= 0) stop("Indices must start at 1 (please refer to the help file) !") ct <- sum(c(is.null(nr), is.null(cel), is.null(abatch))) if (ct != 2) stop("One and only one of 'nr', 'cel', 'abatch' should be specified.") if (!is.null(cel)) nr <- nrow(intensity(cel)) if (!is.null((abatch))) nr <- nrow(abatch) x <- i%%nr x[x == 0] <- nr y <- (i-1)%/%nr + 1 xy <- cbind(x, y) colnames(xy) <- c("x", "y") return(xy) } (the "offset + 1" story is mentioned in the main vignette and in the help file for the function. Try 'example(plotLocation)' for a visual.). I would like to add that this is a very minor bug (that why it escaped several cross-checks). That should not influence much results: the wrong 'XYs' are on one edge of the array. There should be any probes related to genes in that place (well, or so I observed with few chip types so far... I'd be interested to know if this is still the case with the newest chip types (U133A is among them for me)). Unless you were doing something with those border probes (some of them are controls, as outlined in a paper about the 'affy' pack in Bioinformatics (to appear)), you should be safe. Regards, L. On Wed, Aug 20, 2003 at 02:35:15PM +0200, w.huber@dkfz-heidelberg.de wrote: > Hi all, > > there is a bug in the function i2xy() that is contained in each cdf > package. > > This function (as well as another function, indices2xy) is not currently > used in any of the code of the affy package. Thus, the bug will only > affect user programs that explicitely call this function. You may savely > ignore this message if you have never heard about this function. > > Background: > ----------- > cdf packages are used in conjunction with the affy package and contain > chip-type specific layout information. The function is intended to convert > the row index i that addresses the data within an AffyBatch object into > the x- and y-coordinates of that probe on the chip. For example, for an > hgu95av2 chip, x=0..639, y=0..639 and i=1..409600. There is a 1:1 mapping > between each (x,y)-pair and the index i. > > The bug affects the return value of that function for i=n, 2n, 3n, etc., > where n is the number of rows on the chip (n=640 in the example above). > > What to do: > ----------- > For the time being, please do not use this function, or overwrite it > manually with > > i2xy = function(i) cbind((i-1) %% n, (i-1) %/% n) > > where n is the number of rows for your chip. We will put up new CDF > packages with the correct function on the website, but this may be a > couple of days. > > > Furthermore: > ------------ > The present, defective definition of the function is > i2xy = function (i) cbind(i %% n - 1, i %/% n) > > A similar bug has also been found in the indices2xy() function from the > package affy. > > The inverse function xy2i() is correct. > > My apologies to everyone whose work has been affected by this bug. Many > thanks to Brian Peyser who reported the bug! > > Best regards > > ------------------------------------- > Wolfgang Huber > Division of Molecular Genome Analysis > German Cancer Research Center > Heidelberg, Germany > Phone: +49 6221 424709 > Fax: +49 6221 42524709 > Http: www.dkfz.de/mga/whuber > > _______________________________________________ > Bioconductor mailing list > Bioconductor@stat.math.ethz.ch > https://www.stat.math.ethz.ch/mailman/listinfo/bioconductor -- -------------------------------------------------------------- currently unspecified location -------------------------------------------------------------- Laurent Gautier CBS, Building 208, DTU PhD. Student DK-2800 Lyngby,Denmark tel: +45 45 25 24 89 http://www.cbs.dtu.dk/laurent
ADD COMMENT

Login before adding your answer.

Traffic: 418 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6