:lawrence.mich...@gene.com>>>,
>> "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org><mailto:bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>>"
>>
>> mailto:bioc-devel@r-project.org><mailto:bioc-devel@r-project.org<ma
iology
>> >> Office: SRB 4.206 Ph: 585.275.5983
>> >>
>> >> Message: 1
>> >> Date: Sun, 10 Feb 2019 13:36:43 +
>> >> From: Aaron Lun > infinite.monkeys.with.keyboa...@gmail.com>>
>> >> To: "Pages, Herve" mailto:hpa...@fre
; mailto:hpa...@fredhutch.org>>,
> Martin Maechler
> >> mailto:maech...@stat.math.ethz.ch>>
> >> Cc: Michael Lawrence lawrence.mich...@gene.com>>,
> >> "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>" <
> bioc
>> mailto:infinite.monkeys.with.keyboa...@gmail.com>>
>> To: "Pages, Herve" mailto:hpa...@fredhutch.org>>,
>> Martin Maechler
>> mailto:maech...@stat.math.ethz.ch>>
>> Cc: Michael Lawrence
>> mailto:lawrence.mich...@gene.com&
ence
> mailto:lawrence.mich...@gene.com>>,
> "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>"
> mailto:bioc-devel@r-project.org>>
> Subject: Re: [Bioc-devel] Pushing towards a better home for matrix
> generics
> Message-ID:
> <15498
t;,
"bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>"
mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] Pushing towards a better home for matrix
generics
Message-ID:
<1549805803.3935.11.ca...@gmail.com<mailto:1549805803.3935.11.ca...@gmail.com>>
Returning to this topic:
It's good to hear some of the rationale behind the current state of
affairs. That said, the set-up we have now is quite difficult to work
with; as mentioned before, I've had to hack around it like:
# Example from "BiocSingular", https://github.com/LTLA/BiocSingular
.safe
Along like the lines of Martin Morgan's comment, simpler signatures
mean simpler software. We can typically limit to single dispatch, and
it indicates how the generic is _meant_ to be used, separating the
data arguments from the modulating accessory parameters. I'm not sure
how valuable dispatching
Multiple dispatch also makes it difficult to reason about method selection, at
least for me.
> setGeneric(f, function(a, b, c) standardGeneric("f"))
[1] "f"
> setMethod(f, c(b="missing"), function(a, b, c) {})
> setMethod(f, c(c="missing"), function(a, b, c) {})
> f()
Note: method with signature
Yes the help system could enforce the full signature for the aliases but
that means the end user then will have to always do
?`colSums,SomeClass,ANY,ANY-method`, which feels unnecessary complicated
and confusing in the case of a generic where dispatching on the 2nd and
3rd arguments hardly make
> Pages, Herve
> on Tue, 29 Jan 2019 16:44:47 + writes:
> Hi Martin. Speed is not the concern: I just did some
> quick benchmarking and didn't observe any significant
> difference in method dispatch performance after doing
> setGeneric("toto", function(x, a=0, b=0
Hi Martin.
Speed is not the concern: I just did some quick benchmarking and didn't
observe any significant difference in method dispatch performance after
doing setGeneric("toto", function(x, a=0, b=0, c=0)
standardGeneric("toto")) vs doing setGeneric("toto", signature="x",
function(x, a=0, b=
> Michael Lawrence
> on Mon, 28 Jan 2019 20:47:58 -0800 writes:
> That will have some consequences; for example,
> documentation aliases will need to change. Not sure how
> many packages will need to be fixed outside of Matrix, but
> it's not an isolated change. Martin
> Michael Lawrence
> on Mon, 28 Jan 2019 19:00:59 -0800 writes:
> I agree (2) is a good compromise. CC'ing Martin for his
> perspective. Michael
Hmm there's quite a bit more it, really:
I'd not be unwilling to do so myself, but in the long history of
Matrix development
That will have some consequences; for example, documentation aliases
will need to change. Not sure how many packages will need to be fixed
outside of Matrix, but it's not an isolated change. Martin might
comment on the rationale for the full signature, since he defined
those generics.
On Mon, Jan
Actually there is a 4th solution which is to modify the definition of
the implicit generics in the methods package (file makeBasicFunsList.R)
to make them dispatch on their 1st arg only. Should be easy. Then no
package will need to use a setGeneric statement anymore. Everybody will
automaticall
I agree (2) is a good compromise. CC'ing Martin for his perspective.
Michael
On Mon, Jan 28, 2019 at 6:58 PM Pages, Herve wrote:
>
> Hi Aaron,
>
> The 4 matrix summarization generics currently defined in BiocGenerics
> are defined as followed:
>
>setGeneric("rowSums", signature="x")
>set
Hi Aaron,
The 4 matrix summarization generics currently defined in BiocGenerics
are defined as followed:
setGeneric("rowSums", signature="x")
setGeneric("colSums", signature="x")
setGeneric("rowMeans", signature="x")
setGeneric("colMeans", signature="x")
The only reason for having t
This is a resurrection of some old threads:
https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012273.html
https://github.com/Bioconductor/MatrixGenerics/issues
For those who are unfamiliar with this, the basic issue is that various
Matrix and BiocGenerics functions mask each other. This is
19 matches
Mail list logo
