[BioC] Bug in GSVA with methods other than default?

Fri Feb 21 14:39:45 CET 2014

Ahh yes, I apologise, too quick in my testing. It's obviously more 
ExpressionSet- specific.

Here's a reproducible example for you. I'm attaching a toy expression 
matrix (any will do), in this case for probes from an Illumina chip. 
Then do the following:

example<- as.matrix(read.table("example.txt"))
eset_example<- ExpressionSet(example, annotation='illuminaHumanv4')
pdata_example<- data.frame(class=c(rep('class1', 5), c(rep('class2', 5))))
rownames(pdata_example)<- letters[1:10]
pData(eset_example)<- pdata_example
gsva_es<- gsva(eset_example, c2BroadSets , mx.diff=1, method='plage')

Result:

Error in eSco$es.obs : $ operator is invalid for atomic vectors

Jon

On 21/02/2014 13:11, Sonja Haenzelmann wrote:
> On Fri, Feb 21, 2014 at 1:55 PM, Jonathan Manning
> <Jonathan.Manning at ed.ac.uk>  wrote:
>> gsva_es<- gsva(y, geneSets, mx.diff=1, method='plage')$es.obs
> For plage you simply leave the $es.obs out. You only need to put it
> when you use method = "gsva"
>
> Like this:
>
>   gsva_es<- gsva(y, geneSets, mx.diff=1, method='plage')
>
> On Fri, Feb 21, 2014 at 1:55 PM, Jonathan Manning
> <Jonathan.Manning at ed.ac.uk>  wrote:
>> Hi Sonja,
>>
>> Thanks.
>>
>> The error occurs in ALL situations where an alternate method is provided.
>> Tweaking your own example does the trick, try this modification to
>> reproduce:
>>
>> gsva_es<- gsva(y, geneSets, mx.diff=1, method='plage')$es.obs
>>
>> Jon
>>
>>
>> On 21/02/2014 12:34, Sonja Haenzelmann wrote:
>>
>> Hi Jonathan.
>>
>> Justin, the co author of the paper added the bootstrapping. As far as
>> I know it does not work. There was an earlier post on this in the
>> mailng list.
>>
>> How does your input look like? gsva can handle expression set or
>> matrix, nothing else.
>>
>> Did I answer your question? If not, please provide me a *reproducible*
>> example, otherwise I cannot help you :/
>>
>> Cheers
>> Sonja
>>
>>
>> On Fri, Feb 21, 2014 at 1:19 PM, Jonathan Manning
>> <Jonathan.Manning at ed.ac.uk>  wrote:
>>
>> Hi Sonja,
>>
>> Thanks for the quick reply, but I don't think I've made myself clear. I'm
>> aware that gsva() returns that list, from which you need to extract es.obs,
>> but the error lies internal to the method when that list is being
>> constructed.
>>
>> For example, when I run:
>>
>> gsva_es<- gsva(my.expressionset, c2BroadSets, verbose=TRUE,
>> method='plage')$es.obs
>>
>> I get the error I described:
>>
>> Error in eSco$es.obs : $ operator is invalid for atomic vectors
>>
>>  From what I can determine, GSVA:::.gsva() (called from gsva()) returns the
>> results of PLAGE et al directly, as matrices, rather than doing
>> bootstrapping etc and making a list. But the top-level gsva() seems to
>> expect a list with the results of bootstrapping etc, as happens in the
>> default case. The lines from gsva() in question are:
>>
>> eSco<- GSVA:::.gsva(Biobase::exprs(expr), mapped.gset.idx.list,
>>
>>                           method, rnaseq, abs.ranking, no.bootstraps,
>> bootstrap.percent,
>>
>>                           parallel.sz, parallel.type, mx.diff, tau, kernel,
>>
>>                           verbose)
>>
>>      eScoEset<- expr
>>
>>      Biobase::exprs(eScoEset)<- eSco$es.obs
>>
>>
>>
>>      Biobase::annotation(eScoEset)<- ""
>>
>>      return(list(es.obs = eScoEset, bootstrap = eSco$bootstrap,
>>
>>                  p.vals.sign = eSco$p.vals.sign))
>>
>> If I specify method='plage', then 'eSco' is a matrix and 'eSco$es.obs' won't
>> work.
>>
>> Is that clearer? It seems that bootstrapping doesn't happen right now where
>> method is PLAGE etc- should that be the case?
>>
>> Jon
>>
>>
>>
>> On 21/02/2014 12:01, Sonja Haenzelmann wrote:
>>
>> gsva_es<- gsva(y, geneSets, mx.diff=1)$es.obs
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
-------------- next part --------------
a b c d e f g h i j
ILMN_1762337 6.32865812777011 6.37049702144715 6.34266089225608 6.28507480631747 6.35111452232252 6.26421372101437 6.24889447054952 6.33037496506692 6.23735433279223 6.31212898618416
ILMN_2055271 6.47368159659659 6.44672705061977 6.39518159550302 6.41338040918528 6.40752208195447 6.42306274123057 6.36411855874604 6.32371394985614 6.48978316699854 6.36565652284042
ILMN_1736007 6.34156200564141 6.30237234239757 6.40365127392528 6.29791506928539 6.34185621865158 6.29636555366412 6.39441343957831 6.2748016117617 6.35383762854263 6.32781123835757
ILMN_2383229 6.32941919225004 6.2644947306216 6.2638163435598 6.27855087086384 6.30239994029713 6.28796072938563 6.27590363429755 6.3647678628056 6.25139686572329 6.30585207292445
ILMN_1806310 6.37468922598334 6.25420265270942 6.42369636972899 6.43881497603307 6.33905981257491 6.45655920410559 6.33790458264325 6.34182224654541 6.35340774359828 6.37143307012284
ILMN_1779670 6.30299299878235 6.25469674569101 6.28908124067904 6.27373448235854 6.26212368059074 6.28792710587094 6.376739164415 6.34268088775031 6.28022040788398 6.31721290353048
ILMN_1653355 6.29784086006903 6.29285540455235 6.31380298265451 6.29915148464551 6.35809513832342 6.30376054611937 6.27598235348418 6.26479076811505 6.33670294836481 6.26998506846869
ILMN_1717783 6.20093824279964 6.25599610353395 6.16784879248009 6.22608136769709 6.3049367631371 6.26057402739548 6.26021031930376 6.2310949969526 6.27469199858706 6.29466517419505
ILMN_1705025 6.32372057290575 6.37302695408337 6.375120399767 6.40581943804904 6.48779737195469 6.31552830835791 6.28982563624157 6.33278151940857 6.33377793662168 6.41409683356832
ILMN_1814316 6.74116605514272 6.95829086433335 7.14922543586468 7.03001122462025 6.45981886662056 6.44515062245034 6.24100696197496 6.33327743862991 6.32077633091863 6.31763229552447
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/bioconductor/attachments/20140221/7baee131/attachment.pl>