Hi Shraddha,
I am also unable to reproduce this in RStudio Server Version 1.4.1106 using
our Bioc 3.12 Docker container.
There may be some inadvertent version mixing based on the error.
Please make sure the `BiocManager::valid()` is returning `TRUE`.
---
> brca <- curatedTCGAData::curatedTCGADa
On Thu, Jun 3, 2021 at 9:11 AM Shraddha Pai
wrote:
> Hi Vincent,
> Thank you. This is for a workshop with pre-selected versions of R/BioC, so
> I have no control over the release.
> Will try redownloading the data. I just found it puzzling that the
> identical code works in command-line R (ie sta
Hi Vincent,
Thank you. This is for a workshop with pre-selected versions of R/BioC, so
I have no control over the release.
Will try redownloading the data. I just found it puzzling that the
identical code works in command-line R (ie started from bash shell) but not
in Rstudio but perhaps they have
You are behind the release and should update. However, with a reasonably
close
instance I can't reproduce your error. I had a flaky download at one
point; you might
want to reconstitute your brca data.
> brca = curatedTCGAData("BRCA", c("miRNASeqGene", "mRNAArray", "RPPAArray",
> "Methylation_m
Hello BioC community,
Calling assays() on a SummarizedExperiment object has suddenly started
giving me this error in Rstudio but not on command-line R. I have been
trying to solve this for a few hours without luck and any help would be
great. sessionInfo() output below and this is Rstudio 1.4.
Th
Please try re-installing BiocGenerics. It might also be necessary to reinstall
other packages in 'XVector', 'S4Vectors', 'IRanges', "GenomicRanges'
I believe the problem is that the 'lengths' generic was implemented in base R
and then removed from BiocGenerics, but that one or more of your insta
Thank you for the advice! I checked validity of the packages and
reinstalled "too new" once appearing in the warning.
However, I could not install a correct BiocParallel version using
if (!requireNamespace("BiocManager", quietly = TRUE))
install.packages("BiocManager")
BiocManager::install("Bi
A good place to start is to verify that your packages are all from the same
release
BiocManager::valid()
and then if that is not revealing make sure to start a new R session, attach
SummarizedExperiment, and report the output of sessionInfo().
Martin
On 12/1/18, 8:16 PM, "Bioc-devel on behal
Hi everyone,
I am working with R 3.6 on macOS mojave, and I installed the
SummarizedExperiment from BiocManager 3.9. Whenever the package is loaded I
get the following warning:
Warning: multiple methods tables found for ‘lengths'
Did anyone encounter this problem? Any suggestions for fixes?
Bes
Hi Felix,
Nice catch. This can actually be reproduced with just:
> example(SummarizedExperiment)
> metadata(se0) <- list(aa="aa")
> se0[1 , ] <- se0[1 , ]
> metadata(se0)
$aa
[1] "aa"
$aa
[1] "aa"
The culprit is this line:
ans_metadata <- c(metadata(x), metadata(value))
in
Hi all,
I got a bit of weird behaviour with SummarizedExperiments in Bioc 3.6 and
3.7. I suppose it is a bug, but I might be wrong, since the accession to the
SummarizedExperiment object is not really straight forward. Any suggestions?
library(GenomicRanges)
library(SummarizedExperiment)
Hi Felix,
This should be addressed in S4Vectors 0.17.11. Thanks for the catch and
for the nice reproducible example.
Best,
H.
On 11/26/2017 04:09 AM, Felix Ernst wrote:
Hi all,
I got different results constructing a SummarizedExperiment in 3.6 and 3.7. My
question is, whether this is intent
Hi,
Looks like at an even lower level, S4Vectors:::listElementType()
is at the origin of the problem:
> S4Vectors:::listElementType(list(matrix(), data.frame()))
[1] "vector"
Should return "ANY" here.
Will try to fix.
H.
On 11/26/2017 07:03 AM, Martin Morgan wrote:
It would seem to be a
It would seem to be a bug in endoapply
lst <- SimpleList(
m = matrix(0, 2, 2, dimnames=list(letters[1:2], LETTERS[1:2])),
df = data.frame(A=1:2, B=1:2, row.names=letters[1:2])
)
dimnames(lst[[1]]) # list(c("a", "b"), c("A", "B"))
dimnames(endoapply(lst, identity)[[1]]
Confirmed with the following sessionInfo(), satisfying biocValid()==TRUE
> sessionInfo()
R Under development (unstable) (2017-11-22 r73776)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Linux Mint 18.1
Matrix products: default
BLAS: /home/stvjc/R-35-dist/lib/R/lib/libRblas.so
LAPACK
Hi all,
I got different results constructing a SummarizedExperiment in 3.6 and 3.7. My
question is, whether this is intentional or a bug.
library(GenomicRanges)
library(SummarizedExperiment)
nrows <- 200; ncols <- 6
counts <- matrix(runif(nrows * ncols, 1, 1e4), nrows)
colnames(counts) <- LETTE
Thanks very much. I will do that.
Best wishes,
Andrea
From: Martin Morgan
Sent: 24 October 2016 13:58:28
To: Rodriguez Martinez, Andrea; bioc-devel@r-project.org
Subject: Re: [Bioc-devel] SummarizedExperiment
On 10/24/2016 07:48 AM, Rodriguez Martinez, Andrea
On 10/24/2016 07:48 AM, Rodriguez Martinez, Andrea wrote:
Hi,
I am developing a package based on the SummarizedExperiment package. I have included the
SummarizedExperiment package in both DESCRIPTION and NAMESPACE files. In some functions of my
package, and also in the vignette, I use the fun
Hi,
I am developing a package based on the SummarizedExperiment package. I have
included the SummarizedExperiment package in both DESCRIPTION and NAMESPACE
files. In some functions of my package, and also in the vignette, I use the
function "assays()" from the SummarizedExperiment package. How
On Fri, Sep 18, 2015 at 8:36 PM, Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:
> Interesting, thanks for the pointer.
>
> In light of the existing (and future) work on this, may I suggest an eSet
> like class, but build using the technologies in SummarizedExperiment. Ie.
> a Summari
Lawrence
> > Sent: Friday, September 18, 2015 10:42 PM
> > To: Peter Haverty
> > Cc: Tim Triche, Jr.; bioc-devel@r-project.org
> > Subject: Re: [Bioc-devel] SummarizedExperiment with alternate back end
> >
> > While it's useful (and often necessary) to st
n...@r-project.org] On Behalf Of
> Michael Lawrence
> Sent: Friday, September 18, 2015 10:42 PM
> To: Peter Haverty
> Cc: Tim Triche, Jr.; bioc-devel@r-project.org
> Subject: Re: [Bioc-devel] SummarizedExperiment with alternate back end
>
> While it's useful (and often necessary)
For what it's worth, I've written a class which I have creatively named
SubsettableListOfArrays which basically taking the "subset everything
together" aspect of eSet and SummarizedExperiment and making it as
generic as possible. It's basically like (non-ranged)
SummarizedExperiment, except tha
While it's useful (and often necessary) to store the big matrices out of
core, it would be convenient to store the metadata (the other components of
the object) along with the matrices. Something along the lines of HDF5, but
we would want to keep things abstract. Other options include GDS (for
geno
While we are on the topic, my GenoSet class will become a subclass of
RangedSummarizedExperiment, rather than eSet, after this upcoming release.
For this release both APIs work (colnames and sampleNames, etc.)
I think the range-free SummarizedExperiment will be great. I've seen a lot
of Expression
In the dev version, SummarizedExperiment has been split into
RangedSummarizedExperiment (equivalent to the current
SummarizedExperiement, with rowRanges) and SummarizedExperiment (kind of
like eSet, no rowRanges). Given that eSet objects also support multiple
assayData elements, I believe the n
Interesting, thanks for the pointer.
In light of the existing (and future) work on this, may I suggest an eSet
like class, but build using the technologies in SummarizedExperiment. Ie.
a SummarizedExperiment without the rowRanges. I would very much like this
for modern work using eSet like conta
thanks to all, lots of potential here.
On Fri, Sep 18, 2015 at 3:28 PM, Peter Haverty
wrote:
> Yes, bigmemoryExtras::BigMatrix and genoset::RleDataFrame() are good
> tricks for reducing the size of your eSets and SummarizedExperiments. Both
> object types can go into assayData or assays. In fac
Yes, bigmemoryExtras::BigMatrix and genoset::RleDataFrame() are good tricks
for reducing the size of your eSets and SummarizedExperiments. Both object
types can go into assayData or assays. In fact, that's what they were
designed for.
At Genentech, we use these for our 2.5e6 x 1e3 rectangular dat
bigmemoryExtras (Peter Haverty's extensions to bigMemory/bigMatrix) can be
handy for this, as it works well as a backend, especially if you go about
splitting by chromosome as for CNV segmentation, DMR finding, etc. It's
not as seamless as one might like, but it's the closest thing I've found.
S
Hi Vince,
This is actually on "our" TODO list for after the release.
SummarizedExperiment was designed to support alternate back end
for the assays slot. More details and proof of concept are
in ?Assays.
H.
On 09/18/2015 01:29 PM, Vincent Carey wrote:
i am dealing with ~700 450k arrays
they a
i am dealing with ~700 450k arrays
they are derived from one study, so it makes sense to think of
them holistically.
both the load time and the memory consumption are not satisfactory.
has anyone worked on an object type that implements the rangedSE API but has
the assay data out of memory?
>
Thanks for the quick action :-)
Nico
---
Nicolas Delhomme, PhD
The Street Lab
Department of Plant Physiology
Umeå Plant Science Center
Tel: +46 90 786 5478
Email: nicolas.delho...@umu.se
SLU - Umeå universitet
Umeå S-901 87 Sweden
Done in SummarizedExperiment 0.3.2.
Thanks for the feedback,
H.
On 06/29/2015 10:26 PM, Hervé Pagès wrote:
Hi Nico,
It seems reasonable indeed to support rowRanges<- on
SummarizedExperiment0. It might be a little bit surprising for the
user that the setter changes the class of the object but i
Hi Nico,
It seems reasonable indeed to support rowRanges<- on
SummarizedExperiment0. It might be a little bit surprising for the
user that the setter changes the class of the object but it looks
like a perfectly legit situation for doing so here. Also there are
some precedents:
> x <- 1:5
>
Hej alla!
In the simpleRNASeq function of the easyRNASeq package, I start by
instantiating a SummarizedExperiment object not initially providing the
rowRanges. This results in the creation of an object of the class
SummarizedExperiment0. When later, once I have validated the annotation, I try
Unlike exptData(), metadata() returns an ordinary list. These methods
also need to be exported and have aliases in the man page for
RangedSummarizedExperiment. I'll add something like that to the
SummarizedExperiment package. Thanks Tim!
H.
On 05/12/2015 11:27 AM, Tim Triche, Jr. wrote:
one set
Thank you all very much!
Jesper
On Wed, Apr 1, 2015 at 9:54 PM, Martin Morgan
wrote:
> On 04/01/2015 07:07 AM, Martin Morgan wrote:
>
>> On 04/01/2015 05:08 AM, Michael Lawrence wrote:
>>
>>> It would be nice if someone from Seattle would weigh in on this.
>>>
>>
>> I was hoping to weigh in wit
On Fri, Apr 3, 2015 at 7:32 AM, Michael Love
wrote:
> hi Martin,
>
> I noticed with GenomicRanges 1.19.51, a new, or newly functional,
> check on dimnames differing between assays.
ah, I'm still using 1.19.50, maybe that's the issue. But I'd still
like to hear what the new behavior will be so I c
hi Martin,
I noticed with GenomicRanges 1.19.51, a new, or newly functional,
check on dimnames differing between assays.
It might be convenient to add an option that assays() will take an
incoming matrix without error no matter what, even if the dimnames on
the incoming matrix are not the same as
On 04/01/2015 07:07 AM, Martin Morgan wrote:
On 04/01/2015 05:08 AM, Michael Lawrence wrote:
It would be nice if someone from Seattle would weigh in on this.
I was hoping to weigh in with 'it's done' but will instead with 'it will be
done'.
4-dimensional assays, advisable or otherwise, are
On 04/01/2015 05:08 AM, Michael Lawrence wrote:
It would be nice if someone from Seattle would weigh in on this.
I was hoping to weigh in with 'it's done' but will instead with 'it will be
done'.
A second aspect of Jesper's data that took me a little by surprise and is
related to Michael's c
It would be nice if someone from Seattle would weigh in on this.
Also, we might want to consider an assayMatrix() accessor that always
returns an assay in 2D, except, as you suggest, it might be a matrix of
multiples (vectors, matrices, etc) by putting dimensions on a list. That
way, generic code
Hi Wolfgang and Michael,
As Michael says, there is no redundant information in the 4D array I have,
and all the values are integers.
Of course I can simulate 4D by e.g. creating extra 3D arrays as assays
equal to the length of the fourth dimension, but that makes the assay list
a mess. It would a
One would need a long-form colData that aligns with the array.
But now I realize that's not what Jesper wants to do here, and is not how
SE is currently designed. Jesper is using the third (and now fourth)
dimension to store an additional dimension of information about the same
sample. We already
Hi Michael
where would you put the “colData”-style metadata for the 3rd, 4th, … dimensions?
As an (ex-)physicists of course I like arrays, and the more dimensions the
better, but in practical work I’ve consistently been bitten by the rigidity of
such a design choice too early in a process.
Taken in the abstract, the tidy data argument is one for consistent data
structures that enable interoperability, which is what we have with
SummarizedExperiment. The "long form" or "tidy" data frame is an effective
general representation, but if there is additional structure in your data,
why not
Dear Jesper
this is maybe not the answer you want to hear, but stuffing in 4, 5, …
dimensions may not be all that useful, as you can always roll out these higher
dimensions into the existing third (or even into the second, the
SummarizedExperiment columns). There is Hadley’s concept of “tidy da
Hi!
The SummarizedExperiment class is an extremely powerful container for
biological data(thank you!), and all my thinking nowadays is just circling
around how to stuff it as effectively as possible.
Have been using 3 dimension for a long time, which has been very
successful. Now I also have a ca
Sounds good. One note: if range information becomes optional, it would be
nice if we could mark the availability of the information in the class
hierarchy. Otherwise, it's not easy to enforce a contract (that we can call
range-based methods on a SE) through dispatch. An alternative would be to
drop
On 11/26/2014 12:11 PM, Hervé Pagès wrote:
Hi guys,
I like the idea of separating the row data from the row ranges.
This could be formalized with 2 distinct accessors: rowData() and
rowRanges(). The former would return a DataFrame, and the latter
NULL or a range-based object (GRanges or GRangesL
The two objects have conflicting APIs. For example, 1D extraction indexes
into the ranges for a GRanges, but into the columns for a table. So I would
not recommend multiple inheritance. Instead, define something new with the
semantics you want and use composition. Maybe just a subclass of DataFrame
OK, GRanges as vector that does overlap stuff makes sense, but I think
putting a DataFrame of metadata on that confuses the purpose of the
object. How about a "GRangesTable" that inherits from both GenomicRanges
and DataTable? It would be a DataFrame with a fancy index. The DataFrame
API would m
Hi guys,
I like the idea of separating the row data from the row ranges.
This could be formalized with 2 distinct accessors: rowData() and
rowRanges(). The former would return a DataFrame, and the latter
NULL or a range-based object (GRanges or GRangesList).
I don't think there is the need for an
One thing that’s become apparent working on epivizr is that it may be useful to
think about ‘rowData’ in a SummarizedExperiment as having two distinct
components: row coordinates and row metadata. In the current class rowData is a
‘GenomicRanges’ which contains both coordinates (the ranges) and
GRangesList is very compact, so this would definitely get the job done. But
having an empty range is not the same as a NA, nor does it mean that ranges
are "irrelevant". There are definitely times, especially as we extend
beyond genomics, when we need something more general, as Pete suggests.
As a
so as a simple experiment, I did the following:
library(GenomicRanges)
bar <- matrix(rnorm(100), ncol=10)
colnames(bar) <- as.character(1:10)
rownames(bar) <- letters[1:10]
foo <- SummarizedExperiment(assays=list(bar=bar))
rowData(foo)
## GRangesList object of length 10:
## $a
## GRanges object w
On Wed, Nov 26, 2014 at 9:07 AM, Peter Haverty
wrote:
> Hi all,
>
> I believe there is a strong need for an object that organizes a collection
> of rectangular data (matrices, etc.) with metadata on the rows and
> columns. Can SummarizedExperiment inherit from something simpler that has
> a Data
Hi all,
I believe there is a strong need for an object that organizes a collection
of rectangular data (matrices, etc.) with metadata on the rows and
columns. Can SummarizedExperiment inherit from something simpler that has
a DataFrame as rowData? (I believe GenomicRanges should inherit from
Dat
On 26 November 2014 14:59, Wolfgang Huber wrote:
> A colleague and I are designing a package for quantitative proteomics
> data, and we are debating whether to base it on the
> SummarizedExperiment or the ExpressionSet class.
>
> There is no immediate use for the ranges aspect of
> SummarizedExpe
A colleague and I are designing a package for quantitative proteomics data, and
we are debating whether to base it on the SummarizedExperiment or the
ExpressionSet class.
There is no immediate use for the ranges aspect of SummarizedExperiment, so
that would have to be carried around with NAs,
On Tue, Mar 25, 2014 at 9:31 AM, Peter Haverty wrote:
> One benefit of having dimnames on assays would be that one could use
> DataFrames as assays, like in eSet. My genoset class is becoming more and
> more like SummarizedExperiment. The dimname issues prevent me from
> switching entirely from e
Also, keeping just the colnames would be sufficient to put a DataFrame in
SE's assays. DataFrames need to have colnames, but can have NULL rownames
(right?).
BTW, BigMatrix also has the argument "withDimnames" for subsetting. Adding
dimnames to ( and copying ) a huge vector takes as much time as p
If it makes genosets coercible into SEs then I'm all for the change and its
permanence
--t
> On Mar 25, 2014, at 9:31 AM, Peter Haverty wrote:
>
> One benefit of having dimnames on assays would be that one could use
> DataFrames as assays, like in eSet. My genoset class is becoming more and
>
One benefit of having dimnames on assays would be that one could use
DataFrames as assays, like in eSet. My genoset class is becoming more and
more like SummarizedExperiment. The dimname issues prevent me from
switching entirely from eSet to SummarizedExperiment.
I think that keeping only one cop
There could be repurcussions, depending on the long term strategy.
Pre-change behaviour was
all assay matrices would be stored without dimnames.
when they are accessed, dimnames would be copied in from the colData slot
(could be optionally disabled).
Current behaviour (which I have not fully
On Mon, Mar 24, 2014 at 11:07 AM, Martin Morgan wrote:
> On 03/20/2014 06:29 PM, Kasper Daniel Hansen wrote:
>
>> It used to be the case that when a SummarizedExperiment was constructed,
>> dim names was removed from the matrices in assay. One could then either
>> use
>> (1) assay(, withDimname
On 03/20/2014 06:29 PM, Kasper Daniel Hansen wrote:
It used to be the case that when a SummarizedExperiment was constructed,
dim names was removed from the matrices in assay. One could then either use
(1) assay(, withDimnames = TRUE)
which ensured dim names in the return value, but implied copy
It used to be the case that when a SummarizedExperiment was constructed,
dim names was removed from the matrices in assay. One could then either use
(1) assay(, withDimnames = TRUE)
which ensured dim names in the return value, but implied copying of the
return object because the dim names had to
The code that's there now is already unit tested and should be merged.
The test I mentioned was a small check that the following works (this is
what started this thread):
> m <- matrix(1, 5, 3, dimnames=list(NULL, NULL))
> gr <- GRanges("chr1", IRanges(1:5, 10))
> colData <- DataFrame(x=letters[1:
If you don't mind, I think I'll wait till after you're finished testing
before merging.
Please keep me up to date,
Michael
On Fri, Aug 2, 2013 at 7:43 AM, Hector Corrada Bravo wrote:
> Thanks again Kasper,
> All of these are now fixed:
> * empty subject seqlevel,
> * out-of-order seqinfo's,
> *
Thanks again Kasper,
All of these are now fixed:
* empty subject seqlevel,
* out-of-order seqinfo's,
* show,GIntervalTree-method
Michael, please merge from
https://github.com/hcorrada/IRanges [version 1.19.20]
https://github.com/hcorrada/GenomicRanges [version 1.13.36]
I'll test the SummarizedExp
If you're fixing tonight here is a possible related. I get an error when I
do the findOverlaps and I have two GRanges with the same seqlevels but in
different order (so, I guess, technically not the same seqlevels). If this
is not supported, I suggest an upfront check.
gr1 = GRanges(seqnames = c
Minor thing: the show method for GIntervalTrees is saying 'A GRanges with
...'. Perhaps this should be changed to 'A GIntervalTree with ...'
Kasper
On Thu, Aug 1, 2013 at 4:48 PM, Hector Corrada Bravo wrote:
> Thanks. I'll fix tonight.
>
>
> On Thu, Aug 1, 2013 at 4:28 PM, Kasper Daniel Hanse
Thanks. I'll fix tonight.
On Thu, Aug 1, 2013 at 4:28 PM, Kasper Daniel Hansen
wrote:
> Bug:
>> library(GenomicRanges) ## 1.13.35
>> gr = GRanges(seqnames = c("chr1", "chr2"), ranges = IRanges(1:2, width =
> 1))
> > gr.tree <- GIntervalTree(gr)
> > findOverlaps(gr.tree, gr.tree)
> Hits of len
Bug:
> library(GenomicRanges) ## 1.13.35
> gr = GRanges(seqnames = c("chr1", "chr2"), ranges = IRanges(1:2, width =
1))
> gr.tree <- GIntervalTree(gr)
> findOverlaps(gr.tree, gr.tree)
Hits of length 2
queryLength: 2
subjectLength: 2
queryHits subjectHits
1
Ah! Super-nice! I'll test as well, when I have time.
Kasper
On Thu, Aug 1, 2013 at 3:34 PM, Hector Corrada Bravo wrote:
> This is not tested, but...
>
> GIntervalTree extends GenomicRanges so, in principle, can be used in the
> rowData slot of SummarizedExperiment. I tried to make GIntervalTr
This is not tested, but...
GIntervalTree extends GenomicRanges  so, in principle, can be used in the
rowData slot of SummarizedExperiment. I tried to make GIntervalTree support as
much of the GenomicRanges interface as I could so this may work already for
overlap queries where the SummarizedE
Now that we have GIntervalTree, I am really interested in a
SummarizedExperiment that stores its index in a slot, so it can be indexed
once. I am sure other people are greedily eyeing this as well. Either
changing the class or extending it.
Unfortunately, I will not have time to work on this for
79 matches
Mail list logo
