Skip to content

[Bioc-devel] problem w/ "exprs<-" method and LumiBatch objects

8 messages · Martin Morgan, Robert Castelo, Levi Waldron +1 more

Original
Robert Castelo
# 
dear maintainers of Biobase and lumi,

this is a question raised from a different thread a few days ago here:

https://stat.ethz.ch/pipermail/bioc-devel/2014-January/005129.html

the matrix of genes by samples expression values in an 'ExpressionSet' 
object can be accessed and replaced with the "exprs<-" method and this 
changes automatically the dimension of the 'ExpressionSet' object as 
illustrated in the following example:

library(Biobase)

data(sample.ExpressionSet)
dim(sample.ExpressionSet)
Features  Samples
      500       26
exprs(sample.ExpressionSet) <- matrix(rnorm(2600), nrow=100)
dim(sample.ExpressionSet)
Features  Samples
      100       26

however, this does not seem to be happening with 'LumiBatch' objects 
which are an extension of 'ExpressionSet' objects:

library(lumi)

data(example.lumi)
dim(example.lumi)
Features  Samples
     8000        4
exprs(example.lumi) <- matrix(rnorm(400), nrow=100)
dim(example.lumi) ## NOTE NOW THAT DIMENSION DOES NOT CHANGE!!
Features  Samples
     8000        4

a couple of diagnostics are that the expression matrix itself it does 
seem to have been replaced:

dim(exprs(example.lumi))
[1] 100   4

and the "exprs<-" method does not seem to be explicitely defined for 
'LumiBatch' objects:

showMethods("exprs")
Function: exprs (package Biobase)
object="AffyBatch"
object="ExpressionSet"
object="MethyLumiSet"
object="SnpSet"

so i guess something is not working at the interaction of 
Biobase::exprs<- and LumiBatch-class, whether this should be fixed at 
Biobase or lumi, have no idea.

thanks!
robert.
ps: sessionInfo()
 > sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_US.UTF8       LC_NUMERIC=C 
LC_TIME=en_US.UTF8
  [4] LC_COLLATE=en_US.UTF8     LC_MONETARY=en_US.UTF8 
LC_MESSAGES=en_US.UTF8
  [7] LC_PAPER=en_US.UTF8       LC_NAME=C                 LC_ADDRESS=C 

[10] LC_TELEPHONE=C            LC_MEASUREMENT=en_US.UTF8 
LC_IDENTIFICATION=C

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods 
   base

other attached packages:
[1] lumi_2.14.1        Biobase_2.22.0     BiocGenerics_0.8.0 
vimcom_0.9-92
[5] setwidth_1.0-3     colorout_1.0-1

loaded via a namespace (and not attached):
  [1] affy_1.40.0            affyio_1.30.0          annotate_1.40.0
  [4] AnnotationDbi_1.24.0   base64_1.1             beanplot_1.1
  [7] BiocInstaller_1.12.0   biomaRt_2.18.0         Biostrings_2.30.1
[10] bitops_1.0-6           BSgenome_1.30.0        bumphunter_1.2.0
[13] codetools_0.2-8        colorspace_1.2-4       DBI_0.2-7
[16] digest_0.6.4           doRNG_1.5.5            foreach_1.4.1
[19] genefilter_1.44.0      GenomicFeatures_1.14.2 GenomicRanges_1.14.4
[22] grid_3.0.2             illuminaio_0.4.0       IRanges_1.20.6
[25] iterators_1.0.6        itertools_0.1-1        KernSmooth_2.23-10
[28] lattice_0.20-24        limma_3.18.7           locfit_1.5-9.1
[31] MASS_7.3-29            Matrix_1.1-1.1         matrixStats_0.8.14
[34] mclust_4.2             methylumi_2.8.0        mgcv_1.7-27
[37] minfi_1.8.9            multtest_2.18.0        nleqslv_2.1
[40] nlme_3.1-113           nor1mix_1.1-4          pkgmaker_0.17.4
[43] preprocessCore_1.24.0  RColorBrewer_1.0-5     RCurl_1.95-4.1
[46] registry_0.2           reshape_0.8.4          R.methodsS3_1.6.1
[49] rngtools_1.2.3         Rsamtools_1.14.2       RSQLite_0.11.4
[52] rtracklayer_1.22.0     siggenes_1.36.0        splines_3.0.2
[55] stats4_3.0.2           stringr_0.6.2          survival_2.37-4
[58] tools_3.0.2            XML_3.98-1.1           xtable_1.7-1
[61] XVector_0.2.0          zlibbioc_1.8.0
Martin Morgan
#
On 01/10/2014 12:07 AM, Maintainer wrote:
actually, the expression values have been replaced

 > dim(exprs(example.lumi))
[1] 100   4

but the object is no longer valid

 > validObject(example.lumi)
Error in validObject(example.lumi) :
   invalid class "LumiBatch" object: row numbers differ for assayData members

This is also true of the ExpressionSet example (the object is no longer valid), 
it's just that the dims are taken from a different location so reflect the addition.

The user should be providing expression values with the same dimensions (and 
with the same dimnames) as the original. I think the intended use case was more 
along the lines of replacing the expression matrix with say a transformed 
version, exprs(x) = log(exprs(x)).

Obviously Biobase shouldn't be allowing the user to see an invalid object, but 
the design of the package does not make it easy to enforce this; I'll work on 
providing something more robust, but the end result of trying the above 
assignment will be an error.

Martin

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Robert Castelo
    

    

      
      #
    

  


  

      
hi Martin,

along the lines of the situation that Kasper describes, my use case is 
that GSVA transforms a matrix of expression values of genes-by-samples 
into a matrix of summary expression values of pathways-by-samples. When 
the input is an 'ExpressionSet' object, GSVA simply does something like 
this (sketched):

pwysbysamplesmatrix <- gsva(exprs(inputGeneExpressionSet), geneSets)

outputPwyEset <- inputGeneExpressionEset
exprs(outputPwyEset) <- pwysbysamplesmatrix
annotation(outputPwyEset) <- ""

so the first dimension of the ExpressionSet object is reduced from tens 
of thousands of genes to hundreds or thousands of pathways (=gene sets).

i thought this was a valid way to do it, let me know what should be the 
correct route.

robert.

        
On 01/10/2014 03:59 PM, Kasper Daniel Hansen wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Robert Castelo
    

    

      
      #
    

  


  

      
hi Kasper,

you're right. i should have done this upfront, this was too much S4 
magic to be true :)

cheers,
robert.

        
On 1/10/14 5:14 PM, Kasper Daniel Hansen wrote: