Re: [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 > on Tue, 20 Sep 2016 23:46:48 -0700 writes: >> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented 'use.names' argument to c()
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 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
> > on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>
> >> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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 minlq mean medianuq 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
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
2 160040
total 240080
/Henrik
On Fri, Sep 23, 2016 at 10:25 AM, William Dunlap via R-devel
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 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
>> > on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>>
>> >> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel > 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Undocumented 'use.names' argument to c()
I'd expect that a lot of the performance overhead could be eliminated
by simply improving the underlying code. IMHO, we should ignore it in
deciding the API that we want here.
On Fri, Sep 23, 2016 at 10:54 AM, Henrik Bengtsson
wrote:
> 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 minlq mean medianuq 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
> 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
> 2 160040
> total 240080
>
> /Henrik
>
> On Fri, Sep 23, 2016 at 10:25 AM, William Dunlap via R-devel
> 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 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
>>> > on Tue, 20 Sep 2016 23:46:48 -0700 writes:
>>>
>>> >> On Sep 20, 2016, at 7:18 PM, Karl Millar via R-devel >> 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
>>>
>>> _
