I'd recommend that you use fitPLM rather than rmaPLM for these
purposes.
The reason why it is giving "reasonable results" in the first case and
an error in the other case, is that it is using your user supplied
weights in the earlier situation and trying to derive some sensible
weights based on the PLM model fit. Unfortunately rmaPLM does not
return
the information that is used to construct these but fitPLM does.
Ben
On Mon, 2005-09-05 at 13:51 +0300, Ron Ophir wrote:
> Hi
> I am analyzing affymetrix data having the following experimental
> design:
> > analysis$design
> Normal IOP IOPC
> L91RAE230 2.CEL 0 1 0
> L92RAE230 2.CEL 0 1 0
> L93RAE230 2.CEL 0 0 1
> L94RAE230 2.CEL 0 0 1
> L95RAE230 2.CEL 1 0 0
> L96RAE230 2.CEL 1 0 0
> and following contrasts
> > analysis$contrasts
> IOPC.IOP IOPC.Normal IOP.Normal
> Normal 0 -1 -1
> IOP -1 0 1
> IOPC 1 1 0
> The preprocessing was done using affyPLM packge
> analysis$data<-rmaPLM(analysis$raw)
> where analysis$raw is AfyyBatch object. Then I fitted the the model
> once with weighting matrix using AMP flags
> fm<-as.matrix(analysis$Flags!="A")
> analysis$fit<-lmFit(analysis$data,analysis$design,w=matrix(as.numeri
c(fm),dim(fm)[1],dim(fm)[2],dimnames=dimnames(fm)))
> and got a reasonable results and once without this matrix. What
was
> surprising is that fitting without the weighting matrix I got the
> following error message:
> > analysis$bayes<-eBayes(analysis$contrasts.fit)
> Error in ebayes(fit = fit, proportion = proportion, stdev.coef.lim =
> stdev.coef.lim) :
> No residual degrees of freedom in linear model fits
> I've checked the fit coeffecient matrix (analyis$fit object) and is
all
> NA.
> Does someone have an idea why? I did not applied any weighting
matrix
> for this fitting.
> Thanks
> Ron
>
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/bioconductor
>
> Hello
>
> I have a general question regarding pre-processing data using RMA.
>
> Due to memory constraints, I am using the function justRMA() instead
of
> fitPLM() for pre-processing my data (I have a couple of hundred
samples so
> far). Is there a way to obtain standard errors of expression
intensity
> estimates using this function? In this case, se.exprs returns a
matrix of
> NA's.
Unfortunately neither justRMA() nor rma() return SE values.
> Also, I understand that these functions do not readily provide
p-values
> associated with expression intensities (similar to the ones from
MAS5 for
> example). I am wondering what would be a good way to check data
quality in
> this case. Do you have any suggestions?
The P-values that MAS 5 produces are in relation to their presence
absence
calls (not the expression value itself). There is no similar analog
for
RMA in this sense. Generally speaking the MAS5 presence/absence calls
are
pretty decent (although the MAS5 expression values have their faults)
and
you could use these with RMA expression values if you wished without
much
problem. That said, the reason people typically use these is to screen
out
"noisy" genes at the low absolute intensity level. This tends to not
be a
problem with RMA expression values.
You could do preliminary quality examination of things like chip
pseudo
images using recent versions of RMAExpress found at:
http://www.stat.berkeley.edu/~bolstad/RMAExpress/RMAExpress.html
The latest alpha versions support extremely large datasets on memory
limited systems. Unfortunately things like RLE and NUSE (which are in
affyPLM) are not currently implemented in RMAExpress.
>
>
>>>> Gordon Smyth <smyth at="" wehi.edu.au=""> 09/07/05 5:06 AM >>>
>
>>Date: Mon, 05 Sep 2005 13:51:38 +0300
>>From: "Ron Ophir" <ron.ophir at="" weizmann.ac.il="">
>>Subject: [BioC] LIMMA No residual using rmaPLM
>>To: <bioconductor at="" stat.math.ethz.ch="">
>>Message-ID: <s31c4d86.078 at="" wisemail.weizmann.ac.il="">
>>Content-Type: text/plain
>>
>>Hi
>>I am analyzing affymetrix data having the following experimental
>>design:
>> > analysis$design
>> Normal IOP IOPC
>>L91RAE230 2.CEL 0 1 0
>>L92RAE230 2.CEL 0 1 0
>>L93RAE230 2.CEL 0 0 1
>>L94RAE230 2.CEL 0 0 1
>>L95RAE230 2.CEL 1 0 0
>>L96RAE230 2.CEL 1 0 0
>> and following contrasts
>> > analysis$contrasts
>> IOPC.IOP IOPC.Normal IOP.Normal
>>Normal 0 -1 -1
>>IOP -1 0 1
>>IOPC 1 1 0
>>The preprocessing was done using affyPLM packge
>>analysis$data<-rmaPLM(analysis$raw)
>>where analysis$raw is AfyyBatch object. Then I fitted the model
>>once with weighting matrix using AMP flags
>>fm<-as.matrix(analysis$Flags!="A")
>>analysis$fit<-lmFit(analysis$data,analysis$design,w=matrix(as.numeri
c(fm),dim(fm)[1],dim(fm)[2],dimnames=dimnames(fm)))
>> and got a reasonable results and once without this matrix. What
was
>>surprising is that fitting without the weighting matrix I got the
>>following error message:
>> > analysis$bayes<-eBayes(analysis$contrasts.fit)
>>Error in ebayes(fit = fit, proportion = proportion, stdev.coef.lim =
>>stdev.coef.lim) :
>> No residual degrees of freedom in linear model fits
>>I've checked the fit coeffecient matrix (analyis$fit object) and is
all
>>NA.
>>Does someone have an idea why? I did not applied any weighting
matrix
>>for this fitting.
>
>As Ben has already explained, you are implicitly using a weighting
matrix
>here because your 'PLMset' object contains a slot 'se.chip.coefs'
from
>which limma is attempting to construct probe-set weights. (Basically
the
>weight for each expression value is the inverse squared se, with some
>moderation to prevent absurd values.) You can easily turn this off by
using
>
> lmFit(..., weights=NULL)
>
>The philosophy is this: If the se.chip.coefs slot is empty, then
limma
will
>take the se's and hence the weights to be all equal. If however this
slot
>is set to be a matrix with entirely NA values, then limma will assume
(and
>this is the crucial thing) that the se's are not only missing but
>non-ignorable. Hence it passes NA weights to the lmFit and hence you
end up
>with no useful data.
>
>I am open to suggestion that limma should do something different. My
>feeling which motivates the current behaviour is that slots in data
objects
>are only set (or should only be set) when they really mean something.
Hence
>they should not be ignored without specific direction to do so, even
if
>they contain NA values.
>
>Gordon
Thanks Gordon and Ben
Conceptually, you right Gordon that is the idea of OOP. The
responsible
for the data is on the object encapsulates them and if there are some
NAs they may have meaningful. However if
sumapplyis.na(PLMset at se.chip.coefs),1,sum)) equals to
dim(PLMset at se.chip.coefs)[1]*dim(PLMset at se.chip.coefs)[2]
it might indicate a logical bug and hence no use for such data.
I'll be aware of this next time.
Ron
>
>>Thanks
>>Ron
>