Re: [Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Martin Morgan 

On 11/26/2014 07:36 PM, Dan Tenenbaum wrote:



- Original Message -

From: "Martin Morgan" 
To: "Dan Tenenbaum" 
Cc: "Joachim Schumann" , bioc-devel@r-project.org
Sent: Wednesday, November 26, 2014 5:33:22 PM
Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR

On 11/26/2014 10:03 AM, Dan Tenenbaum wrote:



- Original Message -

From: "Martin Morgan" 
To: "Joachim Schumann" ,
bioc-devel@r-project.org
Sent: Wednesday, November 26, 2014 9:00:07 AM
Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR

On 11/26/2014 01:39 AM, Joachim Schumann wrote:

Hi everyone,
this morning I got an email from bioconductor.
The message:

According to the "Build/check report" for BioC 3.0,
the flowCHIC package has the following problem(s):
ERROR for 'R CMD check' on zin1.

The error I get is the following:

Error in callGeneric() :
 'callGeneric' with a primitive needs explicit arguments (no
 formal args defined)
Calls: calculate_overlaps_xor ... calculate_overlaps_xor ->
.local
-> bXOR ->
round -> round -> callGeneric

Does anyone know what the problem is? It seems that the round
function causes
the error.


This is some kind of interaction with Matrix

   > library(EBImage)
   > img = readImage(system.file(package="EBImage", "images",
   > "nuclei.tif"))
   > xx = round(img)
   > library(Matrix)
   > yy = round(img)
Error in callGeneric() :
 'callGeneric' with a primitive needs explicit arguments (no
 formal
 args defined)

which defines a Math2 group generic. How long has this been
appearing? It
doesn't seem like the build system R, EBImage or Matrix has
changed
since
release, and the package is available via biocLite implying that
it
once built...


I think the build system R has changed since release, since it's
running 3.1.2 which was released on 10/31/2014, but release was
10/14/2014.

Indeed, if I look at the flowCHIC_1.0.0.tgz DESCRIPTION file, I see
in the "Built" line that it was built with R 3.1.1.

So this suggests a problem with R-3.1.2? Is this a bug we should
report?


The path to Matrix is

flowCHIC
Imports: vegan
  Imports: mgcv
Imports: Matrix

vegan was updated on

  > packageDescription("vegan")[c('Version', 'Date/Publication')]
$Version
[1] "2.2-0"

$`Date/Publication`
[1] "2014-11-17 11:35:34"

and changed (based on comparison with the last archived version,
2.0-10 from
http://cran.fhcrc.org/src/contrib/Archive/vegan) to move Matrix from
Suggests:
to Imports:.

I think it's a long-standing issue in R; I can reproduce it using the
EBImage /
Matrix example in R 2.15, for instance (although oddly I had to go
through some
mild histrionics to get EBImage to compile). Specifically, it seems
like a patch
that Michael just applied in R-devel (!), plus

Index: MethodsListClass.R
===
--- MethodsListClass.R  (revision 67060)
+++ MethodsListClass.R  (working copy)
@@ -353,7 +353,7 @@
 function(x, digits) {
 value <- x
 x <- x@.Data
-  value@Data  <- callGeneric()
+  value@.Data  <- callGeneric()
 value
 })
   ## some methods for nonStructure, ensuring that the class and
   slots




Are you going to commit this? If this (and Michael's change) fixes the problem, 
then I will update the build machines. BTW flowCHIC has the same issue in 
release, so I guess some backporting is in order.



Both R-devel and R-3-1-branch will have a fix.

For flowCHIC, I'd leave devel as-is, it will eventually heal itself.

For release, I think Joachim should explore an alternative so that users of the 
current R release can use flowCHIC without waiting for the next release in the 
R-3-1 series. I'm not really familiar with the EBImage package, but I think what 
you want to do is the equivalent of


  x = initialize(x, round(imageData(x) * (2^8 - 1), digits = 3))

i.e., calculating round() on the raw array, then updating the Image object 'x'.

Martin


Dan



Martin



Dan




Martin



Best,
Joachim




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Dan Tenenbaum 


- Original Message -
> From: "Martin Morgan" 
> To: "Dan Tenenbaum" 
> Cc: "Joachim Schumann" , bioc-devel@r-project.org
> Sent: Wednesday, November 26, 2014 5:33:22 PM
> Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR
> 
> On 11/26/2014 10:03 AM, Dan Tenenbaum wrote:
> >
> >
> > - Original Message -
> >> From: "Martin Morgan" 
> >> To: "Joachim Schumann" ,
> >> bioc-devel@r-project.org
> >> Sent: Wednesday, November 26, 2014 9:00:07 AM
> >> Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR
> >>
> >> On 11/26/2014 01:39 AM, Joachim Schumann wrote:
> >>> Hi everyone,
> >>> this morning I got an email from bioconductor.
> >>> The message:
> >>>
> >>> According to the "Build/check report" for BioC 3.0,
> >>> the flowCHIC package has the following problem(s):
> >>> ERROR for 'R CMD check' on zin1.
> >>>
> >>> The error I get is the following:
> >>>
> >>> Error in callGeneric() :
> >>> 'callGeneric' with a primitive needs explicit arguments (no
> >>> formal args defined)
> >>> Calls: calculate_overlaps_xor ... calculate_overlaps_xor ->
> >>> .local
> >>> -> bXOR ->
> >>> round -> round -> callGeneric
> >>>
> >>> Does anyone know what the problem is? It seems that the round
> >>> function causes
> >>> the error.
> >>
> >> This is some kind of interaction with Matrix
> >>
> >>   > library(EBImage)
> >>   > img = readImage(system.file(package="EBImage", "images",
> >>   > "nuclei.tif"))
> >>   > xx = round(img)
> >>   > library(Matrix)
> >>   > yy = round(img)
> >> Error in callGeneric() :
> >> 'callGeneric' with a primitive needs explicit arguments (no
> >> formal
> >> args defined)
> >>
> >> which defines a Math2 group generic. How long has this been
> >> appearing? It
> >> doesn't seem like the build system R, EBImage or Matrix has
> >> changed
> >> since
> >> release, and the package is available via biocLite implying that
> >> it
> >> once built...
> >
> > I think the build system R has changed since release, since it's
> > running 3.1.2 which was released on 10/31/2014, but release was
> > 10/14/2014.
> >
> > Indeed, if I look at the flowCHIC_1.0.0.tgz DESCRIPTION file, I see
> > in the "Built" line that it was built with R 3.1.1.
> >
> > So this suggests a problem with R-3.1.2? Is this a bug we should
> > report?
> 
> The path to Matrix is
> 
> flowCHIC
>Imports: vegan
>  Imports: mgcv
>Imports: Matrix
> 
> vegan was updated on
> 
>  > packageDescription("vegan")[c('Version', 'Date/Publication')]
> $Version
> [1] "2.2-0"
> 
> $`Date/Publication`
> [1] "2014-11-17 11:35:34"
> 
> and changed (based on comparison with the last archived version,
> 2.0-10 from
> http://cran.fhcrc.org/src/contrib/Archive/vegan) to move Matrix from
> Suggests:
> to Imports:.
> 
> I think it's a long-standing issue in R; I can reproduce it using the
> EBImage /
> Matrix example in R 2.15, for instance (although oddly I had to go
> through some
> mild histrionics to get EBImage to compile). Specifically, it seems
> like a patch
> that Michael just applied in R-devel (!), plus
> 
> Index: MethodsListClass.R
> ===
> --- MethodsListClass.R(revision 67060)
> +++ MethodsListClass.R(working copy)
> @@ -353,7 +353,7 @@
> function(x, digits) {
> value <- x
> x <- x@.Data
> -  value@Data  <- callGeneric()
> +  value@.Data  <- callGeneric()
> value
> })
>   ## some methods for nonStructure, ensuring that the class and
>   slots
> 
> 

Are you going to commit this? If this (and Michael's change) fixes the problem, 
then I will update the build machines. BTW flowCHIC has the same issue in 
release, so I guess some backporting is in order.

Dan


> Martin
> 
> >
> > Dan
> >
> >
> >>
> >> Martin
> >>
> >>>
> >>> Best,
> >>> Joachim
> >>>
> >>
> >>
> >> --
> >> Computational Biology / Fred Hutchinson Cancer Research Center
> >> 1100 Fairview Ave. N.
> >> PO Box 19024 Seattle, WA 98109
> >>
> >> Location: Arnold Building M1 B861
> >> Phone: (206) 667-2793
> >>
> >> ___
> >> Bioc-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>
> 
> 
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> 
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Martin Morgan 

On 11/26/2014 10:03 AM, Dan Tenenbaum wrote:



- Original Message -

From: "Martin Morgan" 
To: "Joachim Schumann" , bioc-devel@r-project.org
Sent: Wednesday, November 26, 2014 9:00:07 AM
Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR

On 11/26/2014 01:39 AM, Joachim Schumann wrote:

Hi everyone,
this morning I got an email from bioconductor.
The message:

According to the "Build/check report" for BioC 3.0,
the flowCHIC package has the following problem(s):
ERROR for 'R CMD check' on zin1.

The error I get is the following:

Error in callGeneric() :
'callGeneric' with a primitive needs explicit arguments (no
formal args defined)
Calls: calculate_overlaps_xor ... calculate_overlaps_xor -> .local
-> bXOR ->
round -> round -> callGeneric

Does anyone know what the problem is? It seems that the round
function causes
the error.


This is some kind of interaction with Matrix

  > library(EBImage)
  > img = readImage(system.file(package="EBImage", "images",
  > "nuclei.tif"))
  > xx = round(img)
  > library(Matrix)
  > yy = round(img)
Error in callGeneric() :
'callGeneric' with a primitive needs explicit arguments (no formal
args defined)

which defines a Math2 group generic. How long has this been
appearing? It
doesn't seem like the build system R, EBImage or Matrix has changed
since
release, and the package is available via biocLite implying that it
once built...


I think the build system R has changed since release, since it's running 3.1.2 
which was released on 10/31/2014, but release was 10/14/2014.

Indeed, if I look at the flowCHIC_1.0.0.tgz DESCRIPTION file, I see in the 
"Built" line that it was built with R 3.1.1.

So this suggests a problem with R-3.1.2? Is this a bug we should report?


The path to Matrix is

flowCHIC
  Imports: vegan
Imports: mgcv
  Imports: Matrix

vegan was updated on

> packageDescription("vegan")[c('Version', 'Date/Publication')]
$Version
[1] "2.2-0"

$`Date/Publication`
[1] "2014-11-17 11:35:34"

and changed (based on comparison with the last archived version, 2.0-10 from 
http://cran.fhcrc.org/src/contrib/Archive/vegan) to move Matrix from Suggests: 
to Imports:.


I think it's a long-standing issue in R; I can reproduce it using the EBImage / 
Matrix example in R 2.15, for instance (although oddly I had to go through some 
mild histrionics to get EBImage to compile). Specifically, it seems like a patch 
that Michael just applied in R-devel (!), plus


Index: MethodsListClass.R
===
--- MethodsListClass.R  (revision 67060)
+++ MethodsListClass.R  (working copy)
@@ -353,7 +353,7 @@
   function(x, digits) {
   value <- x
   x <- x@.Data
-  value@Data  <- callGeneric()
+  value@.Data  <- callGeneric()
   value
   })
 ## some methods for nonStructure, ensuring that the class and slots


Martin



Dan




Martin



Best,
Joachim




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Michael Lawrence 
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
that adds a GenomicRanges slot.

On Wed, Nov 26, 2014 at 1:55 PM, Peter Haverty 
wrote:

> 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 make stuff like colnames work (rather than needing
> colnames(mcols(x)) ). If this were used as the rowData for
> SummarizedExperiment, then a plain DataFrame could be made to work too.
>
> Pete
>
> 
> Peter M. Haverty, Ph.D.
> Genentech, Inc.
> phave...@gene.com
>
> On Wed, Nov 26, 2014 at 9:33 AM, Michael Lawrence <
> lawrence.mich...@gene.com> wrote:
>
>>
>>
>> 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 DataFrame as rowData?
>>
>>   (I believe GenomicRanges should inherit from
>>> DataTable, rather than Vector, and subset as x[i,j], but maybe that's
>>> getting a bit off topic.)
>>
>>
>> Have to disagree on that. A GRanges is a vector of ranges; a table is a
>> list of vectors all of the same length. Different things. There was a lot
>> of thought invested in that. But it does subset as x[i,j], so in theory
>> SummarizedExperiment could be generalized to contain something with the
>> contract of 2D extraction.
>>
>>
>>> I often see people stuffing arbitrary data into
>>> an ExpressionSet and calling one of the assays "exprs" as a work-around.
>>>
>>> Regards,
>>>
>>> Pete
>>>
>>> 
>>> Peter M. Haverty, Ph.D.
>>> Genentech, Inc.
>>> phave...@gene.com
>>>
>>> On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
>>>
>>> >
>>> > 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
>>> > > SummarizedExperiment, so that would have to be carried around with
>>> > > NAs, and this is a parsimony argument for using ExpressionSet
>>> > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
>>> > > code more modern and more likely to be updated, and users of the
>>> > > Bioconductor project are likely to benefit from having to deal with a
>>> > > single interface that works the same or similarly across packages,
>>> > > rather than a variety of formats; which argues that new packages
>>> > > should converge towards SummarizedExperiment('s interface).
>>> > >
>>> > > Are there any pertinent insights from this group?
>>> >
>>> > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
>>> > essentially an ExpressionSet for quantitative proteomics (i.e it has a
>>> > MIAPE slot, instead of MIAME for example).
>>> >
>>> > Ideally, a SummarizedExperiment for proteomics would use
>>> peptide/protein
>>> > ranges, which is in the pipeline, as far as I am concerned. When that
>>> > becomes available, there should be infrastructure to coerce and MSnSet
>>> > (and/or other relevant data) into an SummarizedExperiment.
>>> >
>>> > Hope this helps.
>>> >
>>> > Best wishes,
>>> >
>>> > Laurent
>>> >
>>> > > Thanks and best wishes
>>> > > Wolfgang
>>> > >
>>> > > ___
>>> > > Bioc-devel@r-project.org mailing list
>>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>> >
>>> > --
>>> > Laurent Gatto
>>> > http://cpu.sysbiol.cam.ac.uk/
>>> >
>>> > ___
>>> > Bioc-devel@r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>> >
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Peter Haverty 
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 make stuff like colnames work (rather than needing
colnames(mcols(x)) ). If this were used as the rowData for
SummarizedExperiment, then a plain DataFrame could be made to work too.

Pete


Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com

On Wed, Nov 26, 2014 at 9:33 AM, Michael Lawrence  wrote:

>
>
> 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 DataFrame as rowData?
>
>   (I believe GenomicRanges should inherit from
>> DataTable, rather than Vector, and subset as x[i,j], but maybe that's
>> getting a bit off topic.)
>
>
> Have to disagree on that. A GRanges is a vector of ranges; a table is a
> list of vectors all of the same length. Different things. There was a lot
> of thought invested in that. But it does subset as x[i,j], so in theory
> SummarizedExperiment could be generalized to contain something with the
> contract of 2D extraction.
>
>
>> I often see people stuffing arbitrary data into
>> an ExpressionSet and calling one of the assays "exprs" as a work-around.
>>
>> Regards,
>>
>> Pete
>>
>> 
>> Peter M. Haverty, Ph.D.
>> Genentech, Inc.
>> phave...@gene.com
>>
>> On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
>>
>> >
>> > 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
>> > > SummarizedExperiment, so that would have to be carried around with
>> > > NAs, and this is a parsimony argument for using ExpressionSet
>> > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
>> > > code more modern and more likely to be updated, and users of the
>> > > Bioconductor project are likely to benefit from having to deal with a
>> > > single interface that works the same or similarly across packages,
>> > > rather than a variety of formats; which argues that new packages
>> > > should converge towards SummarizedExperiment('s interface).
>> > >
>> > > Are there any pertinent insights from this group?
>> >
>> > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
>> > essentially an ExpressionSet for quantitative proteomics (i.e it has a
>> > MIAPE slot, instead of MIAME for example).
>> >
>> > Ideally, a SummarizedExperiment for proteomics would use peptide/protein
>> > ranges, which is in the pipeline, as far as I am concerned. When that
>> > becomes available, there should be infrastructure to coerce and MSnSet
>> > (and/or other relevant data) into an SummarizedExperiment.
>> >
>> > Hope this helps.
>> >
>> > Best wishes,
>> >
>> > Laurent
>> >
>> > > Thanks and best wishes
>> > > Wolfgang
>> > >
>> > > ___
>> > > Bioc-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>> > --
>> > Laurent Gatto
>> > http://cpu.sysbiol.cam.ac.uk/
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Hervé Pagès 

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 emptyRanges class.

H.

On 11/26/2014 11:40 AM, Hector Corrada Bravo wrote:

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 metadata 
(mcols(rowData)). In metagenomics (the other application my group works a lot 
with), we think of the taxonomy as providing coordinates. The distinction is 
worthwhile thinking about since there are certain operations we do on 
coordinates that we don’t do with metadata (and conversely).




Thinking about it this way, the ‘ExpressionSet’ object would be data without 
coordinates. So, I would avoid making ‘GenomicRanges’ behave like ‘DataFrame’ 
since this distinction between coordinates and metadata is lost. The 
‘emptyRanges’ proposal gets closer to this since this corresponds to ‘no 
coordinates’, but it may be worth thinking in the long term on making the 
coordinate/metadata distinction more general.




Hector

On Wed, Nov 26, 2014 at 12:38 PM, Tim Triche, Jr. 
wrote:


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 with 0 ranges and 0 metadata columns:
##seqnamesranges strand
##  
##
## $b
## GRanges object with 0 ranges and 0 metadata columns:
##  seqnames ranges strand
##
## $c
## GRanges object with 0 ranges and 0 metadata columns:
##  seqnames ranges strand
##
## ...
## <7 more elements>
colData(foo)
## DataFrame with 10 rows and 0 columns
This got me to thinking, why not have an emptyRanges class, or else the
ability to index a bunch of NULL ranges without a lot of hoohah?  The
defaults mostly do what they're supposed to; why not have a compact
representation of empty rowData as for empty colData (i.e., a DataFrame
with 0 rows)?  Or is a GRangesList of empty GRanges as compact as it is
practicable to get for this purpose?
Just pondering what the lowest-impact solution to the problem at hand might
be.
Statistics is the grammar of science.
Karl Pearson 
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 DataFrame as rowData?  (I believe GenomicRanges should inherit from
DataTable, rather than Vector, and subset as x[i,j], but maybe that's
getting a bit off topic.)  I often see people stuffing arbitrary data into
an ExpressionSet and calling one of the assays "exprs" as a work-around.

Regards,

Pete


Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com

On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:



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
SummarizedExperiment, so that would have to be carried around with
NAs, and this is a parsimony argument for using ExpressionSet
instead. OTOH, the interface of SummarizedExperiment is cleaner, its
code more modern and more likely to be updated, and users of the
Bioconductor project are likely to benefit from having to deal with a
single interface that works the same or similarly across packages,
rather than a variety of formats; which argues that new packages
should converge towards SummarizedExperiment('s interface).

Are there any pertinent insights from this group?


Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
essentially an ExpressionSet for quantitative proteomics (i.e it has a
MIAPE slot, instead of MIAME for example).

Ideally, a SummarizedExperiment for proteomics would use peptide/protein
ranges, which is in the pipeline, as far as I am concerned. When that
becomes available, there should be infrastructure to coerce and MSnSet
(and/or other relevant data) into an SummarizedExperiment.

Hope this helps.

Best wishes,

Laurent


Thanks and best wishes
Wolfgang

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
Laurent Gatto
http://cpu.sysbiol.cam.ac.uk/

___

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Hector Corrada Bravo 
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 metadata 
(mcols(rowData)). In metagenomics (the other application my group works a lot 
with), we think of the taxonomy as providing coordinates. The distinction is 
worthwhile thinking about since there are certain operations we do on 
coordinates that we don’t do with metadata (and conversely).




Thinking about it this way, the ‘ExpressionSet’ object would be data without 
coordinates. So, I would avoid making ‘GenomicRanges’ behave like ‘DataFrame’ 
since this distinction between coordinates and metadata is lost. The 
‘emptyRanges’ proposal gets closer to this since this corresponds to ‘no 
coordinates’, but it may be worth thinking in the long term on making the 
coordinate/metadata distinction more general.




Hector

On Wed, Nov 26, 2014 at 12:38 PM, Tim Triche, Jr. 
wrote:

> 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 with 0 ranges and 0 metadata columns:
> ##seqnamesranges strand
> ##  
> ##
> ## $b
> ## GRanges object with 0 ranges and 0 metadata columns:
> ##  seqnames ranges strand
> ##
> ## $c
> ## GRanges object with 0 ranges and 0 metadata columns:
> ##  seqnames ranges strand
> ##
> ## ...
> ## <7 more elements>
> colData(foo)
> ## DataFrame with 10 rows and 0 columns
> This got me to thinking, why not have an emptyRanges class, or else the
> ability to index a bunch of NULL ranges without a lot of hoohah?  The
> defaults mostly do what they're supposed to; why not have a compact
> representation of empty rowData as for empty colData (i.e., a DataFrame
> with 0 rows)?  Or is a GRangesList of empty GRanges as compact as it is
> practicable to get for this purpose?
> Just pondering what the lowest-impact solution to the problem at hand might
> be.
> Statistics is the grammar of science.
> Karl Pearson 
> 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 DataFrame as rowData?  (I believe GenomicRanges should inherit from
>> DataTable, rather than Vector, and subset as x[i,j], but maybe that's
>> getting a bit off topic.)  I often see people stuffing arbitrary data into
>> an ExpressionSet and calling one of the assays "exprs" as a work-around.
>>
>> Regards,
>>
>> Pete
>>
>> 
>> Peter M. Haverty, Ph.D.
>> Genentech, Inc.
>> phave...@gene.com
>>
>> On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
>>
>> >
>> > 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
>> > > SummarizedExperiment, so that would have to be carried around with
>> > > NAs, and this is a parsimony argument for using ExpressionSet
>> > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
>> > > code more modern and more likely to be updated, and users of the
>> > > Bioconductor project are likely to benefit from having to deal with a
>> > > single interface that works the same or similarly across packages,
>> > > rather than a variety of formats; which argues that new packages
>> > > should converge towards SummarizedExperiment('s interface).
>> > >
>> > > Are there any pertinent insights from this group?
>> >
>> > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
>> > essentially an ExpressionSet for quantitative proteomics (i.e it has a
>> > MIAPE slot, instead of MIAME for example).
>> >
>> > Ideally, a SummarizedExperiment for proteomics would use peptide/protein
>> > ranges, which is in the pipeline, as far as I am concerned. When that
>> > becomes available, there should be infrastructure to coerce and MSnSet
>> > (and/or other relevant data) into an SummarizedExperiment.
>> >
>> > Hope this helps.
>> >
>> > Best wishes,
>> >
>> > Laurent
>> >
>> > > Thanks and best wishes
>> > > Wolfgang
>> > >
>> > > ___
>> > > Bioc-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>> > --
>> > Laurent Gatto
>> > http://cpu.sysbiol.cam.ac.uk/
>> >
>>

Re: [Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Dan Tenenbaum 


- Original Message -
> From: "Martin Morgan" 
> To: "Joachim Schumann" , bioc-devel@r-project.org
> Sent: Wednesday, November 26, 2014 9:00:07 AM
> Subject: Re: [Bioc-devel] BioC 3.0 CHECK ERROR
> 
> On 11/26/2014 01:39 AM, Joachim Schumann wrote:
> > Hi everyone,
> > this morning I got an email from bioconductor.
> > The message:
> >
> > According to the "Build/check report" for BioC 3.0,
> > the flowCHIC package has the following problem(s):
> > ERROR for 'R CMD check' on zin1.
> >
> > The error I get is the following:
> >
> > Error in callGeneric() :
> >'callGeneric' with a primitive needs explicit arguments (no
> >formal args defined)
> > Calls: calculate_overlaps_xor ... calculate_overlaps_xor -> .local
> > -> bXOR ->
> > round -> round -> callGeneric
> >
> > Does anyone know what the problem is? It seems that the round
> > function causes
> > the error.
> 
> This is some kind of interaction with Matrix
> 
>  > library(EBImage)
>  > img = readImage(system.file(package="EBImage", "images",
>  > "nuclei.tif"))
>  > xx = round(img)
>  > library(Matrix)
>  > yy = round(img)
> Error in callGeneric() :
>'callGeneric' with a primitive needs explicit arguments (no formal
>args defined)
> 
> which defines a Math2 group generic. How long has this been
> appearing? It
> doesn't seem like the build system R, EBImage or Matrix has changed
> since
> release, and the package is available via biocLite implying that it
> once built...

I think the build system R has changed since release, since it's running 3.1.2 
which was released on 10/31/2014, but release was 10/14/2014.

Indeed, if I look at the flowCHIC_1.0.0.tgz DESCRIPTION file, I see in the 
"Built" line that it was built with R 3.1.1.

So this suggests a problem with R-3.1.2? Is this a bug we should report?

Dan


> 
> Martin
> 
> >
> > Best,
> > Joachim
> >
> 
> 
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
> 
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Michael Lawrence 
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 an aside I think there is an interesting structural relationship between
something like an eSet and a pivot table in a spreadsheet, except an eSet
has multiple measurement tables and the column/row annotations are not just
for aggregation. If we start to think more broadly, we should consider such
specializations and try to unify them into a single framework.



On Wed, Nov 26, 2014 at 9:37 AM, Tim Triche, Jr. 
wrote:

> 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 with 0 ranges and 0 metadata columns:
> ##seqnamesranges strand
> ##  
> ##
> ## $b
> ## GRanges object with 0 ranges and 0 metadata columns:
> ##  seqnames ranges strand
> ##
> ## $c
> ## GRanges object with 0 ranges and 0 metadata columns:
> ##  seqnames ranges strand
> ##
> ## ...
> ## <7 more elements>
>
> colData(foo)
> ## DataFrame with 10 rows and 0 columns
>
> This got me to thinking, why not have an emptyRanges class, or else the
> ability to index a bunch of NULL ranges without a lot of hoohah?  The
> defaults mostly do what they're supposed to; why not have a compact
> representation of empty rowData as for empty colData (i.e., a DataFrame
> with 0 rows)?  Or is a GRangesList of empty GRanges as compact as it is
> practicable to get for this purpose?
>
> Just pondering what the lowest-impact solution to the problem at hand might
> be.
>
>
> Statistics is the grammar of science.
> Karl Pearson 
>
> 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 DataFrame as rowData?  (I believe GenomicRanges should inherit from
> > DataTable, rather than Vector, and subset as x[i,j], but maybe that's
> > getting a bit off topic.)  I often see people stuffing arbitrary data
> into
> > an ExpressionSet and calling one of the assays "exprs" as a work-around.
> >
> > Regards,
> >
> > Pete
> >
> > 
> > Peter M. Haverty, Ph.D.
> > Genentech, Inc.
> > phave...@gene.com
> >
> > On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
> >
> > >
> > > 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
> > > > SummarizedExperiment, so that would have to be carried around with
> > > > NAs, and this is a parsimony argument for using ExpressionSet
> > > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
> > > > code more modern and more likely to be updated, and users of the
> > > > Bioconductor project are likely to benefit from having to deal with a
> > > > single interface that works the same or similarly across packages,
> > > > rather than a variety of formats; which argues that new packages
> > > > should converge towards SummarizedExperiment('s interface).
> > > >
> > > > Are there any pertinent insights from this group?
> > >
> > > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
> > > essentially an ExpressionSet for quantitative proteomics (i.e it has a
> > > MIAPE slot, instead of MIAME for example).
> > >
> > > Ideally, a SummarizedExperiment for proteomics would use
> peptide/protein
> > > ranges, which is in the pipeline, as far as I am concerned. When that
> > > becomes available, there should be infrastructure to coerce and MSnSet
> > > (and/or other relevant data) into an SummarizedExperiment.
> > >
> > > Hope this helps.
> > >
> > > Best wishes,
> > >
> > > Laurent
> > >
> > > > Thanks and best wishes
> > > > Wolfgang
> > > >
> > > > ___
> > > > Bioc-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >
> > > --
> > > Laurent Gatto
> > > http://cpu.sysbiol.cam.ac.uk/
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > Bioc-devel@r

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Tim Triche, Jr. 
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 with 0 ranges and 0 metadata columns:
##seqnamesranges strand
##  
##
## $b
## GRanges object with 0 ranges and 0 metadata columns:
##  seqnames ranges strand
##
## $c
## GRanges object with 0 ranges and 0 metadata columns:
##  seqnames ranges strand
##
## ...
## <7 more elements>

colData(foo)
## DataFrame with 10 rows and 0 columns

This got me to thinking, why not have an emptyRanges class, or else the
ability to index a bunch of NULL ranges without a lot of hoohah?  The
defaults mostly do what they're supposed to; why not have a compact
representation of empty rowData as for empty colData (i.e., a DataFrame
with 0 rows)?  Or is a GRangesList of empty GRanges as compact as it is
practicable to get for this purpose?

Just pondering what the lowest-impact solution to the problem at hand might
be.


Statistics is the grammar of science.
Karl Pearson 

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 DataFrame as rowData?  (I believe GenomicRanges should inherit from
> DataTable, rather than Vector, and subset as x[i,j], but maybe that's
> getting a bit off topic.)  I often see people stuffing arbitrary data into
> an ExpressionSet and calling one of the assays "exprs" as a work-around.
>
> Regards,
>
> Pete
>
> 
> Peter M. Haverty, Ph.D.
> Genentech, Inc.
> phave...@gene.com
>
> On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
>
> >
> > 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
> > > SummarizedExperiment, so that would have to be carried around with
> > > NAs, and this is a parsimony argument for using ExpressionSet
> > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
> > > code more modern and more likely to be updated, and users of the
> > > Bioconductor project are likely to benefit from having to deal with a
> > > single interface that works the same or similarly across packages,
> > > rather than a variety of formats; which argues that new packages
> > > should converge towards SummarizedExperiment('s interface).
> > >
> > > Are there any pertinent insights from this group?
> >
> > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
> > essentially an ExpressionSet for quantitative proteomics (i.e it has a
> > MIAPE slot, instead of MIAME for example).
> >
> > Ideally, a SummarizedExperiment for proteomics would use peptide/protein
> > ranges, which is in the pipeline, as far as I am concerned. When that
> > becomes available, there should be infrastructure to coerce and MSnSet
> > (and/or other relevant data) into an SummarizedExperiment.
> >
> > Hope this helps.
> >
> > Best wishes,
> >
> > Laurent
> >
> > > Thanks and best wishes
> > > Wolfgang
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> > --
> > Laurent Gatto
> > http://cpu.sysbiol.cam.ac.uk/
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Michael Lawrence 
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 DataFrame as rowData?

  (I believe GenomicRanges should inherit from
> DataTable, rather than Vector, and subset as x[i,j], but maybe that's
> getting a bit off topic.)


Have to disagree on that. A GRanges is a vector of ranges; a table is a
list of vectors all of the same length. Different things. There was a lot
of thought invested in that. But it does subset as x[i,j], so in theory
SummarizedExperiment could be generalized to contain something with the
contract of 2D extraction.


> I often see people stuffing arbitrary data into
> an ExpressionSet and calling one of the assays "exprs" as a work-around.
>
> Regards,
>
> Pete
>
> 
> Peter M. Haverty, Ph.D.
> Genentech, Inc.
> phave...@gene.com
>
> On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:
>
> >
> > 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
> > > SummarizedExperiment, so that would have to be carried around with
> > > NAs, and this is a parsimony argument for using ExpressionSet
> > > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
> > > code more modern and more likely to be updated, and users of the
> > > Bioconductor project are likely to benefit from having to deal with a
> > > single interface that works the same or similarly across packages,
> > > rather than a variety of formats; which argues that new packages
> > > should converge towards SummarizedExperiment('s interface).
> > >
> > > Are there any pertinent insights from this group?
> >
> > Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
> > essentially an ExpressionSet for quantitative proteomics (i.e it has a
> > MIAPE slot, instead of MIAME for example).
> >
> > Ideally, a SummarizedExperiment for proteomics would use peptide/protein
> > ranges, which is in the pipeline, as far as I am concerned. When that
> > becomes available, there should be infrastructure to coerce and MSnSet
> > (and/or other relevant data) into an SummarizedExperiment.
> >
> > Hope this helps.
> >
> > Best wishes,
> >
> > Laurent
> >
> > > Thanks and best wishes
> > > Wolfgang
> > >
> > > ___
> > > Bioc-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> > --
> > Laurent Gatto
> > http://cpu.sysbiol.cam.ac.uk/
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Peter Haverty 
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
DataTable, rather than Vector, and subset as x[i,j], but maybe that's
getting a bit off topic.)  I often see people stuffing arbitrary data into
an ExpressionSet and calling one of the assays "exprs" as a work-around.

Regards,

Pete


Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com

On Wed, Nov 26, 2014 at 7:19 AM, Laurent Gatto  wrote:

>
> 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
> > SummarizedExperiment, so that would have to be carried around with
> > NAs, and this is a parsimony argument for using ExpressionSet
> > instead. OTOH, the interface of SummarizedExperiment is cleaner, its
> > code more modern and more likely to be updated, and users of the
> > Bioconductor project are likely to benefit from having to deal with a
> > single interface that works the same or similarly across packages,
> > rather than a variety of formats; which argues that new packages
> > should converge towards SummarizedExperiment('s interface).
> >
> > Are there any pertinent insights from this group?
>
> Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
> essentially an ExpressionSet for quantitative proteomics (i.e it has a
> MIAPE slot, instead of MIAME for example).
>
> Ideally, a SummarizedExperiment for proteomics would use peptide/protein
> ranges, which is in the pipeline, as far as I am concerned. When that
> becomes available, there should be infrastructure to coerce and MSnSet
> (and/or other relevant data) into an SummarizedExperiment.
>
> Hope this helps.
>
> Best wishes,
>
> Laurent
>
> > Thanks and best wishes
> > Wolfgang
> >
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Laurent Gatto
> http://cpu.sysbiol.cam.ac.uk/
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Martin Morgan 

On 11/26/2014 01:39 AM, Joachim Schumann wrote:

Hi everyone,
this morning I got an email from bioconductor.
The message:

According to the "Build/check report" for BioC 3.0,
the flowCHIC package has the following problem(s):
ERROR for 'R CMD check' on zin1.

The error I get is the following:

Error in callGeneric() :
   'callGeneric' with a primitive needs explicit arguments (no formal args 
defined)
Calls: calculate_overlaps_xor ... calculate_overlaps_xor -> .local -> bXOR ->
round -> round -> callGeneric

Does anyone know what the problem is? It seems that the round function causes
the error.


This is some kind of interaction with Matrix

> library(EBImage)
> img = readImage(system.file(package="EBImage", "images", "nuclei.tif"))
> xx = round(img)
> library(Matrix)
> yy = round(img)
Error in callGeneric() :
  'callGeneric' with a primitive needs explicit arguments (no formal args 
defined)

which defines a Math2 group generic. How long has this been appearing? It 
doesn't seem like the build system R, EBImage or Matrix has changed since 
release, and the package is available via biocLite implying that it once built...


Martin



Best,
Joachim




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Laurent Gatto 

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
> SummarizedExperiment, so that would have to be carried around with
> NAs, and this is a parsimony argument for using ExpressionSet
> instead. OTOH, the interface of SummarizedExperiment is cleaner, its
> code more modern and more likely to be updated, and users of the
> Bioconductor project are likely to benefit from having to deal with a
> single interface that works the same or similarly across packages,
> rather than a variety of formats; which argues that new packages
> should converge towards SummarizedExperiment(’s interface).
>
> Are there any pertinent insights from this group?

Instead of ExpressionSet, you could use MSnbase::MSnSet, which is
essentially an ExpressionSet for quantitative proteomics (i.e it has a
MIAPE slot, instead of MIAME for example).

Ideally, a SummarizedExperiment for proteomics would use peptide/protein
ranges, which is in the pipeline, as far as I am concerned. When that
becomes available, there should be infrastructure to coerce and MSnSet
(and/or other relevant data) into an SummarizedExperiment.

Hope this helps.

Best wishes,

Laurent

> Thanks and best wishes
> Wolfgang
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

-- 
Laurent Gatto
http://cpu.sysbiol.cam.ac.uk/

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] SummarizedExperiment vs ExpressionSet

2014-11-26 Thread Wolfgang Huber 
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, and this is a parsimony argument 
for using ExpressionSet instead. OTOH, the interface of SummarizedExperiment is 
cleaner, its code more modern and more likely to be updated, and users of the 
Bioconductor project are likely to benefit from having to deal with a single 
interface that works the same or similarly across packages, rather than a 
variety of formats; which argues that new packages should converge towards 
SummarizedExperiment(’s interface).

Are there any pertinent insights from this group?

Thanks and best wishes
Wolfgang

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] BioC 3.0 CHECK ERROR

2014-11-26 Thread Joachim Schumann 

Hi everyone,
this morning I got an email from bioconductor.
The message:

According to the "Build/check report" for BioC 3.0,
the flowCHIC package has the following problem(s):
ERROR for 'R CMD check' on zin1.

The error I get is the following:

Error in callGeneric() :
  'callGeneric' with a primitive needs explicit arguments (no formal args 
defined)
Calls: calculate_overlaps_xor ... calculate_overlaps_xor -> .local -> bXOR -> round 
-> round -> callGeneric

Does anyone know what the problem is? It seems that the round function 
causes the error.


Best,
Joachim

--
M. Sc. Joachim Schumann
Department of Environmental Microbiology
AG Flow Cytometry
Helmholtz Centre for Environmental Research - UFZ
Permoserstraße 15, 04318 Leipzig
Tel.: 0049-341-235-1330
E-Mail: joachim.schum...@ufz.de
http://www.ufz.de

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel