gument yet and so do not ignore it, but treat it
as a regular argument (to be concatenated).
One consequence of this change (the above commit) is that in
principle all c() methods which have more than the '...'
arguments should be documented as "they have surprising
arguments&quo
ld print in R.
Currently it prints like what I say should just be the default
method.
Honestly, I'm not sure if it would be straightforward or even
just relatively painless to go to '1) + 2)' ... may change
r71349 (to the S4 generic definition of "c") had dramatical
effect
27; is in the output. That's precisely because 'c.Date' doesn't
have 'use.names', so that 'use.names' is absorbed into '...'.
------------
On Sun, 25/9/16, Martin Maechler wrote:
Subject: Re: [Rd] Undocumented
; its a
base function, hence not hidden ..
As mentioned before, 'use.names' is used in unlist() in quite a
few places, and such an argument also exists for
lengths() and
all.equal.list()
and now c()
> --------
> On Sa
x27;
as an alias.
----
On Sat, 24/9/16, Martin Maechler wrote:
Subject: Re: [Rd] Undocumented 'use.names' argument to c()
To: "Karl Millar"
Date: Saturday, 24 September, 2016, 9:12 PM
>>>>> Karl Millar via R-de
> Karl Millar via R-devel
> on Fri, 23 Sep 2016 11:12:49 -0700 writes:
> 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.
I agree partially.
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
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 themselv
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
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'
> 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
> 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' has an undocumented 'use.names' argument. I'm not sure if this is
a documentation or implementation bug.
> 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
13 matches
Mail list logo
