[Bioc-devel] RFC: xy2i and i2xy in *cdf packages
hb at stat.berkeley.edu
Thu Apr 12 17:18:43 CEST 2007
One could back up this by a calculation based on the assumption that
there are (typically?) equal number of rows as columns on Affy arrays.
Anyone know of a counter example?
On 4/12/07, Francesco Ferrari <ferrari.francesco at unimore.it> wrote:
> I found an interesting "trick" adopted within the package mtachprobes
> to solve this problem...
> i.e. obtaining chip dimensions information from current versions of
> CDF packages.
> Within the package "matchprobes" there's a function named
> If you read this function code you can find the following lines:
> tab = table(mm1 - pm1)
> sizex = as.numeric(names(tab))[max(tab) == tab]
> pm2 = pt$y * sizex + pt$x + 1
> "mm1" is a vector containing MM probes indexes (obtained from CDF package)
> "pm1" is a vector containing PM probes indexes (obtained from CDF package)
> Then chip dimension (i.e. "sizex") is obtained as the maximum difference between
> MM and PM probes indexes. This is based on the assumption that PM and
> MM probe are usually next to each other on the chip
> at same x coordinate and at adjacent y coordinates.
> The last line is equal to function "xy2i()" since "pt" is a data.frame
> containing probe sequences information
> and columns x and y (i.e. vectors "pt$x" and "pt$y") contain xy probes
> However I agree with the fact that this could not be the final solution
> and that having dim environment accessible within CDF packages is a
> better solution.
> > Date: Wed, 11 Apr 2007 16:53:55 -0400
> > From: "James W. MacDonald" <jmacdon at med.umich.edu>
> > Subject: Re: [Bioc-devel] RFC: xy2i and i2xy in *cdf packages
> > To: Seth Falcon <sfalcon at fhcrc.org>
> > Cc: bioc-devel at stat.math.ethz.ch
> > Message-ID: <461D4AE3.2070501 at med.umich.edu>
> > Content-Type: text/plain; charset="utf-8"; format=flowed
> > Seth Falcon wrote:
> > > Wolfgang Huber <huber at ebi.ac.uk> writes:
> > >
> > >
> > >>Hi,
> > >>
> > >>Rather than make up these new dimension objects in the CDF package,
> > >>why not teach the affy:indices2xy function to reach into the
> > >>appropriate CDF package and grab the *unexported*, existing i2xy
> > >>function in order to do its thing, and the affy:xy2indices to grab the
> > >>*unexported* xy2i function? Seems like the least intrusive way to do
> > >>things, and more flexible.
> > >
> > >
> > > I don't think we should change the visibility of the xy2i functions
> > > without going through the deprecation cycle.
> > >
> > > But in general, I like your suggestion. Teaching affy to grab the
> > > appropriate function seems sensible. Personally, I think it is fine
> > > to have these functions exported. You can still get the right one
> > > when using affy::xy2indices. Symbol masking is a fact of R.
> > >
> > > But having the dimensions accessible in the CDF package also makes
> > > sense to me and is easy so I'm still in favor of adding hgu95av2dim.
> > > And the xy2i and i2xy functions should use it...
> > The functions in affy don't care what happens with xy2i and i2xy since
> > they don't use them (they get dimensions directly from the AffyBatch).
> > The only functions that care are those that don't have an AffyBatch to
> > query.
> > So, unless there are any objections*, I will add the little dim env to
> > the cdf packages any any functions that need this info (and don't have
> > an AffyBatch to query) will have to learn to use it.
> > *By objections, I mean 'This will completely break my code and destroy
> > my life'. The cdf packages are nearing the end of their shelf lives,
> > soon to be replaced with SQLite packages, so arguments about stylistic
> > differences and 'How things should be done' are counterproductive,
> > especially given how close we are to release. Also, remember that xy2i
> > and i2xy are only being _deprecated_. Anybody who uses these functions
> > has > 6 months from now to make changes.
> > Best,
> > Jim
> > --
> > James W. MacDonald, M.S.
> > Biostatistician
> > Affymetrix and cDNA Microarray Core
> > University of Michigan Cancer Center
> > 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 mailing list
> > Bioc-devel at stat.math.ethz.ch
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > End of Bioc-devel Digest, Vol 37, Issue 8
> > *****************************************
> Bioc-devel at stat.math.ethz.ch mailing list
More information about the Bioc-devel