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

[Francesco Ferrari]

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
".lgExtraParanoia"

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
coordinates



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.

Best,
Francesco






> 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
> *****************************************
>