Suharto Anggono Suharto Anggono
2016-Sep-23 16:37 UTC
[Rd] Undocumented 'use.names' argument to c()
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: > http://stackoverflow.com/questions/24815572/why-does-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
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.> cfunction(..., recursive = F) .Internal(c(..., recursive = recursive), "S_unlist", TRUE, 1)> unlistfunction(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: > > > http://stackoverflow.com/questions/24815572/why-does- > 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]]
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" + )> > statsUnit: 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: >> >> > http://stackoverflow.com/questions/24815572/why-does- >> 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