- Original Message -
From: Ista Zahn
To: Fg Nu
Cc: "r-devel@r-project.org"
Sent: Tuesday, July 23, 2013 9:50 PM
Subject: Re: [Rd] cbind error with check.names
On Tue, Jul 23, 2013 at 9:18 AM, Fg Nu wrote:
>
>
>
> Here is an example where cbind fails with an error when check.names=TR
- Original Message -
From: Ista Zahn
To: Fg Nu
Cc: "r-devel@r-project.org"
Sent: Tuesday, July 23, 2013 11:05 PM
Subject: Re: [Rd] cbind error with check.names
On Tue, Jul 23, 2013 at 12:54 PM, Fg Nu wrote:
>
>
>
> - Original Message -
> From: Ista Zahn
> To: Fg Nu
> Cc:
> Is there then a reason that overriding the check.names default is forbidden
> from cbind? I can't tell why this would be the case.
For the same reason you can't have
data.frame(x=1:10, x=11:20, check.names=TRUE, check.names=FALSE)
or
mean(x=1:10, x=11:20)
i.e, you can't generally pass the
Hi all,
Take this simple script, which I'm trying to use to understand when
modification in-place occurs, and when a new object is created:
message("Global")
x <- 1:3
.Internal(inspect(x))
x[2] <- 1L
.Internal(inspect(x))
message("In function")
(function() {
x <- 1:3
.Internal(inspect(x))
> I meant what is the design principle behind check.names being hardcoded to
> FALSE.
> I see no conflict with the purpose of cbind from the ability to specify
> check.names
> at the level of cbind.
One rationale is that data.frame(check.names=TRUE,...) does two things: it makes
sure there are n
On Jul 24, 2013, at 10:35 AM, Hadley Wickham wrote:
> Hi all,
>
> Take this simple script, which I'm trying to use to understand when
> modification in-place occurs, and when a new object is created:
>
> message("Global")
> x <- 1:3
> .Internal(inspect(x))
> x[2] <- 1L
> .Internal(inspect(x))
>
Hi all,
I had the need to create a colorbar considering the alpha channel of the
colors, but colorRamp() and colorRampPalette() ignored the alpha argument in
rgb(). So I performed some minor modifs. in their codes, as to support the
interpolation using the alpha channel.
I guess that th
