R devel - Sep 2016 - 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.
> 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]]

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:
>>
>>     > 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