Re: [Rd] cbind error with check.names
- 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=TRUE is > set. > > data(airquality) > airQualityBind =cbind(airquality,airquality,check.names =TRUE) > > > I understand that cbind is a call to data.frame and the following works: > airQualityBind =data.frame(airquality,airquality,check.names =TRUE) > but I would like to understand why cbind throws an error. > > I asked this question on SO here: > http://stackoverflow.com/questions/17810470/cbind-error-with-check-names > and user Hong Ooi confirmed my suspicion that cbind was passing check.names = > FALSE regardless of my setting that option, even though the help file > indicates that this should be possible, > > "For the "data.frame" method of cbind these can be further arguments to > data.frame such as stringsAsFactors." > > Is there some design principle that I am missing here? Well, the function does work as documented. See the help file section on "Data frame methods", which says "The 'cbind' data frame method is just a wrapper for 'data.frame(..., check.names = FALSE)'". Best, Ista 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. Thanks __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cbind error with check.names
- 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: "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=TRUE is >> set. >> >> data(airquality) >> airQualityBind =cbind(airquality,airquality,check.names =TRUE) >> >> >> I understand that cbind is a call to data.frame and the following works: >> airQualityBind =data.frame(airquality,airquality,check.names =TRUE) >> but I would like to understand why cbind throws an error. >> >> I asked this question on SO here: >> http://stackoverflow.com/questions/17810470/cbind-error-with-check-names >> and user Hong Ooi confirmed my suspicion that cbind was passing check.names >> = FALSE regardless of my setting that option, even though the help file >> indicates that this should be possible, >> >> "For the "data.frame" method of cbind these can be further arguments to >> data.frame such as stringsAsFactors." >> >> Is there some design principle that I am missing here? > > > Well, the function does work as documented. See the help file section > on "Data frame methods", which says "The 'cbind' data frame method is > just a wrapper for 'data.frame(..., check.names = FALSE)'". > > Best, > Ista > > > > 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 same argument more than once. There are exceptions to this, e.g., sum(c(NA, 1:10), na.rm=TRUE, na.rm=FALSE) but in general each argument can only be matched once. Since cbind.data.frame calls data.frame with check.names=FALSE, you can't supply it again. Best, Ista > > Thanks > Yikes, no. As I mentioned to the SO poster, I get that bit. 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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cbind error with check.names
> 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 same argument more than once. There are exceptions to this, e.g., sum(c(NA, 1:10), na.rm=TRUE, na.rm=FALSE) but in general each argument can only be matched once. Since cbind.data.frame calls data.frame with check.names=FALSE, you can't supply it again. Best, Ista > > Thanks > Yikes, no. As I mentioned to the SO poster, I get that bit. 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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Understanding modification in place
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))
x[2] <- 1L
.Internal(inspect(x))
})()
If I run it from the command line, I get:
Global
@1050bb840 13 INTSXP g0c2 [MARK,NAM(1)] (len=3, tl=0) 1,2,3
@1050bb840 13 INTSXP g0c2 [MARK,NAM(1)] (len=3, tl=0) 1,1,3
In function
@1050bb190 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
@1050bb190 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
i.e. both modifications occur in place.
If I put it in a file and source() it, I get:
Global
@1050bb318 13 INTSXP g0c2 [NAM(2)] (len=3, tl=0) 1,2,3
@1050bb698 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
In function
@1050b8958 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
@1050b8958 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
i.e. in the global environment a copy is created.
Why is there a difference?
Thanks!
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cbind error with check.names
> 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 no duplicate names and it makes sure that all the names are syntactic names. If you have created a data.frame with non-syntactic names you would be annoyed if a call to cbind mangled its names, hence cbind.data.frame sets check.names=FALSE to avoid this. > d1 <- data.frame(`Mass (g)`=102, `Conc (% by vol.)`=0.23, check.names=FALSE) > d2 <- data.frame(`Accel (m/s/s)`=9.81, `Conc (% by vol.)`=0.23, check.names=FALSE) > names(d1) [1] "Mass (g)" "Conc (% by vol.)" > names(d2) [1] "Accel (m/s/s)""Conc (% by vol.)" > names(data.frame(d1, d2, check.names=TRUE)) [1] "Mass..g." "Concby.vol.." "Accel..m.s.s." "Concby.vol...1" > names(data.frame(d1, d2, check.names=FALSE)) [1] "Mass (g)" "Conc (% by vol.)" "Accel (m/s/s)""Conc (% by vol.)" > names(cbind(d1, d2)) [1] "Mass (g)" "Conc (% by vol.)" "Accel (m/s/s)""Conc (% by vol.)" Perhaps data.frame() should throw an error if there are duplicate names, or perhaps it should have a separate argument to say what to do about duplicate names, but changing that sort of thing now would break a fair bit of code. Perhaps cbind.data.frame should not call data.frame, but copy the work that data.frame does or perhaps it should check for duplicate names on the output of data.frame(). Is it worth the time to do that? Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On > Behalf > Of Fg Nu > Sent: Tuesday, July 23, 2013 10:48 AM > To: Ista Zahn > Cc: r-devel@r-project.org > Subject: Re: [Rd] cbind error with check.names > > > > > 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 same argument more than once. There > are exceptions to this, e.g., > > sum(c(NA, 1:10), na.rm=TRUE, na.rm=FALSE) > > but in general each argument can only be matched once. Since > cbind.data.frame calls data.frame with check.names=FALSE, you can't > supply it again. > > Best, > Ista > > > > > Thanks > > > > > > Yikes, no. As I mentioned to the SO poster, I get that bit. > > 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. > > __ > 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] Understanding modification in place
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))
>
> message("In function")
> (function() {
> x <- 1:3
> .Internal(inspect(x))
> x[2] <- 1L
> .Internal(inspect(x))
> })()
>
> If I run it from the command line, I get:
>
> Global
> @1050bb840 13 INTSXP g0c2 [MARK,NAM(1)] (len=3, tl=0) 1,2,3
> @1050bb840 13 INTSXP g0c2 [MARK,NAM(1)] (len=3, tl=0) 1,1,3
> In function
> @1050bb190 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
> @1050bb190 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
>
> i.e. both modifications occur in place.
>
> If I put it in a file and source() it, I get:
>
> Global
> @1050bb318 13 INTSXP g0c2 [NAM(2)] (len=3, tl=0) 1,2,3
> @1050bb698 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
> In function
> @1050b8958 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
> @1050b8958 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
>
> i.e. in the global environment a copy is created.
>
> Why is there a difference?
>
Did you look at source()? ;)
It has to do with all the additional processing there which assigns the result
of every line locally thus producing extra copies. If you just eval it, you'll
get the same behavior as in the console:
> p=parse("test.R")
> eval(p)
Global
@100816498 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
@100816498 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
In function
@102c42378 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3
@102c42378 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,1,3
The same is true is you just put { } around it and source it so it becomes a
single expression.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Alpha channel in colorRamp() and colorRampPalette()
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 those simple modifications might be useful for other people, so
perhaps it would be worth to add them to colorRamp and colorRampPalette codes
in grDevices… the modified functions follows.
Cheers,
Alberto.
colorRampPalette <- function (colors, ...) {
ramp <- colorRamp(colors, ...)
function(n) {
x <- ramp(seq.int(0, 1, length.out = n))
rgb(x[, 1], x[, 2], x[, 3], x[, 4], maxColorValue = 255)
}
}
colorRamp <- function (colors, bias = 1, space = c("rgb", "Lab"), interpolate =
c("linear", "spline")) {
if (bias <= 0)
stop("'bias' must be positive")
colors <- t(col2rgb(colors, alpha=T)/255)
space <- match.arg(space)
interpolate <- match.arg(interpolate)
if (space == "Lab") {
colors <- convertColor(colors, from = "sRGB", to = "Lab")
}
interpolate <- switch(interpolate, linear = stats::approxfun, spline =
stats::splinefun)
if ((nc <- nrow(colors)) == 1L) {
colors <- colors[c(1L, 1L), ]
nc <- 2L
}
x <- seq.int(0, 1, length.out = nc)^bias
palette <- c(interpolate(x, colors[, 1]), interpolate(x, colors[, 2]),
interpolate(x, colors[, 3]), interpolate(x, colors[, 4]))
roundcolor <- function(rgb) pmax(pmin(rgb, 1), 0)
if (space == "Lab") {
function(x) {
roundcolor(convertColor(cbind(palette[[1L]](x), palette[[2L]](x),
palette[[3L]](x), palette[[4L]](x)), from = "Lab", to =
"sRGB")) *
255
}
}
else {
function(x) {
roundcolor(cbind(palette[[1L]](x), palette[[2L]](x),
palette[[3L]](x), palette[[4L]](x))) * 255
}
}
}
Universidade de Lisboa - Laboratório SIM
Alberto Krone-Martins
http://www.astro.iag.usp.br/~algol
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
