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

Fri Apr 13 13:10:20 CEST 2007

The check might well fail in that case.
The rationale for that test was to be very sensitive.
Having not tried it on custom arrays, I would indeed make
no claim on its specificity.

Anyway, it looks like we all agree that one should not count
on this to infer chip dimensions.
I see that John has already implemented dimensions as package
members, and hopefully we all agree that this is the easiest
and safest route at the moment.

L.

PS: Anyone one with input on how to improve the test discussed
is of course more than welcome.

2007/4/13, Kasper Daniel Hansen <khansen at stat.berkeley.edu>:
> A custom CDF file might not use all the probes on the array - I have
> no idea if the ones offered by Bioconductor does it. In that case,
> the check (might) fail.
>
> Kasper
>
> On Apr 12, 2007, at 8:18 AM, Henrik Bengtsson wrote:
>
> > 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?
> >
> > /Henrik
> >
> > 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
> >> ".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
> >>> *****************************************
> >>>
> >>
> >> _______________________________________________
> >> 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
>