Hi,
On 01/23/2015 07:01 AM, luke-tier...@uiowa.edu wrote:
On Thu, 22 Jan 2015, Michael Lawrence wrote:
On Thu, Jan 22, 2015 at 11:44 AM, <luke-tier...@uiowa.edu> wrote:
For default methods there ought to be a way to create those so the
default method is computed at creation or load time and stored in an
environment.
We had considered that, but we thought the definition of the function
would be easier to interpret if it explicitly specified the namespace,
instead of using tricks with environments. The same applies for
memoizing the lookup in front of a loop.
interpret in what sense (human reader or R interpreter)? In either
case I'm not convinced.
From a developer perspective, especially when debugging, when we do
selectMethod("match", ...) and it turns out that this returns the
default method, it's good to see:
Method Definition (Class "derivedDefaultMethod"):
function (x, table, nomatch = NA_integer_, incomparables = NULL,
...)
base::match(x, table, nomatch = nomatch, incomparables = incomparables,
...)
<environment: namespace:BiocGenerics>
Signatures:
x table
target "DataFrame" "ANY"
defined "ANY" "ANY"
rather than some obscure/uninformative body. I hope we can keep that.
The implementation of these functions is almost simpler in C than it
is in R, so there is relatively little risk to this change. But I
agree the benefits are also somewhat minor.
I don't disagree, but it remains that even calling the C version has
costs that should not need to be paid. But maybe we can leave that to
the compiler/byte code engine. Optimizing references to symbols
resolved statically to name spaces and imports is on the to do list,
and with a little care that mechanism should work for foo::bar uses as
well.
That would be great. Thanks!
H.
Best,
luke
For other cases if I want to use foo::bar many times, say
in a loop, I would do
foo_bar <- foo::bar
and use foo_bar, or something along those lines.
When :: and ::: were introduce they were intended primarily for
reflection and debugging, so speed was not an issue. ::: is still
really only reliably usable that way, and making it faster may just
encourage bad practice. :: is different and there are good arguments
for using it in code, but I'm not yet seeing good arguments for use in
ways that would be performance-critical, but I'm happy to be convinced
otherwise. If there is a need for a faster :: then going to a
SPECIALSXP is fine; it would also be good to make the byte code
compiler aware of it, and possibly to work on ways to improve the
performance further e.g. through cacheing.
Best,
luke
On Thu, 22 Jan 2015, Peter Haverty wrote:
Hi all,
When S4 methods are defined on base function (say, "match"), the
function becomes a method with the body "base::match(x,y)". A call to
such a function often spends more time doing "::" than in the function
itself. I always assumed that "::" was a very low-level thing, but it
turns out to be a plain old function defined in base/R/namespace.R.
What would you all think about making "::" and ":::" .Primitives? I
have submitted some examples, timings, and a patch to the R bug
tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134).
I'd be very interested to hear your thoughts on the matter.
Regards,
Pete
____________________
Peter M. Haverty, Ph.D.
Genentech, Inc.
phave...@gene.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
