Undocumented 'use.names' argument to c()
I'd vote for it to stay. It could of course suprise someone who'd expect c(list(a=1), b=2, use.names = FALSE) to generate list(a=1, b=2, use.names=FALSE). On the upside, is the performance gain from using use.names=FALSE. Below benchmarks show that the combining of the names attributes themselves takes ~20-25 times longer than the combining of the integers themselves. Also, at no surprise, use.names=FALSE avoids some memory allocations.
options(digits = 2) a <- b <- c <- d <- 1:1e4 names(c) <- c names(d) <- d stats <- microbenchmark::microbenchmark(
+ c(a, b, use.names=FALSE), + c(c, d, use.names=FALSE), + c(a, d, use.names=FALSE), + c(a, b, use.names=TRUE), + c(a, d, use.names=TRUE), + c(c, d, use.names=TRUE), + unit = "ms" + )
stats
Unit: milliseconds
expr min lq mean median uq max neval
c(a, b, use.names = FALSE) 0.031 0.032 0.049 0.034 0.036 1.474 100
c(c, d, use.names = FALSE) 0.031 0.031 0.035 0.034 0.035 0.064 100
c(a, d, use.names = FALSE) 0.031 0.031 0.049 0.034 0.035 1.452 100
c(a, b, use.names = TRUE) 0.031 0.031 0.055 0.034 0.036 2.094 100
c(a, d, use.names = TRUE) 0.510 0.526 0.588 0.549 0.617 1.998 100
c(c, d, use.names = TRUE) 0.780 0.815 0.886 0.841 0.944 1.430 100
profmem::profmem(c(c, d, use.names=FALSE))
Rprofmem memory profiling of:
c(c, d, use.names = FALSE)
Memory allocations:
bytes calls
1 80040 <internal>
total 80040
profmem::profmem(c(c, d, use.names=TRUE))
Rprofmem memory profiling of:
c(c, d, use.names = TRUE)
Memory allocations:
bytes calls
1 80040 <internal>
2 160040 <internal>
total 240080
/Henrik
On Fri, Sep 23, 2016 at 10:25 AM, William Dunlap via R-devel
<r-devel at r-project.org> wrote:
In Splus c() and unlist() called the same C code, but with a different 'sys_index' code (the last argument to .Internal) and c() did not consider an argument named 'use.names' special.
c
function(..., recursive = F) .Internal(c(..., recursive = recursive), "S_unlist", TRUE, 1)
unlist
function(data, recursive = T, use.names = T) .Internal(unlist(data, recursive = recursive, use.names = use.names), "S_unlist", TRUE, 2)
c(A=1,B=2,use.names=FALSE)
A B use.names
1 2 0
The C code used sys_index==2 to mean 'the last argument is the 'use.names'
argument, if sys_index==1 only the recursive argument was considered
special.
Sys.funs.c:
405 S_unlist(vector *ent, vector *arglist, s_evaluator *S_evaluator)
406 {
407 int which = sys_index; boolean named, recursive, names;
...
419 args = arglist->value.tree; n = arglist->length;
...
424 names = which==2 ? logical_value(args[--n], ent, S_evaluator)
: (which == 1);
Thus there is no historical reason for giving c() the use.names argument.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Sep 23, 2016 at 9:37 AM, Suharto Anggono Suharto Anggono via
R-devel <r-devel at r-project.org> wrote:
In S-PLUS 3.4 help on 'c' (http://www.uni-muenster.de/ ZIV.BennoSueselbeck/s-html/helpfiles/c.html), there is no 'use.names' argument. Because 'c' is a generic function, I don't think that changing formal arguments is good. In R devel r71344, 'use.names' is not an argument of functions 'c.Date', 'c.POSIXct' and 'c.difftime'. Could 'use.names' be documented to be accepted by the default method of 'c', but not listed as a formal argument of 'c'? Or, could the code that handles the argument name 'use.names' be removed? ----------------
David Winsemius <dwinsemius at comcast.net>
on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel <r-devel at
r-project.org> wrote:
>>
>> 'c' has an undocumented 'use.names' argument. I'm not sure if this
is
>> a documentation or implementation bug.
> It came up on stackoverflow a couple of years ago:
function-c-accept-an-undocumented-argument/24815653#24815653
> At the time it appeared to me to be a documentation lag.
Thank you, Karl and David, yes it is a documentation glitch ... and a bit more: Experts know that print()ing of primitive functions is, eehm, "special". I've committed a change to R-devel ... (with the intent to port to R-patched). Martin
>>
>>> c(a = 1)
>> a
>> 1
>>> c(a = 1, use.names = F)
>> [1] 1
>>
>> Karl
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel