Re: [Rd] findInterval
The other problem in this example is setting NA's.
replace(x, x == 0, NA)
requires two instances of x making it not very pipe friendly. In
dplyr there is na_if
to address that problem and base R might have something that addresses this
so we don't have to define our own zero2na as the base of R now has pipes.
On Tue, Sep 17, 2024 at 12:14 PM Martin Maechler
wrote:
>
> >>>>> Gabor Grothendieck
> >>>>> on Mon, 16 Sep 2024 11:21:55 -0400 writes:
>
> > Suppose we have `dat` shown below and we want to find the the `y` value
> > corresponding to the last value in `x` equal to the corresponding
> component
> > of `seek` and we wish to return an output the same length as `seek`
> using
> > `findInterval` to perform the search. This returns the correct result:
>
> > dat <- data.frame(x = c(2, 2, 3, 4, 4, 4),
> > y = c(37, 12, 19, 30, 6, 15),
> > seek = 1:6)
>
> > zero2na <- function(x) replace(x, x == 0, NA)
>
> > dat |>
> > transform(dat, result = y[ zero2na(findInterval(seek, x)) ] ) |>
> > _$result
> > ## [1] NA 12 19 15 15 15
>
> I'd write that as
>
> with(dat, y[ zero2na(findInterval(seek, x)) ] )
>
> so I can read it with jumping hoops and stand on my head ...
>
> > Since `findInterval` returns an index it is natural that the next step
> be
> > to use the index and it is also common that we want a result that is the
> > same length as the input.
>
> I think your example where x and y are of the same length
> not typical.
>
> Not that the design of findInterval(x, vec, ..) is indeed to always return
> an index, but there isn't any "nomatch", but rather a
> - "left of the leftmost", i.e., an x[i] < vec[1] (as 'vec' must be
> sorted increasingly) or
> - "right of rightmost" , i.e., an x[i] > vec[length(vec)]
>
> and these should give *different* results (and not both the
> same).
>
> I don't think 'nomatch' would improve the relatively clean findInterval()
> behavior.
>
> There are three logical switches ... which allow 2^3
> variants of which I now guess only 6 differ:
>
> Here's some R code showing the possibilities:
>
>
> (argsTF <- names(formals(findInterval))[-(1:2)]) # "rightmost.closed"
> "all.inside" "left.open"
> FT <- c(FALSE, TRUE)
> allFT <- as.matrix(expand.grid(rightmost.closed = FT,
>all.inside = FT,
>left.open= FT))
> allFT
> (cn <- substr(colnames(allFT), 1,1)) # "r" "a" "l"
>
> x <- 2:18
> v <- c(5, 10, 15) # create two bins [5,10) and [10,15)
>
> fiAll <- apply(allFT, 1, function(r.a.f)
> do.call(findInterval, c(list(x, v), as.list(r.a.f
>
> cbind(x, fiAll) # has all info
>
> ## must find cool 'column names' for fiAll: construct from r.., a.., l.. = F
> / T
> (cn1 <- apply(`dim<-`(c(".","|")[allFT+1L], dim(allFT)), 1, paste0,
> collapse=""))
> ## "..." "|.." ".|." "||." "..|" "|.|" ".||" "|||"
> colnames(fiAll) <- cn1
> cbind(x, fiAll) ## --> col. 3 == 4 and 7 == 8
> ##==> show only unique columns:
> cbind(x, t(unique(t(fiAll
> ## x ... |.. .|. ..| |.| .||
> ## 2 0 0 1 0 0 1
> ## 3 0 0 1 0 0 1
> ## 4 0 0 1 0 0 1
> ## 5 1 1 1 0 1 1
> ## 6 1 1 1 1 1 1
> ## 7 1 1 1 1 1 1
> ## 8 1 1 1 1 1 1
> ## 9 1 1 1 1 1 1
> ## 10 2 2 2 1 1 1
> ## 11 2 2 2 2 2 2
> ## 12 2 2 2 2 2 2
> ## 13 2 2 2 2 2 2
> ## 14 2 2 2 2 2 2
> ## 15 3 2 2 2 2 2
> ## 16 3 3 2 3 3 2
> ## 17 3 3 2 3 3 2
> ## 18 3 3 2 3 3 2
>
>
> Martin
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] findInterval
Suppose we have `dat` shown below and we want to find the the `y` value corresponding to the last value in `x` equal to the corresponding component of `seek` and we wish to return an output the same length as `seek` using `findInterval` to perform the search. This returns the correct result: dat <- data.frame(x = c(2, 2, 3, 4, 4, 4), y = c(37, 12, 19, 30, 6, 15), seek = 1:6) zero2na <- function(x) replace(x, x == 0, NA) dat |> transform(dat, result = y[ zero2na(findInterval(seek, x)) ] ) |> _$result ## [1] NA 12 19 15 15 15 Since `findInterval` returns an index it is natural that the next step be to use the index and it is also common that we want a result that is the same length as the input. The extra step here is to convert the 0 which `findInterval` hard codes as missing to NA. If, like `match`, the `findInterval` function had a `nomatch=` argument we could have written this as follows which is shorter, more understandable and avoids the need for zero2na: # if nomatch= were implemented seek |> transform(result = y[ findInterval(x, nomatch = NA) ] ) |> _$result -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] transform
Suggest you look at dplyr::mutate as this functionality is widely used there and has shown itself to be useful. On Tue, Aug 27, 2024 at 9:16 AM Sebastian Meyer wrote: > > Am 27.08.24 um 11:55 schrieb peter dalgaard: > > Yes. A quirk, rather than a bug I'd say. One issue is that the internal > > logic of transform() relies on > > > > e <- eval(substitute(list(...)), `_data`, parent.frame()) > > tags <- names(e) > > > > so untagged entries in ... will not be included. > > ... unless at least one is tagged: > > R> transform(BOD, 0:5, 1:6) >Time demand > 118.3 > 22 10.3 > 33 19.0 > 44 16.0 > 55 15.6 > 67 19.8 > > R> transform(BOD, 0:5, 1:6, foo = 1) >Time demand 0:5 1:6 foo > 118.3 0 1 1 > 22 10.3 1 2 1 > 33 19.0 2 3 1 > 44 16.0 3 4 1 > 55 15.6 4 5 1 > 67 19.8 5 6 1 > > But as transform.data.frame is only documented for tagged vector > expressions, all examples provided in this thread were formal misuses. > (It might make sense to warn about untagged entries.) > > Personally, I'd be quite confused about what to expect from syntax like > > transform(BOD, data.frame(y = 1:6)) > > as really no transformation is specified. Looks like cbind() or > data.frame() was meant. > > Sebastian > > > > The other part is a direct consequence of a quirk in data.frame: > > > >> data.frame(head(airquality), y=data.frame(x=rnorm(6))) > >Ozone Solar.R Wind Temp Month Day x > > 141 190 7.4 67 5 1 0.3075402 > > 236 118 8.0 72 5 2 0.7765265 > > 312 149 12.6 74 5 3 0.3909341 > > 418 313 11.5 62 5 4 0.4733170 > > 5NA NA 14.3 56 5 5 -0.6947709 > > 628 NA 14.9 66 5 6 0.1126040 > > > > whereas (the wisdom of this escapes me) > > > >> data.frame(head(airquality), y=data.frame(x=rnorm(6),z=rnorm(6))) > >Ozone Solar.R Wind Temp Month Dayy.x y.z > > 141 190 7.4 67 5 1 -0.9250228 0.46483406 > > 236 118 8.0 72 5 2 -0.5035793 0.28822668 > > ... > > > > On the whole, I think that transform was never designed (nor documented) to > > take data frame arguments, so caveat emptor. > > > > - Peter > > > > > >> On 24 Aug 2024, at 16:41 , Gabor Grothendieck > >> wrote: > >> > >> One oddity in transform that I recently noticed. It seems that to include > >> a one-column data frame in the arguments one must name it even though the > >> name is ignored. If the data frame has more than one column then it must > >> also be named but in that case it is not ignored and the names are made up > >> of > >> a combination of that name and the data frame's names. I would have > >> thought > >> that if we did not want a combination of names we would just not name the > >> argument. > >> > >> # ignores second argument returning BOD unchanged > >> transform(BOD, data.frame(y = 1:6)) |> names() > >> ## [1] "Time" "demand" > >> > >> # ignores second argument returning BOD unchanged > >> transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() > >> ## [1] "Time" "demand" > >> > >> # with one column in data frame it adds the column and names it y > >> ignoring x > >> transform(BOD, x = data.frame(y = 1:6)) |> names() > >> ## [1] "Time" "demand" "y" > >> > >> # with multiple columns in data frame it uses x.y and x.z as names > >> transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() > >> ## [1] "Time" "demand" "x.y""x.z" > >> > >> > >> -- > >> Statistics & Software Consulting > >> GKX Group, GKX Associates Inc. > >> tel: 1-877-GKX-GROUP > >> email: ggrothendieck at gmail.com > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency between row and nrow
The fact that it is consistent with the documentation is not the point. The point is that the design itself is inconsistent. On Sun, Sep 8, 2024 at 8:27 AM Marc Schwartz wrote: > > Hi Gabor, > > In strictly reading the help files for both nrow() and row(), the 'x' > argument in the former case is "a vector, array, data frame, or NULL.", > whereas in the latter case it is "a matrix-like object, that is one with a > two-dimensional dim.". > > Thus, I would expect row() to fail on a >= 3-dimensional array, as your > example shows. > > In reading the help file for slice.index(), there is the following in the See > Also section: > > "row and col for determining row and column indexes; in fact, these are > special cases of slice.index corresponding to MARGIN equal to 1 and 2, > respectively when x is a matrix." > > further differentiating the behavior of row() and col() as more specific > implementations in the 2-dimensional case. > > To my read then, the difference in behavior appears to be intentional and > expected. > > Regards, > > Marc Schwartz > > > -Original Message- > From: R-devel <mailto:r-devel-boun...@r-project.org>> on behalf of Gabor Grothendieck > mailto:ggrothendi...@gmail.com>> > Date: Sunday, September 8, 2024 at 7:31 AM > To: "r-devel@r-project.org <mailto:r-devel@r-project.org>" > mailto:r-devel@r-project.org>> > Subject: [Rd] Inconsistency between row and nrow > > > In the following nrow provides the expected result but row gives an > error. I would have thought that they would both work or both fail. > > > aa <- array(dim = 5:3) > > > nrow(aa) > ## [1] 5 > > > row(aa) > ## Error in row(aa) : a matrix-like object is required as argument to 'row' > > > # this does work: > slice.index(aa, 1) > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > > __ > R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > <https://stat.ethz.ch/mailman/listinfo/r-devel> > > > > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistency between row and nrow
In the following nrow provides the expected result but row gives an error. I would have thought that they would both work or both fail. aa <- array(dim = 5:3) nrow(aa) ## [1] 5 row(aa) ## Error in row(aa) : a matrix-like object is required as argument to 'row' # this does work: slice.index(aa, 1) -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] transform
It could be enhanced to handle data frame argos. Unnamed args are currently just ignored so adding such would be backwards compatible. Any interest in this? On Tue, Aug 27, 2024 at 5:55 AM peter dalgaard wrote: > > Yes. A quirk, rather than a bug I'd say. One issue is that the internal logic > of transform() relies on > > e <- eval(substitute(list(...)), `_data`, parent.frame()) > tags <- names(e) > > so untagged entries in ... will not be included. The other part is a direct > consequence of a quirk in data.frame: > > > data.frame(head(airquality), y=data.frame(x=rnorm(6))) > Ozone Solar.R Wind Temp Month Day x > 141 190 7.4 67 5 1 0.3075402 > 236 118 8.0 72 5 2 0.7765265 > 312 149 12.6 74 5 3 0.3909341 > 418 313 11.5 62 5 4 0.4733170 > 5NA NA 14.3 56 5 5 -0.6947709 > 628 NA 14.9 66 5 6 0.1126040 > > whereas (the wisdom of this escapes me) > > > data.frame(head(airquality), y=data.frame(x=rnorm(6),z=rnorm(6))) > Ozone Solar.R Wind Temp Month Dayy.x y.z > 141 190 7.4 67 5 1 -0.9250228 0.46483406 > 236 118 8.0 72 5 2 -0.5035793 0.28822668 > ... > > On the whole, I think that transform was never designed (nor documented) to > take data frame arguments, so caveat emptor. > > - Peter > > > > On 24 Aug 2024, at 16:41 , Gabor Grothendieck > > wrote: > > > > One oddity in transform that I recently noticed. It seems that to include > > a one-column data frame in the arguments one must name it even though the > > name is ignored. If the data frame has more than one column then it must > > also be named but in that case it is not ignored and the names are made up > > of > > a combination of that name and the data frame's names. I would have thought > > that if we did not want a combination of names we would just not name the > > argument. > > > > # ignores second argument returning BOD unchanged > > transform(BOD, data.frame(y = 1:6)) |> names() > > ## [1] "Time" "demand" > > > > # ignores second argument returning BOD unchanged > > transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() > > ## [1] "Time" "demand" > > > > # with one column in data frame it adds the column and names it y ignoring > > x > > transform(BOD, x = data.frame(y = 1:6)) |> names() > > ## [1] "Time" "demand" "y" > > > > # with multiple columns in data frame it uses x.y and x.z as names > > transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() > > ## [1] "Time" "demand" "x.y""x.z" > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] transform
One oddity in transform that I recently noticed. It seems that to include a one-column data frame in the arguments one must name it even though the name is ignored. If the data frame has more than one column then it must also be named but in that case it is not ignored and the names are made up of a combination of that name and the data frame's names. I would have thought that if we did not want a combination of names we would just not name the argument. # ignores second argument returning BOD unchanged transform(BOD, data.frame(y = 1:6)) |> names() ## [1] "Time" "demand" # ignores second argument returning BOD unchanged transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() ## [1] "Time" "demand" # with one column in data frame it adds the column and names it y ignoring x transform(BOD, x = data.frame(y = 1:6)) |> names() ## [1] "Time" "demand" "y" # with multiple columns in data frame it uses x.y and x.z as names transform(BOD, data.frame(y = 1:6, z = 6:1)) |> names() ## [1] "Time" "demand" "x.y""x.z" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] head.ts, tail.ts loses time
It isn't really clear that it can't work. This does work by inserting NA's.
library(zoo)
as.ts(as.zoo(lynx)[ c(1:3, 7) ] )
## Time Series:
## Start = 1821
## End = 1827
## Frequency = 1
## [1] 269 321 585 NA NA NA 3928
On Mon, Jun 10, 2024 at 10:32 AM Martin Maechler
wrote:
>
> >>>>> Spencer Graves
> >>>>> on Mon, 10 Jun 2024 07:50:13 -0500 writes:
>
> > Hi, Gabor et al.: Thanks for this. I should change my
> > current application to use either zoo or xts, as Gabor
> > suggests.
>
>
> > However, I was surprised to learn that "[.ts" does NOT
> > return an object of class "ts". I see that "head.default"
> > and "head.matrix" both call "[", so "head" cannot return a
> > ts object, because "[" doesn't.
>
> Yes, the default head() and tail() are built on `[` very much
> on purpose.
> Note that `[` should *not* keep the "ts" property in
> general, e.g.,
> lynx[c(1:3, 7)]
> cannot be a regular time series
>
> I think I'd consider using windows() for a head.ts() and tail.ts(),
> but in any case, I am sympathetic adding such methods to "base R"'s
> utils package.
>
>
> Martin
>
> > Best Wishes, Spencer Graves
>
>
> > On 6/9/24 8:40 PM, Gabor Grothendieck wrote:
> >> zoo overcomes many of the limitations of ts:
> >>
> >> library(zoo) as.ts(head(as.zoo(presidents))) ## Qtr1 Qtr2
> >> Qtr3 Qtr4 ## 1945 NA 87 82 75 ## 1946 63 50
> >>
> >> xts also works here.
> >>
> >> On Sun, Jun 9, 2024 at 12:04 PM Spencer Graves
> >> wrote:
> >>>
> >>> Hello, All:
> >>>
> >>>
> >>> The 'head' and 'tail' functions strip the time from a
> >>> 'ts' object. Example:
> >>>
> >>>
> >>> > head(presidents) [1] NA 87 82 75 63 50
> >>>
> >>>
> >>> > window(presidents, 1945, 1946.25) Qtr1 Qtr2 Qtr3 Qtr4
> >>> 1945 NA 87 82 75 1946 63 50
> >>>
> >>>
> >>> Below please find code for 'head.ts' and 'tail.ts' that
> >>> matches 'window'.
> >>>
> >>>
> >>> Comments? Spencer Graves
> >>>
> >>> head.ts <- function(x, n=6L, ...){ tmx <-
> >>> as.numeric(time(x))
> >>> #
> >>> utils:::checkHT(n, d <- dim(x)) if(is.na(n[1]) ||
> >>> n[1]==0)ts(NULL)
> >>> #
> >>> firstn <- head(tmx, n[1]) if(is.null(d)){
> >>> return(window(x, firstn[1], tail(firstn, 1))) } else{
> >>> if(length(n)<2){ return(window(x, firstn[1],
> >>> tail(firstn, 1))) } else { Cols <- head(1:d[2], n[2])
> >>> xn2 <- x[, Cols[1]:tail(Cols, 1)] return(window(xn2,
> >>> firstn[1], tail(firstn, 1))) } } }
> >>>
> >>>
> >>> tail.ts <- function (x, n = 6L, ...) {
> >>> utils:::checkHT(n, d <- dim(x)) tmx <-
> >>> as.numeric(time(x))
> >>> #
> >>> if(is.na(n[1]) || n[1]==0)ts(NULL)
> >>> #
> >>> lastn <- tail(tmx, n[1]) if(is.null(d)){
> >>> return(window(x, lastn[1], tail(lastn, 1))) } else{
> >>> if(length(n)<2){ return(window(x, lastn[1], tail(lastn,
> >>> 1))) } else { Cols <- head(1:d[2], n[2]) xn2 <- x[,
> >>> Cols[1]:tail(Cols, 1)] return(window(xn2, lastn[1],
> >>> tail(lastn, 1))) } } }
> >>>
> >>>
> >>> # examples head(presidents)
> >>>
> >>> head(presidents, 2)
> >>>
> >>> npresObs <- length(presidents) head(presidents,
> >>> 6-npresObs)
> >>>
> >>> try(head(presidents, 1:2)) # 'try-error'
> >>>
> >>> try(head(presidents, 0)) # 'try-error'
> >>>
> >>> # matrix time series str(pres <-
> >>> cbind(n=1:length(presidents), presidents)) head(pres, 2)
> >>>
> >>> head(pres, 2-npresObs)
> >>>
> >>> head(pres, 1:2) head(pres, 2:1) head(pres, 1:
Re: [Rd] head.ts, tail.ts loses time
zoo overcomes many of the limitations of ts:
library(zoo)
as.ts(head(as.zoo(presidents)))
## Qtr1 Qtr2 Qtr3 Qtr4
## 1945 NA 87 82 75
## 1946 63 50
xts also works here.
On Sun, Jun 9, 2024 at 12:04 PM Spencer Graves
wrote:
>
> Hello, All:
>
>
> The 'head' and 'tail' functions strip the time from a 'ts' object.
> Example:
>
>
> > head(presidents)
> [1] NA 87 82 75 63 50
>
>
> > window(presidents, 1945, 1946.25)
> Qtr1 Qtr2 Qtr3 Qtr4
> 1945 NA 87 82 75
> 1946 63 50
>
>
> Below please find code for 'head.ts' and 'tail.ts' that matches
> 'window'.
>
>
> Comments?
> Spencer Graves
>
> head.ts <- function(x, n=6L, ...){
>tmx <- as.numeric(time(x))
> #
>utils:::checkHT(n, d <- dim(x))
>if(is.na(n[1]) || n[1]==0)ts(NULL)
> #
>firstn <- head(tmx, n[1])
>if(is.null(d)){
> return(window(x, firstn[1], tail(firstn, 1)))
>} else{
> if(length(n)<2){
>return(window(x, firstn[1], tail(firstn, 1)))
> } else {
>Cols <- head(1:d[2], n[2])
>xn2 <- x[, Cols[1]:tail(Cols, 1)]
>return(window(xn2, firstn[1], tail(firstn, 1)))
> }
>}
> }
>
>
> tail.ts <- function (x, n = 6L, ...)
> {
>utils:::checkHT(n, d <- dim(x))
>tmx <- as.numeric(time(x))
> #
>if(is.na(n[1]) || n[1]==0)ts(NULL)
> #
>lastn <- tail(tmx, n[1])
>if(is.null(d)){
> return(window(x, lastn[1], tail(lastn, 1)))
>} else{
> if(length(n)<2){
>return(window(x, lastn[1], tail(lastn, 1)))
> } else {
>Cols <- head(1:d[2], n[2])
>xn2 <- x[, Cols[1]:tail(Cols, 1)]
>return(window(xn2, lastn[1], tail(lastn, 1)))
> }
>}
> }
>
>
> # examples
> head(presidents)
>
> head(presidents, 2)
>
> npresObs <- length(presidents)
> head(presidents, 6-npresObs)
>
> try(head(presidents, 1:2)) # 'try-error'
>
> try(head(presidents, 0)) # 'try-error'
>
> # matrix time series
> str(pres <- cbind(n=1:length(presidents), presidents))
> head(pres, 2)
>
> head(pres, 2-npresObs)
>
> head(pres, 1:2)
> head(pres, 2:1)
> head(pres, 1:3)
>
> # examples
> tail(presidents)
>
> tail(presidents, 2)
>
> npresObs <- length(presidents)
> tail(presidents, 6-npresObs)
>
> try(tail(presidents, 1:2)) # 'try-error'
>
> try(tail(presidents, 0)) # 'try-error'
>
> # matrix time series
> str(pres <- cbind(n=1:length(presidents), presidents))
> tail(pres, 2)
>
> tail(pres, 2-npresObs)
>
> tail(pres, 1:2)
> tail(pres, 2:1)
> tail(pres, 1:3)
>
> # for unit testing:
> headPres <- head(presidents)
> pres6 <- ts(presidents[1:6], time(presidents)[1],
> frequency=frequency(presidents))
> stopifnot(all.equal(headPres, pres6))
>
> headPres2 <- head(presidents, 2)
> pres2 <- ts(presidents[1:2], time(presidents)[1],
> frequency=frequency(presidents))
> stopifnot(all.equal(headPres2, pres2))
>
> npresObs <- length(presidents)
> headPres. <- head(presidents, 6-npresObs)
> stopifnot(all.equal(headPres., pres6))
>
> headPresOops <- try(head(presidents, 1:2))
> stopifnot(class(headPresOops) == 'try-error')
>
> headPres0 <- try(head(presidents, 0))
> stopifnot(class(headPres0) == 'try-error')
>
> str(pres <- cbind(n=1:length(presidents), presidents))
> headP2 <- head(pres, 2)
>
> p2 <- ts(pres[1:2, ], time(presidents)[1],
> frequency=frequency(presidents))
> stopifnot(all.equal(headP2, p2))
>
> headP2. <- head(pres, 2-npresObs)
> stopifnot(all.equal(headP2., p2))
>
>
> #
>
>
> sessionInfo()
> R version 4.4.0 (2024-04-24)
> Platform: aarch64-apple-darwin20
> Running under: macOS Sonoma 14.5
>
> Matrix products: default
> BLAS:
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
>
> LAPACK:
> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;
> LAPACK version 3.12.0
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> time zone: America/Chicago
> tzcode source: internal
>
> attached base packages:
> [1] stats graphics grDevices utils datasets
> [6] methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.4.0 tools_4.4.0
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] capture "->"
Would it be good enough to pass it as a formula? Using your definition of foo foo(~ A -> result) ## result <- ~A foo(~ result <- A) ## ~result <- A On Fri, Mar 1, 2024 at 4:18 AM Dmitri Popavenko wrote: > > Hi everyone, > > I am aware this is a parser issue, but is there any possibility to capture > the use of the inverse assignment operator into a formula? > > Something like: > > > foo <- function(x) substitute(x) > > gives: > > > foo(A -> B) > B <- A > > I wonder if there is any possibility whatsoever to signal the use of -> > instead of <- > > Thank you, > Dmitri > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(parse()) within mutate() returning same value for all rows
Here is a solution that does not hard code 3:
library(dplyr)
library(purrr)
library(tidyr)
df %>%
separate_wider_delim(args, ",", names_sep = "") %>%
mutate(combined = exec(sprintf, .[[1]], !!!.[-1]))
## # A tibble: 3 × 5
## wordsargs1 args2 args3 combined
##
## 1 %s plus %s equals %s 1 1 2 1 plus 1 equals 2
## 2 %s plus %s equals %s 2 2 4 2 plus 2 equals 4
## 3 %s plus %s equals %s 3 3 6 3 plus 3 equals 6
On Fri, Dec 29, 2023 at 1:45 PM Gabor Grothendieck
wrote:
>
> If the question is how to accomplish this as opposed to how to use eval
> then we can do it without eval like this provided we can assume that words
> contains three %s .
>
> library(dplyr)
> library(tidyr)
> df <- tibble(words=c("%s plus %s equals
> %s"),args=c("1,1,2","2,2,4","3,3,6"))
>
> df |>
> separate_wider_delim(args, ",", names = c("a", "b", "c")) |>
> mutate(combined = sprintf(words, a, b, c))
> ## # A tibble: 3 × 5
> ## wordsa b c combined
> ##
> ## 1 %s plus %s equals %s 1 1 2 1 plus 1 equals 2
> ## 2 %s plus %s equals %s 2 2 4 2 plus 2 equals 4
> ## 3 %s plus %s equals %s 3 3 6 3 plus 3 equals 6
>
> On Fri, Dec 29, 2023 at 9:14 AM Mateo Obregón wrote:
> >
> > Hi all-
> >
> > Looking through stackoverflow for R string combining examples, I found the
> > following from 3 years ago:
> >
> > <https://stackoverflow.com/questions/63881854/how-to-format-strings-using-values-from-other-column-in-r>
> >
> > The top answer suggests to use eval(parse(sprintf())). I tried the
> > suggestion
> > and it did not return the expected combines strings. I thought that this
> > might
> > be an issue with some leftover values being reused, so I explicitly eval()
> > with a new.env():
> >
> > > library(dplyr)
> > > df <- tibble(words=c("%s plus %s equals %s"),
> > args=c("1,1,2","2,2,4","3,3,6"))
> > > df |> mutate(combined = eval(parse(text=sprintf("sprintf('%s', %s)",
> > > words,
> > args)), envir=new.env()))
> >
> > # A tibble: 3 × 3
> > wordsargs combined
> >
> > 1 %s plus %s equals %s 1,1,2 3 plus 3 equals 6
> > 2 %s plus %s equals %s 2,2,4 3 plus 3 equals 6
> > 3 %s plus %s equals %s 3,3,6 3 plus 3 equals 6
> >
> > The `combined` is not what I was expecting, as the same last eval() is
> > returned for all three rows.
> >
> > Am I missing something? What has changed in the past three years?
> >
> > Mateo.
> > --
> > Mateo Obregón
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eval(parse()) within mutate() returning same value for all rows
If the question is how to accomplish this as opposed to how to use eval
then we can do it without eval like this provided we can assume that words
contains three %s .
library(dplyr)
library(tidyr)
df <- tibble(words=c("%s plus %s equals %s"),args=c("1,1,2","2,2,4","3,3,6"))
df |>
separate_wider_delim(args, ",", names = c("a", "b", "c")) |>
mutate(combined = sprintf(words, a, b, c))
## # A tibble: 3 × 5
## wordsa b c combined
##
## 1 %s plus %s equals %s 1 1 2 1 plus 1 equals 2
## 2 %s plus %s equals %s 2 2 4 2 plus 2 equals 4
## 3 %s plus %s equals %s 3 3 6 3 plus 3 equals 6
On Fri, Dec 29, 2023 at 9:14 AM Mateo Obregón wrote:
>
> Hi all-
>
> Looking through stackoverflow for R string combining examples, I found the
> following from 3 years ago:
>
>
>
> The top answer suggests to use eval(parse(sprintf())). I tried the suggestion
> and it did not return the expected combines strings. I thought that this might
> be an issue with some leftover values being reused, so I explicitly eval()
> with a new.env():
>
> > library(dplyr)
> > df <- tibble(words=c("%s plus %s equals %s"),
> args=c("1,1,2","2,2,4","3,3,6"))
> > df |> mutate(combined = eval(parse(text=sprintf("sprintf('%s', %s)", words,
> args)), envir=new.env()))
>
> # A tibble: 3 × 3
> wordsargs combined
>
> 1 %s plus %s equals %s 1,1,2 3 plus 3 equals 6
> 2 %s plus %s equals %s 2,2,4 3 plus 3 equals 6
> 3 %s plus %s equals %s 3,3,6 3 plus 3 equals 6
>
> The `combined` is not what I was expecting, as the same last eval() is
> returned for all three rows.
>
> Am I missing something? What has changed in the past three years?
>
> Mateo.
> --
> Mateo Obregón
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data.frame weirdness
Seems like a leaky abstraction. If both representations are supposed
to be outwardly the same to the user then they should act the same and
if not then identical should not be TRUE.
On Tue, Nov 14, 2023 at 9:56 AM Deepayan Sarkar
wrote:
>
> On Tue, 14 Nov 2023 at 09:41, Gabor Grothendieck
> wrote:
> >
> > Also why should that difference result in different behavior?
>
> That's justifiable, I think; consider:
>
> > d1 = data.frame(a = 1:4)
> > d2 = d3 = data.frame(b = 1:2)
> > row.names(d3) = c("a", "b")
> > data.frame(d1, d2)
> a b
> 1 1 1
> 2 2 2
> 3 3 1
> 4 4 2
> > data.frame(d1, d2)
> a b
> 1 1 1
> 2 2 2
> 3 3 1
> 4 4 2
> > data.frame(d1, d3)
> a b
> 1 1 1
> 2 2 2
> 3 3 1
> 4 4 2
> Warning message:
> In data.frame(d1, d3) :
> row names were found from a short variable and have been discarded
> > data.frame(d2, d3)
> b b.1
> a 1 1
> b 2 2
>
>
> > On Tue, Nov 14, 2023 at 9:38 AM Gabor Grothendieck
> > wrote:
> > >
> > > In that case identical should be FALSE but it is TRUE
>
> Yes, or at least both cases should warn (or not warn). Certainly not
> ideal, but one of the inevitable side effects of having two different
> ways of storing row names that R tries to pretend should be
> exchangeable, but are not (and some code not having caught up).
>
> Part of the problem, I think, is that it's not clear what the ideal
> behaviour should be in such cases (to warn or not to warn).
>
> Best,
> -Deepayan
>
> > > identical(a1, a2)
> > > ## [1] TRUE
> > >
> > >
> > > On Tue, Nov 14, 2023 at 8:58 AM Deepayan Sarkar
> > > wrote:
> > > >
> > > > They differ in whether the row names are "automatic":
> > > >
> > > > > .row_names_info(a1)
> > > > [1] -3
> > > > > .row_names_info(a2)
> > > > [1] 3
> > > >
> > > > Best,
> > > > -Deepayan
> > > >
> > > > On Tue, 14 Nov 2023 at 08:23, Gabor Grothendieck
> > > > wrote:
> > > > >
> > > > > What is going on here? In the lines ending in the inputs and
> > > > > outputs
> > > > > are identical yet one gives a warning and the other does not.
> > > > >
> > > > > a1 <- `rownames<-`(anscombe[1:3, ], NULL)
> > > > > a2 <- anscombe[1:3, ]
> > > > >
> > > > > ix <- 5:8
> > > > >
> > > > > # input arguments to are identical in both cases
> > > > >
> > > > > identical(stack(a1[ix]), stack(a2[ix]))
> > > > > ## [1] TRUE
> > > > > identical(a1[-ix], a2[-ix])
> > > > > ## [1] TRUE
> > > > >
> > > > >
> > > > > res1 <- data.frame(stack(a1[ix]), a1[-ix])
> > > > > res2 <- data.frame(stack(a2[ix]), a2[-ix])
> > > > > ## Warning message:
> > > > > ## In data.frame(stack(a2[ix]), a2[-ix]) :
> > > > > ## row names were found from a short variable and have been
> > > > > discarded
> > > > >
> > > > > # results are identical
> > > > > identical(res1, res2)
> > > > > ## [1] TRUE
> > > > >
> > > > >
> > > > > --
> > > > > Statistics & Software Consulting
> > > > > GKX Group, GKX Associates Inc.
> > > > > tel: 1-877-GKX-GROUP
> > > > > email: ggrothendieck at gmail.com
> > > > >
> > > > > __
> > > > > R-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> > >
> > >
> > > --
> > > Statistics & Software Consulting
> > > GKX Group, GKX Associates Inc.
> > > tel: 1-877-GKX-GROUP
> > > email: ggrothendieck at gmail.com
> >
> >
> >
> > --
> > Statistics & Software Consulting
> > GKX Group, GKX Associates Inc.
> > tel: 1-877-GKX-GROUP
> > email: ggrothendieck at gmail.com
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data.frame weirdness
Also why should that difference result in different behavior? On Tue, Nov 14, 2023 at 9:38 AM Gabor Grothendieck wrote: > > In that case identical should be FALSE but it is TRUE > > identical(a1, a2) > ## [1] TRUE > > > On Tue, Nov 14, 2023 at 8:58 AM Deepayan Sarkar > wrote: > > > > They differ in whether the row names are "automatic": > > > > > .row_names_info(a1) > > [1] -3 > > > .row_names_info(a2) > > [1] 3 > > > > Best, > > -Deepayan > > > > On Tue, 14 Nov 2023 at 08:23, Gabor Grothendieck > > wrote: > > > > > > What is going on here? In the lines ending in the inputs and outputs > > > are identical yet one gives a warning and the other does not. > > > > > > a1 <- `rownames<-`(anscombe[1:3, ], NULL) > > > a2 <- anscombe[1:3, ] > > > > > > ix <- 5:8 > > > > > > # input arguments to are identical in both cases > > > > > > identical(stack(a1[ix]), stack(a2[ix])) > > > ## [1] TRUE > > > identical(a1[-ix], a2[-ix]) > > > ## [1] TRUE > > > > > > > > > res1 <- data.frame(stack(a1[ix]), a1[-ix]) > > > res2 <- data.frame(stack(a2[ix]), a2[-ix]) > > > ## Warning message: > > > ## In data.frame(stack(a2[ix]), a2[-ix]) : > > > ## row names were found from a short variable and have been discarded > > > > > > # results are identical > > > identical(res1, res2) > > > ## [1] TRUE > > > > > > > > > -- > > > Statistics & Software Consulting > > > GKX Group, GKX Associates Inc. > > > tel: 1-877-GKX-GROUP > > > email: ggrothendieck at gmail.com > > > > > > __ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data.frame weirdness
In that case identical should be FALSE but it is TRUE identical(a1, a2) ## [1] TRUE On Tue, Nov 14, 2023 at 8:58 AM Deepayan Sarkar wrote: > > They differ in whether the row names are "automatic": > > > .row_names_info(a1) > [1] -3 > > .row_names_info(a2) > [1] 3 > > Best, > -Deepayan > > On Tue, 14 Nov 2023 at 08:23, Gabor Grothendieck > wrote: > > > > What is going on here? In the lines ending in the inputs and outputs > > are identical yet one gives a warning and the other does not. > > > > a1 <- `rownames<-`(anscombe[1:3, ], NULL) > > a2 <- anscombe[1:3, ] > > > > ix <- 5:8 > > > > # input arguments to are identical in both cases > > > > identical(stack(a1[ix]), stack(a2[ix])) > > ## [1] TRUE > > identical(a1[-ix], a2[-ix]) > > ## [1] TRUE > > > > > > res1 <- data.frame(stack(a1[ix]), a1[-ix]) > > res2 <- data.frame(stack(a2[ix]), a2[-ix]) > > ## Warning message: > > ## In data.frame(stack(a2[ix]), a2[-ix]) : > > ## row names were found from a short variable and have been discarded > > > > # results are identical > > identical(res1, res2) > > ## [1] TRUE > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] data.frame weirdness
What is going on here? In the lines ending in the inputs and outputs are identical yet one gives a warning and the other does not. a1 <- `rownames<-`(anscombe[1:3, ], NULL) a2 <- anscombe[1:3, ] ix <- 5:8 # input arguments to are identical in both cases identical(stack(a1[ix]), stack(a2[ix])) ## [1] TRUE identical(a1[-ix], a2[-ix]) ## [1] TRUE res1 <- data.frame(stack(a1[ix]), a1[-ix]) res2 <- data.frame(stack(a2[ix]), a2[-ix]) ## Warning message: ## In data.frame(stack(a2[ix]), a2[-ix]) : ## row names were found from a short variable and have been discarded # results are identical identical(res1, res2) ## [1] TRUE -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple Assignment built into the R Interpreter?
The gsubfn package can do that.
library(gsubfn)
# swap a and b without explicitly creating a temporary
a <- 1; b <- 2
list[a,b] <- list(b,a)
# get eigenvectors and eigenvalues
list[eval, evec] <- eigen(cbind(1,1:3,3:1))
# get today's month, day, year
require(chron)
list[Month, Day, Year] <- month.day.year(unclass(Sys.Date()))
# get first two components of linear model ignoring rest
list[Coef, Resid] <- lm(rnorm(10) ~ seq(10))
# assign Green and Blue (but not Red) components
list[,Green,Blue] <- col2rgb("aquamarine")
# Assign QR and QRaux but not other components
list[QR,,QRaux] <- qr(c(1,1:3,3:1))
On Sat, Mar 11, 2023 at 7:47 AM Sebastian Martin Krantz
wrote:
>
> Dear R Core,
>
> working on my dynamic factor modelling package, which requires several
> subroutines to create and update several system matrices, I come back to
> the issue of being annoyed by R not supporting multiple assignment out of
> the box like Matlab, Python and julia. e.g. something like
>
> A, C, Q, R = init_matrices(X, Y, Z)
>
> would be a great addition to the language. I know there are several
> workarounds such as the %<-% operator in the zeallot package or my own %=%
> operator in collapse, but these don't work well for package development as
> R CMD Check warns about missing global bindings for the created variables,
> e.g. I would have to use
>
> A <- C <- Q <- R <- NULL
> .c(A, C, Q, R) %=% init_matrices(X, Y, Z)
>
> in a package, which is simply annoying. Of course the standard way of
>
> init <- init_matrices(X, Y, Z)
> A <- init$A; C <- init$C; Q <- init$Q; R <- init$R
> rm(init)
>
> is also super cumbersome compared to Python or Julia. Another reason is of
> course performance, even my %=% operator written in C has a non-negligible
> performance cost for very tight loops, compared to a solution at the
> interpretor level or in a primitive function such as `=`.
>
> So my conclusion at this point is that it is just significantly easier to
> implement such codes in Julia, in addition to the greater performance it
> offers. There are obvious reasons why I am still coding in R and C, thanks
> to the robust API and great ecosystem of packages, but adding this could be
> a presumably low-hanging fruit to make my life a bit easier. Several issues
> for this have been filed on Stackoverflow, the most popular one (
> https://stackoverflow.com/questions/7519790/assign-multiple-new-variables-on-lhs-in-a-single-line)
> has been viewed 77 thousand times.
>
> But maybe this has already been discussed here and already decided against.
> In that case, a way to browse R-devel archives to find out would be nice.
>
> Best regards,
>
> Sebastian
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Augment base::replace(x, list, value) to allow list= to be a predicate?
This is getting way off topic. I wasn't suggesting that gsubfn, which
does a lot more than this simple
example, as the implementation.
I was pointing out that the replace function idea can be extended to
sub and gsub and showing what
it would do.
On Tue, Mar 7, 2023 at 9:41 PM Steve Martin wrote:
>
> That's an interesting example, as it's conceptually similar to what
> Pavel is proposing, but structurally different. gsubfn() is more
> complicated than a simple switch in the body of the function, and
> wouldn't work well as an anonymous function.
>
> Multiple dispatch can nicely encompass both of these cases. For replace(),
>
> library(S7)
>
> replace <- new_generic("replace", c("x", "list"), function(x, list,
> values, ...) {
> S7_dispatch()
> })
>
> method(replace, list(class_any, class_any)) <- base::replace
>
> method(replace, list(class_any, class_function)) <- function(x, list,
> values, ...) {
> replace(x, list(x, ...), values)
> }
>
> x <- c(1 ,2, NA, 3)
> replace(x, is.na(x), 0)
> [1] 1 2 0 3
>
> replace(x, is.na, 0)
> [1] 1 2 0 3
>
> And for gsub(),
>
> gsub <- new_generic("gsub", c("pattern", "replacement"),
> function(pattern, replacement, x, ...) {
> S7_dispatch()
> })
>
> method(gsub, list(class_character, class_character)) <- base::gsub
>
> # My quick-and-dirty implementation as an example
> method(gsub, list(class_character, class_function)) <-
> function(pattern, replacement, x) {
> m <- regexpr(pattern, x)
> res <- replacement(regmatches(x, m))
> mapply(gsub, pattern, as.character(res), x, USE.NAMES = FALSE)
> }
>
> gsub("^..", toupper, c("abc", "xyz"))
> [1] "ABc" "XYz"
>
> But this isn't a simple change to replace() anymore, and I may just be
> spending too much time tinkering with Julia.
>
> Steve
>
> On Tue, 7 Mar 2023 at 07:34, Gabor Grothendieck
> wrote:
> >
> > This could be extended to sub and gsub as well which gsubfn in the
> > gusbfn package already does:
> >
> > library(gsubfn)
> > gsubfn("^..", toupper, c("abc", "xyz"))
> > ## [1] "ABc" "XYz"
> >
> > On Fri, Mar 3, 2023 at 7:22 PM Pavel Krivitsky
> > wrote:
> > >
> > > Dear All,
> > >
> > > Currently, list= in base::replace(x, list, value) has to be an index
> > > vector. For me, at least, the most common use case is for list= to be
> > > some simple property of elements of x, e.g.,
> > >
> > > x <- c(1,2,NA,3)
> > > replace(x, is.na(x), 0)
> > >
> > > Particularly when using R pipes, which don't allow multiple
> > > substitutions, it would simplify many of such cases if list= could be a
> > > function that returns an index, e.g.,
> > >
> > > replace <- function (x, list, values, ...) {
> > > # Here, list() refers to the argument, not the built-in.
> > > if(is.function(list)) list <- list(x, ...)
> > > x[list] <- values
> > > x
> > > }
> > >
> > > Then, the following is possible:
> > >
> > > c(1,2,NA,3) |> replace(is.na, 0)
> > >
> > > Any thoughts?
> > > Pavel
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
> > --
> > Statistics & Software Consulting
> > GKX Group, GKX Associates Inc.
> > tel: 1-877-GKX-GROUP
> > email: ggrothendieck at gmail.com
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Augment base::replace(x, list, value) to allow list= to be a predicate?
This could be extended to sub and gsub as well which gsubfn in the
gusbfn package already does:
library(gsubfn)
gsubfn("^..", toupper, c("abc", "xyz"))
## [1] "ABc" "XYz"
On Fri, Mar 3, 2023 at 7:22 PM Pavel Krivitsky wrote:
>
> Dear All,
>
> Currently, list= in base::replace(x, list, value) has to be an index
> vector. For me, at least, the most common use case is for list= to be
> some simple property of elements of x, e.g.,
>
> x <- c(1,2,NA,3)
> replace(x, is.na(x), 0)
>
> Particularly when using R pipes, which don't allow multiple
> substitutions, it would simplify many of such cases if list= could be a
> function that returns an index, e.g.,
>
> replace <- function (x, list, values, ...) {
> # Here, list() refers to the argument, not the built-in.
> if(is.function(list)) list <- list(x, ...)
> x[list] <- values
> x
> }
>
> Then, the following is possible:
>
> c(1,2,NA,3) |> replace(is.na, 0)
>
> Any thoughts?
> Pavel
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] summary.lm fails for difftime objects
lm works with difftime objects but then if you try to get the summary it fails with an error: fit <- lm(as.difftime(Time, units = "mins") ~ demand, BOD) summary(fit) ## Error in Ops.difftime((f - mean(f)), 2) : ## '^' not defined for "difftime" objects A number of other lm methods also fail, e.g. plot(fit), but others work, e.g. coef(fit), resid(fit) -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package.skeleton hello* files
Is there some way to avoid the automatic generation of hello* files in package.skeleton? I found that the following does it on Windows but then it does not create an R directory which I still want and also it gives warnings which I don't want. package.skeleton(code_files = "NUL") -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anova and intercept
Good idea. On Mon, Dec 26, 2022 at 12:59 PM peter dalgaard wrote: > > My usual advice on getting nonstandard F tests out of anova() is to fit the > models explicitly and compare. > > So how about this? > > fit1 <- lm(diff(extra,10) ~ 1, sleep) > fit0 <- update(fit1, ~ -1) > anova(fit0, fit1) > > -pd > > > On 26 Dec 2022, at 13:49 , Gabor Grothendieck > > wrote: > > > > Suppose we want to perform a paired test using the sleep data frame > > with anova in R. Then this works and gives the same p value as > > t.test(extra ~ group, sleep, paired = TRUE, var.equal = TRUE) > > > > ones <- rep(1, 10) > > anova(lm(diff(extra, 10) ~ ones + 0, sleep) > > > > This gives output but does not give an F test at all. > > > > ones <- rep(1, 10) > > anova(lm(diff(extra, 10) ~ 1, sleep) > > > > Maybe there should be some way to force an F test to be produced for > > the intercept in anova for consistency with t.test so that the second > > code can be used. > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] anova and intercept
Suppose we want to perform a paired test using the sleep data frame with anova in R. Then this works and gives the same p value as t.test(extra ~ group, sleep, paired = TRUE, var.equal = TRUE) ones <- rep(1, 10) anova(lm(diff(extra, 10) ~ ones + 0, sleep) This gives output but does not give an F test at all. ones <- rep(1, 10) anova(lm(diff(extra, 10) ~ 1, sleep) Maybe there should be some way to force an F test to be produced for the intercept in anova for consistency with t.test so that the second code can be used. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pipes and setNames
When trying to transform names in a pipeline one can do the following
where for this example we are making names upper case.
BOD |> (\(x) setNames(x, toupper(names(x()
but that seems a bit ugly and verbose.
1. One possibility is to enhance setNames to allow a function as a
second argument. In that case one could write:
BOD |> setNames(toupper)
2. One can already do the following with the existing `with` but is
quite verbose:
BOD |> list() |> setNames(".") |> with(setNames(., toupper(names(.
but could be made simpler with a utility function.
This utility function is not as good for setNames but would still
result in shorter code than the anonymous function in the example at
the top of this email and is more general so it would also apply in
other situations too. Here R would define a function with. (note dot
at end) which would be defined and used as follows.
with. <- function(data, expr, ...) {
eval(substitute(expr), list(. = data), enclos = parent.frame())
}
BOD |> with.(setNames(., toupper(names(.
with. is not as efficient as straight pipes but in many cases such as
this it does not really matter and one just wants to get it done
without the parenthesis laden anonymous function.
Having both of these two would be nice to make it easier to use R pipes.
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] aggregate.formula and pipes
Because aggregate.formula has a formula argument but the generic has an x argument neither of these work: mtcars |> aggregate(x = mpg ~ cyl, FUN = mean) mtcars |> aggregate(formula = mpg ~ cyl, FUN = mean) This does work: mtcars |> stats:::aggregate.formula(formula = mpg ~ cyl, FUN = mean) Suggest that aggregate.formula be exported. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] assignment
In a recent SO post this came up (changed example to simplify it
here). It seems that `test` still has the value sin.
test <- sin
environment(test)$test <- cos
test(0)
## [1] 0
It appears to be related to the double use of `test` in `$<-` since if
we break it up it works as expected:
test <- sin
e <- environment(test)
e$test <- cos
test(0)
## [1] 1
`assign` also works:
test <- sin
assign("test", cos, environment(test))
test(0)
## [1] 1
Can anyone shed some light on this?
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order of operations
It could be that the two sides of * are run in parallel in the future and maybe not having a guarantee would simplify implementation? On Fri, Aug 27, 2021 at 12:35 PM Avi Gross via R-devel wrote: > > Does anyone have a case where this construct has a valid use? > > Didn't Python add a := operator recently that might be intended more for > such uses as compared to using the standard assignment operators? I wonder > if that has explicit guarantees of what happens in such cases, but that is > outside what this forum cares about. Just for the heck of it, I tried the > example there: > > >>> (x := 1) * (x := 2) > 2 > >>> x > 2 > > Back to R, ... > > The constructs can get arbitrarily complex as in: > > (x <- (x <- 0) + 1) * (x <- (x <-2) + 1) > > My impression is that when evaluation is left to right and also innermost > parentheses before outer ones, then something like the above goes in stages. > The first of two parenthetical expressions is evaluated first. > > (x <- (x <- 0) + 1) > > The inner parenthesis set x to zero then the outer one increments x to 1. > The full sub-expression evaluates to 1 and that value is set aside for a > later multiplication. > > But then the second parenthesis evaluates similarly, from inside out: > > (x <- (x <-2) + 1) > > It clearly resets x to 2 then increments it by 1 to 3 and returns a value of > 3. That is multiplied by the first sub-expression to result in 3. > > So for simple addition, even though it is commutative, is there any reason > any compiler or interpreter should not follow rules like the above? > Obviously with something like matrices, some operations are not abelian and > require more strict interpretation in the right order. > > And note the expressions like the above can run into more complex quandaries > such as when you have a conditional with OR or AND parts that may be > short-circuited and in some cases, a variable you expected to be set, may > remain unset or ... > > This reminds me a bit of languages that allow pre/post increment/decrement > operators like ++ and -- and questions about what order things happen. > Ideally, anything in which a deterministic order is not guaranteed should be > flagged by the language at compile time (or when interpreted) and refuse to > go on. > > All I can say with computer languages and adding ever more features, > with greater power comes greater responsibility and often greater > confusion. > > > -Original Message- > From: R-devel On Behalf Of Gabor > Grothendieck > Sent: Friday, August 27, 2021 11:32 AM > To: Thierry Onkelinx > Cc: r-devel@r-project.org > Subject: Re: [Rd] order of operations > > I agree and personally never do this but I would still like to know if it is > guaranteed behavior or not. > > On Fri, Aug 27, 2021 at 11:28 AM Thierry Onkelinx > wrote: > > > IMHO this is just bad practice. Whether the result is guaranteed or > > not, doesn't matter. > > > > ir. Thierry Onkelinx > > Statisticus / Statistician > > > > Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN > > BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie > > & Kwaliteitszorg / Team Biometrics & Quality Assurance > > thierry.onkel...@inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be > > > > > > // > > / To call in the statistician after the experiment > > is done may be no more than asking him to perform a post-mortem > > examination: he may be able to say what the experiment died of. ~ Sir > > Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger > > Brinner The combination of some data and an aching desire for an > > answer does not ensure that a reasonable answer can be extracted from > > a given body of data. > > ~ John Tukey > > > > // > > / > > > > <https://www.inbo.be> > > > > > > Op vr 27 aug. 2021 om 17:18 schreef Gabor Grothendieck < > > ggrothendi...@gmail.com>: > > > >> Are there any guarantees of whether x will equal 1 or 2 after this is > run? > >> > >> (x <- 1) * (x <- 2) > >> ## [1] 2 > >> x > >> ## [1] 2 > >> > >> -- > >> Statistics & Software Consulting > >> GKX Group, GKX Associates Inc. > >> tel: 1-877-GKX-GROUP > >> email: ggrothendieck at gmail.com > >
Re: [Rd] order of operations
I agree and personally never do this but I would still like to know if it is guaranteed behavior or not. On Fri, Aug 27, 2021 at 11:28 AM Thierry Onkelinx wrote: > IMHO this is just bad practice. Whether the result is guaranteed or not, > doesn't matter. > > ir. Thierry Onkelinx > Statisticus / Statistician > > Vlaamse Overheid / Government of Flanders > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND > FOREST > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance > thierry.onkel...@inbo.be > Havenlaan 88 bus 73, 1000 Brussel > www.inbo.be > > > /// > To call in the statistician after the experiment is done may be no more > than asking him to perform a post-mortem examination: he may be able to say > what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does not > ensure that a reasonable answer can be extracted from a given body of data. > ~ John Tukey > > /// > > <https://www.inbo.be> > > > Op vr 27 aug. 2021 om 17:18 schreef Gabor Grothendieck < > ggrothendi...@gmail.com>: > >> Are there any guarantees of whether x will equal 1 or 2 after this is run? >> >> (x <- 1) * (x <- 2) >> ## [1] 2 >> x >> ## [1] 2 >> >> -- >> Statistics & Software Consulting >> GKX Group, GKX Associates Inc. >> tel: 1-877-GKX-GROUP >> email: ggrothendieck at gmail.com >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] order of operations
Are there any guarantees of whether x will equal 1 or 2 after this is run? (x <- 1) * (x <- 2) ## [1] 2 x ## [1] 2 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with pipes, textConnection and read.dcf
This gives an error bit if the first gsub line is commented out then there is no
error even though it is equivalent code.
L <- c("Variable:id", "Length:112630 ")
L |>
gsub(pattern = " ", replacement = "") |>
gsub(pattern = " ", replacement = "") |>
textConnection() |>
read.dcf()
## Error in textConnection(gsub(gsub(L, pattern = " ", replacement = ""), :
## argument 'object' must deparse to a single character string
That is this works:
L |>
# gsub(pattern = " ", replacement = "") |>
gsub(pattern = " ", replacement = "") |>
textConnection() |>
read.dcf()
## Variable Length
## [1,] "id" "112630"
R.version.string
## [1] "R version 4.1.0 RC (2021-05-16 r80303)"
win.version()
## [1] "Windows 10 x64 (build 19042)"
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Feature request: Change default library path on Windows
At the very least it would be nice if there were a function that displays all the locations/paths currently being used in R. On Sat, Jul 24, 2021 at 6:15 PM Steve Haroz wrote: > > Hello, > > I'd like to propose moving the default library install location on Windows > from: > %USERPROFILE%/Documents/R > to some other location such as: > %USERPROFILE%/R > > For many users the Documents folder is backed up or synchronized. > Installing libraries thrashes Documents, and it causes synchronization > issues with Dropbox (I confirm this one), OneDrive, and users with > Network IT policies. > > The vast majority of R users won't touch that folder and don't need it > backed up. And, its contents are not really "documents". > > There are many blog posts and websites with people complaining about > it or offering workarounds that involve hand editing setting and > environment files, which reduces R's usability and accessibility. > * > https://community.rstudio.com/t/help-regarding-package-installation-renviron-rprofile-r-libs-r-libs-site-and-r-libs-user-oh-my/13888/5 > * https://accelebrate.com/library/how-to-articles/r-rstudio-library > * > https://community.rstudio.com/t/r-studio-library-installation-directory/30725/2 > * https://twitter.com/sharoz/status/1418712098444546057 > * https://twitter.com/JoeHilgard/status/1419025358070878210 > > This change should not interfere with any project environment managers > like renv. It should just change the global default for Windows R > users. > Also, I believe that on Mac it is not in Documents, but it's in the > equivalent of %USERPROFILE%/R. > > Thanks, > Steve Haroz > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 weirdness
The fact that zoo:: in one part of the code has a side effect in another seems not to be in the spirit of functional programming or modularity. On Thu, Jun 24, 2021 at 6:51 PM Simon Urbanek wrote: > > Gabor, > > just by using zoo::read.zoo() you *do* load the namespace: > > > args(zoo::read.zoo) > function (file, format = "", tz = "", FUN = NULL, regular = FALSE, > index.column = 1, drop = TRUE, FUN2 = NULL, split = NULL, > aggregate = FALSE, ..., text, read = read.table) > NULL > > sessionInfo() > R Under development (unstable) (2021-06-23 r80548) > Platform: x86_64-apple-darwin19.6.0 (64-bit) > Running under: macOS Catalina 10.15.7 > > Matrix products: default > BLAS: /Volumes/Builds/R/build/lib/libRblas.dylib > LAPACK: /Volumes/Builds/R/build/lib/libRlapack.dylib > > locale: > [1] en_NZ.UTF-8/en_NZ.UTF-8/en_NZ.UTF-8/C/en_NZ.UTF-8/en_NZ.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] zoo_1.8-9 compiler_4.2.0 grid_4.2.0 lattice_0.20-44 > > which includes S3 method dispatch tables: > > > methods(as.ts) > [1] as.ts.default* as.ts.zoo* as.ts.zooreg* > see '?methods' for accessing help and source code > > so the behavior is as expected. > > Cheers, > Simon > > > > On 25/06/2021, at 9:56 AM, Gabor Grothendieck > > wrote: > > > > If we start up a vanilla session of R with no packages loaded and > > type the single line of code below as the first line entered then > > we get the output shown below. The NA in the output and the length > > of 7 indicate that as.ts dispatched as.ts.zoo since as.ts.default > > would have resulted in a length of 6 with no NA's. It should not have > > known about as.ts.zoo since we never explicitly loaded the zoo > > package using library or require. > > zoo:: was only used to refer to read.zoo. This seems to be a bug in > > the way R is currently working. > > > > as.ts(zoo::read.zoo(BOD)) > > ## Time Series: > > ## Start = 1 > > ## End = 7 > > ## Frequency = 1 > > ## [1] 8.3 10.3 19.0 16.0 15.6 NA 19.8 > > > > R.version.string > > ## [1] "R version 4.1.0 RC (2021-05-16 r80303)" > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S3 weirdness
If we start up a vanilla session of R with no packages loaded and type the single line of code below as the first line entered then we get the output shown below. The NA in the output and the length of 7 indicate that as.ts dispatched as.ts.zoo since as.ts.default would have resulted in a length of 6 with no NA's. It should not have known about as.ts.zoo since we never explicitly loaded the zoo package using library or require. zoo:: was only used to refer to read.zoo. This seems to be a bug in the way R is currently working. as.ts(zoo::read.zoo(BOD)) ## Time Series: ## Start = 1 ## End = 7 ## Frequency = 1 ## [1] 8.3 10.3 19.0 16.0 15.6 NA 19.8 R.version.string ## [1] "R version 4.1.0 RC (2021-05-16 r80303)" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Additional an example for the forward pipe operator's documentation
These also work in this particular case although not in general and the Call: line in the output differs: mtcars |> subset(cyl == 4) |> with(lm(mpg ~ disp)) mtcars |> with(lm(mpg ~ disp, subset = cyl == 4)) On Sat, Jun 19, 2021 at 7:23 AM Erez Shomron wrote: > > Hello, > > > While playing around with the new forward pipe operator I've noticed > there's a possibly overlooked usage for the operator, which would be > very beneficial to document. > > Whenever you want the LHS to be passed to an argument other than the > first, the documented example demonstrates how to do that with an > anonymous function. > > > However the syntax is less than ideal (aesthetically): > > > mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))() > > > Fortunately there's a better, undocumented option using named arguments: > > > mtcars |> subset(cyl == 4) |> lm(formula = mpg ~ disp) > > > The reason this works, is because of how R matches arguments. As the > language definition states, first named arguments are matched, then > partial matching, and only afterwards positional arguments are matched. > > > I think people that are frustrated with former syntax would be happy to > know the latter option exists. > > > That's just my opinion. > > > Thank you for reading, > > Erez > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reshape documentation
One thing about varying is that reshape ignores the names on the
varying list and makes you
specify them all over again even though it could know what they are.
Note that we had to
specify that names(varying) is the v.names.
DF <- structure(list(A1 = 10L, A2 = 5L, B1 = 11L, B2 = 5L, C1 = 21L,
C2 = 10L), class = "data.frame", row.names = c(NA, -1L))
let <- gsub("\\d", "", names(DF))
num <- gsub("\\D", "", names(DF))
varying <- split(names(DF), num)
reshape(DF, dir = "long", varying = varying, v.names = names(varying),
times = unique(let), timevar = "let")[-4]
On Sun, Apr 11, 2021 at 6:01 AM Deepayan Sarkar
wrote:
>
> On Wed, Mar 17, 2021 at 7:55 PM Michael Dewey wrote:
> >
> > Comments in line
> >
> > On 13/03/2021 09:50, SOEIRO Thomas wrote:
> > > Dear list,
> > >
> > > I have some questions/suggestions about reshape.
> > >
> > > 1) I think a good amount of the popularity of base::reshape alternative
> > > is due to the complexity of reshape documentation. It is quite hard (at
> > > least it is for me) to figure out what argument is needed for
> > > respectively "long to wide" and "wide to long", because reshapeWide and
> > > reshapeLong are documented together.
> > > - Do you agree with this?
> > > - Would you consider a proposal to modify the documentation?
> > > - If yes, what approach do you suggest? e.g. split in two pages?
> >
> > The current documentation is much clearer than it was when I first
> > started using R but we should always strive for more.
> >
> > I would suggest leaving the documentation in one place but it might be
> > helpful to add which direction is relevant for each parameter by placing
> > (to wide) or (to long) as appropriate. I think having completely
> > separate lists is not needed
>
> I have just checked in some updates to the documentation (in R-devel)
> which hopefully makes usage clearer. Any further suggestions are
> welcome. We are planning to add a short vignette as well, hopefully in
> time for R 4.1.0.
>
> > > 2) I do not think the documentation indicates that we can use varying
> > > argument to rename variables in reshapeWide.
> > > - Is this worth documenting?
> > > - Is the construct list(c()) really needed?
> >
> > Yes, because you may have more than one set of variables which need to
> > correspond to a single variable in long format. So in your example if
> > you also had 11 variables for the temperature as well as the
> > concentration each would need specifying as a separate vector in the list.
>
> That's a valid point, but on the other hand, direction="long" already
> supports specifying 'varying' as a vector, and it does simplify the
> single variable case. So we decided to be consistent and allow it for
> direction="wide" too, hopefully with loud enough warnings in the
> documentation about using the feature carelessly.
>
> Best,
> -Deepayan
>
> > Michael
> >
> > >
> > > reshape(Indometh,
> > > v.names = "conc",
> > > idvar = "Subject",
> > > timevar = "time",
> > > direction = "wide",
> > > varying = list(c("conc_0.25hr",
> > > "conc_0.5hr",
> > > "conc.0.75hr",
> > > "conc_1hr",
> > > "conc_1.25hr",
> > > "conc_2hr",
> > > "conc_3hr",
> > > "conc_4hr",
> > > "conc_5hr",
> > > "conc_6hr",
> > > "conc_8hr")))
> > >
> > > Thanks,
> > >
> > > Thomas
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > --
> > Michael
> > http://www.dewey.myzen.co.uk/home.html
> >
> > __
> > 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
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] replicate evaluates its second argument in wrong environment
Currently replicate used within sapply within a function can fail because it gets the environment for its second argument, which is currently hard coded to be the parent frame, wrong. See this link for a full example of how it goes wrong and how it could be made to work if it were possible to pass an envir argument to it. https://stackoverflow.com/questions/66184446/sapplya-replicate-b-expression-no-longer-works-inside-a-function/66185079#66185079 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] brief update on the pipe operator in R-devel
These are documented but still seem like serious deficiencies:
> f <- function(x, y) x + 10*y
> 3 |> x => f(x, x)
Error in f(x, x) : pipe placeholder may only appear once
> 3 |> x => f(1+x, 1)
Error in f(1 + x, 1) :
pipe placeholder must only appear as a top-level argument in the RHS call
Also note:
?"=>"
No documentation for ‘=>’ in specified packages and libraries:
you could try ‘??=>’
On Tue, Dec 22, 2020 at 5:28 PM wrote:
>
> It turns out that allowing a bare function expression on the
> right-hand side (RHS) of a pipe creates opportunities for confusion
> and mistakes that are too risky. So we will be dropping support for
> this from the pipe operator.
>
> The case of a RHS call that wants to receive the LHS result in an
> argument other than the first can be handled with just implicit first
> argument passing along the lines of
>
> mtcars |> subset(cyl == 4) |> (\(d) lm(mpg ~ disp, data = d))()
>
> It was hoped that allowing a bare function expression would make this
> more convenient, but it has issues as outlined below. We are exploring
> some alternatives, and will hopefully settle on one soon after the
> holidays.
>
> The basic problem, pointed out in a comment on Twitter, is that in
> expressions of the form
>
> 1 |> \(x) x + 1 -> y
> 1 |> \(x) x + 1 |> \(y) x + y
>
> everything after the \(x) is parsed as part of the body of the
> function. So these are parsed along the lines of
>
> 1 |> \(x) { x + 1 -> y }
> 1 |> \(x) { x + 1 |> \(y) x + y }
>
> In the first case the result is assigned to a (useless) local
> variable. Someone writing this is more likely to have intended to
> assign the result to a global variable, as this would:
>
> (1 |> \(x) x + 1) -> y
>
> In the second case the 'x' in 'x + y' refers to the local variable 'x'
> in the first RHS function. Someone writing this is more likely to have
> meant
>
> (1 |> \(x) x + 1) |> \(y) x + y
>
> with 'x' in 'x + y' now referring to a global variable:
>
> > x <- 2
> > 1 |> \(x) x + 1 |> \(y) x + y
> [1] 3
> > (1 |> \(x) x + 1) |> \(y) x + y
> [1] 4
>
> These issues arise with any approach in R that allows a bare function
> expression on the RHS of a pipe operation. It also arises in other
> languages with pipe operators. For example, here is the last example
> in Julia:
>
> julia> x = 2
> 2
> julia> 1 |> x -> x + 1 |> y -> x + y
> 3
> julia> ( 1 |> x -> x + 1 ) |> y -> x + y
> 4
>
> Even though proper use of parentheses can work around these issues,
> the likelihood of making mistakes that are hard to track down is too
> high. So we will disallow the use of bare function expressions on the
> right hand side of a pipe.
>
> Best,
>
> luke
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: New pipe operator
On Wed, Dec 9, 2020 at 12:36 PM Gabriel Becker wrote: > I mean, I think the bizarro pipe was a pretty clever piece of work. I was > impressed by what John did there, but I don't really know what you're > suggesting here. As you say, the bizarro pipe works now without any changes > and you're welcome to use it if you prefer it to base's (proposed/likely) |> > and magrittr's %>%. > If |> exists then it will be impossible to avoid it unless the only software you ever use is your own. It's about the entire R ecosystem and what gets used because it is in the base. It would still be possible to implement \(x)... without |> so I would go with that and rethink the pipe situation. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: New pipe operator
On Wed, Dec 9, 2020 at 10:08 AM Duncan Murdoch wrote: > > You might be interested in this blog post by Michael Barrowman: > > https://michaelbarrowman.co.uk/post/the-new-base-pipe/ > > He does some timing comparisons, and the current R-devel implementations > of |> and \() do quite well. It does bring out that the requirement of using functions to get around the lack of placeholders is not free but exacts a small penalty in terms of performance (in addition to verbosity). The bizarro pipe supports placeholders and so doesn't require functions as a workaround and thus would presumably be even faster. It is also perfectly consistent with the rest of R and requires no new syntax. You have to explicitly add a dot as the first argument but this seems a better compromise to me than those involved with |> . __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] the pipe |> and line breaks in pipelines
On Wed, Dec 9, 2020 at 4:03 AM Timothy Goodman wrote:
> But the bigger issue happens when I want to re-run just *part* of the
> pipeline.
Insert one of the following into the pipeline. It does not require that you
edit any lines. It only involves inserting a line.
print %>%
{ str(.); . } %>%
{ . ->> .save } %>%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: New pipe operator
On Mon, Dec 7, 2020 at 9:09 AM Gabor Grothendieck
wrote:
>
> On Sat, Dec 5, 2020 at 1:19 PM wrote:
> > Let's get some experience
>
> Here is my last SO post using dplyr rewritten to use R 4.1 devel. Seems
It occurred to me it would also be interesting to show this example
rewritten using John Mount's bizarro pipe
(which is clever use of syntax to get the effect of a pipe) with the
new \(x) ...
This can be done entirely in base R 4.1. It does not use \>, just \(x)...
"myfile.csv" ->.;
readLines(.) ->.;
gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) ->.;
read.csv(text = .) ->.;
replace(., 2:3, lapply(.[2:3], \(col) lapply(col, \(x)
eval(parse(text = x) ->.;
. -> DF
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] anonymous functions
On Mon, Dec 7, 2020 at 12:34 PM wrote: > I don't disagree in principle, but the reality is users want shortcuts > and as a result various packages, in particular tidyverse, have been > providing them. Mostly based on formulas, mostly with significant > issues since formulas weren't designed for this, and mostly > incompatible (tidyverse ones are compatible within tidyverse but not > with others). And of course none work in sapply or lapply. The formulas as functions in the gsubfn package work with nearly any function including sapply and lapply. library(gsubfn) fn$lapply(1:3, ~ x + 1) ## [1] 2 3 4 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
Duncan Murdoch: > I agree it's all about call expressions, but they aren't all being > treated equally: > > x |> f(...) > > expands to f(x, ...), while > > x |> `function`(...) > > expands to `function`(...)(x). This is an exception to the rule for Yes, this is the problem. It is trying to handle two different sorts of right hand sides, calls and functions, using only syntax level operations and it really needs to either make use of deeper information or have some method that is available at the syntax level for identifying whether the right hand side is a call or function. In the latter case having two operators would be one way to do it. f <- \(x) x + 1 x |> f() # call x |:> f # function x |:> \(x) x + 1 # function In the other case where deeper information is used there would only be one operator and it would handle all cases but would use more than just syntax level knowledge. R solved these sorts of problems long ago using S3 and other object oriented systems which dispatch different methods based on what the right hand side is. The attempt to avoid using the existing or equivalent mechanisms seems to have led to this problem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Mon, Dec 7, 2020 at 2:02 PM Kevin Ushey wrote:
>
> IMHO the use of anonymous functions is a very clean solution to the
> placeholder problem, and the shorthand lambda syntax makes it much
> more ergonomic to use. Pipe implementations that crawl the RHS for
> usages of `.` are going to be more expensive than the alternatives. It
You wouldn't have to crawl the expression. This does it at the syntax level.
e <- quote( { gsub("x", "y", .) } )
c(e[[1]], quote(. <- LHS), e[-1])
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Mon, Dec 7, 2020 at 12:54 PM Duncan Murdoch wrote:
> An advantage of the current implementation is that it's simple and easy
> to understand. Once you make it a user-modifiable binary operator,
> things will go kind of nuts.
>
> For example, I doubt if there are many users of magrittr's pipe who
> really understand its subtleties, e.g. the example in Luke's paper where
> 1 %>% c(., 2) gives c(1,2), but 1 %>% c(c(.), 2) gives c(1, 1, 2). (And
> I could add 1 %>% c(c(.), 2, .) and 1 %>% c(c(.), 2, . + 2) to
> continue the fun.)
The rule is not so complicated. Automatic insertion is done unless
you use dot in the top level function or if you surround it with
{...}. It really makes sense since if you use gsub(pattern,
replacement, .) then surely you don't want automatic insertion and if
you surround it with { ... } then you are explicitly telling it not
to.
Assuming the existence of placeholders a possible simplification would
be to NOT do automatic insertion if { ... } is used and to use it
otherwise although personally having used it for some time I find the
existing rule in magrittr generally does what you want.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anonymous functions
It is easier to understand a function if you can see the entire
function body at once on a page or screen and excessive verbosity
interferes with that.
On Mon, Dec 7, 2020 at 12:04 PM Therneau, Terry M., Ph.D. via R-devel
wrote:
>
> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be
> helpful in making
> code containing simple function expressions more readable.”
>
> Color me unimpressed.
> Over the decades I've seen several "who can write the shortest code" threads:
> in Fortran,
> in C, in Splus, ... The same old idea that "short" is a synonym for either
> elegant,
> readable, or efficient is now being recylced in the tidyverse. The truth is
> that "short"
> is actually an antonym for all of these things, at least for anyone else
> reading the code;
> or for the original coder 30-60 minutes after the "clever" lines were
> written. Minimal
> use of the spacebar and/or the return key isn't usually held up as a goal,
> but creeps into
> many practiioner's code as well.
>
> People are excited by replacing "function(" with "\("? Really? Are people
> typing code
> with their thumbs?
> I am ambivalent about pipes: I think it is a great concept, but too many of
> my colleagues
> think that using pipes = no need for any comments.
>
> As time goes on, I find my goal is to make my code less compact and more
> readable. Every
> bug fix or new feature in the survival package now adds more lines of
> comments or other
> documentation than lines of code. If I have to puzzle out what a line does,
> what about
> the poor sod who inherits the maintainance?
>
>
> --
> Terry M Therneau, PhD
> Department of Health Science Research
> Mayo Clinic
> thern...@mayo.edu
>
> "TERR-ree THUR-noh"
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: New pipe operator
On Mon, Dec 7, 2020 at 10:11 AM wrote:
> Or, keeping dplyr but with R-devel pipe and function shorthand:
>
> DF <- "myfile.csv" %>%
> readLines() |>
> \(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |>
> \(.) read.csv(text = .) |>
> mutate(across(2:3, \(col) lapply(col, \(x) eval(parse(text = x)
>
> Using named arguments to redirect to the implicit first does work,
> also in magrittr, but for me at least it is the kind of thing I would
> probably regret a month later when trying to figure out the code.
The gsub issue suggests that if one were to start afresh
that the arguments to gsub (and many other R functions)
should be rearranged. Of course, that is precisely what
the tidyverse did.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
One could examine how magrittr works as a reference implementation if there is a question on how something should function. It's in widespread use and seems to work well. On Mon, Dec 7, 2020 at 10:20 AM Deepayan Sarkar wrote: > > On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck > wrote: > > > > On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch > > wrote: > > > I agree it's all about call expressions, but they aren't all being > > > treated equally: > > > > > > x |> f(...) > > > > > > expands to f(x, ...), while > > > > > > x |> `function`(...) > > > > > > expands to `function`(...)(x). This is an exception to the rule for > > > other calls, but I think it's a justified one. > > > > This admitted inconsistency is justified by what? No argument has been > > presented. The justification seems to be implicitly driven by > > implementation > > concerns at the expense of usability and language consistency. > > Sorry if I have missed something, but is your consistency argument > basically that if > > foo <- function(x) x + 1 > > then > > x |> foo > x |> function(x) x + 1 > > should both work the same? Suppose it did. Would you then be OK if > > x |> foo() > > no longer worked as it does now, and produced foo()(x) instead of foo(x)? > > If you are not OK with that and want to retain the current behaviour, > what would you want to happen with the following? > > bar <- function(x) function(n) rnorm(n, mean = x) > > 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10) > 10 |> bar(runif(1)) # currently bar(10, runif(1)) > > both of which you probably want. But then > > baz <- bar(runif(1)) > 10 |> baz > > (not currently allowed) will not be the same as what you would want from > > 10 |> bar(runif(1)) > > which leads to a different kind of inconsistency, doesn't it? > > -Deepayan -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: New pipe operator
On Sat, Dec 5, 2020 at 1:19 PM wrote:
> Let's get some experience
Here is my last SO post using dplyr rewritten to use R 4.1 devel. Seems
not too bad. Was able to work around the placeholder for gsub by specifying
the arg names and used \(...)... elsewhere. This does not address the
inconsistency discussed though. I have indented by 2 spaced in case the
email wraps around. The objective is to read myfile.csv including columns that
contain c(...) and integer(0), parsing and evaluating them.
# taken from:
#
https://stackoverflow.com/questions/65174764/reading-in-a-csv-that-contains-vectors-cx-y-in-r/65175172#65175172
# create input file for testing
Lines <-
"\"col1\",\"col2\",\"col3\"\n\"a\",1,integer(0)\n\"c\",c(3,4),5\n\"e\",6,7\n"
cat(Lines, file = "myfile.csv")
#
# base R 4.1 (devel)
DF <- "myfile.csv" |>
readLines() |>
gsub(pattern = r'{(c\(.*?\)|integer\(0\))}', replacement = r'{"\1"}') |>
\(.) read.csv(text = .) |>
\(.) replace(., 2:3, lapply(.[2:3], \(col) lapply(col, \(x)
eval(parse(text = x)
#
# dplyr/magrittr
library(dplyr)
DF <- "myfile.csv" %>%
readLines %>%
gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) %>%
{ read.csv(text = .) } %>%
mutate(across(2:3, ~ lapply(., function(x) eval(parse(text = x)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch wrote: > I agree it's all about call expressions, but they aren't all being > treated equally: > > x |> f(...) > > expands to f(x, ...), while > > x |> `function`(...) > > expands to `function`(...)(x). This is an exception to the rule for > other calls, but I think it's a justified one. This admitted inconsistency is justified by what? No argument has been presented. The justification seems to be implicitly driven by implementation concerns at the expense of usability and language consistency. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
This is really irrelevant.
On Sun, Dec 6, 2020 at 9:23 PM Gabriel Becker wrote:
>
> Hi Gabor,
>
> On Sun, Dec 6, 2020 at 3:22 PM Gabor Grothendieck
> wrote:
>>
>> I understand very well that it is implemented at the syntax level;
>> however, in any case the implementation is irrelevant to the principles.
>>
>> Here a similar example to the one I gave before but this time written out:
>>
>> This works:
>>
>> 3 |> function(x) x + 1
>>
>> but this does not:
>>
>> foo <- function(x) x + 1
>> 3 |> foo
>>
>> so it breaks the principle of functions being first class objects. foo and
>> its
>> definition are not interchangeable.
>
>
> I understood what you meant as well.
>
> The issue is that neither foo nor its definition are being operated on, or
> even exist within the scope of what |> is defined to do. You are used to
> magrittr's %>% where arguably what you are saying would be true. But its not
> here, in my view.
>
> Again, I think the issue is that |>, in as much as it "operates" on anything
> at all (it not being a function, regardless of appearances), operates on call
> expression objects, NOT on functions, ever.
>
> function(x) x parses to a call expression as does RHSfun(), while RHSfun does
> not, it parses to a name, regardless of whether that symbol will eventually
> evaluate to a closure or not.
>
> So in fact, it seems to me that, technically, all name symbols are being
> treated exactly the same (none are allowed, including those which will lookup
> to functions during evaluation), while all* call expressions are also being
> treated the same. And again, there are no functions anywhere in either case.
>
> * except those that include that the parser flags as syntactically special.
>
>>
>> You have
>> to write 3 |> foo() but don't have to write 3 |> (function(x) x + 1)().
>
>
> I think you should probably be careful what you wish for here. I'm not
> involved with this work and do not speak for any of those who were, but the
> principled way to make that consistent while remaining entirely in the parser
> seems very likely to be to require the latter, rather than not require the
> former.
>
>>
>> This isn't just a matter of notation, i.e. foo vs foo(), but is a
>> matter of breaking
>> the way R works as a functional language with first class functions.
>
>
> I don't agree. Consider `+`
>
> Having
>
> foo <- get("+") ## note no `` here
> foo(x,y)
>
> parse and work correctly while
>
> +(x,y)
>
> does not does not mean + isn't a function or that it is a "second class
> citizen", it simply means that the parser has constraints on the syntax for
> writing code that calls it that calling other functions are not subject to.
> The fact that such syntactic constraints can exist proves that there is not
> some overarching inviolable principle being violated here, I think. Now you
> may say "well thats just the parser, it has to parse + specially because its
> an operator with specific precedence etc". Well, the same exact thing is true
> of |> I think.
>
> Best,
> ~G
>>
>>
>> On Sun, Dec 6, 2020 at 4:06 PM Gabriel Becker wrote:
>> >
>> > Hi Gabor,
>> >
>> > On Sun, Dec 6, 2020 at 12:52 PM Gabor Grothendieck
>> > wrote:
>> >>
>> >> I think the real issue here is that functions are supposed to be
>> >> first class objects in R
>> >> or are supposed to be and |> would break that if if is possible
>> >> to write function(x) x + 1 on the RHS but not foo (assuming foo
>> >> was defined as that function).
>> >>
>> >> I don't think getting experience with using it can change that
>> >> inconsistency which seems serious to me and needs to
>> >> be addressed even if it complicates the implementation
>> >> since it drives to the heart of what R is.
>> >>
>> >
>> > With respect I think this is a misunderstanding of what is happening here.
>> >
>> > Functions are first class citizens. |> is, for all intents and purposes, a
>> > macro.
>> >
>> > LHS |> RHS(arg2=5)
>> >
>> > parses to
>> >
>> > RHS(LHS, arg2 = 5)
>> >
>> > There are no functions at the point in time when the pipe transformation
>> > happens, because no code has been evaluated. To know if a symbol is going
>> > to evaluate to a function
Re: [Rd] New pipe operator
I understand very well that it is implemented at the syntax level; however, in any case the implementation is irrelevant to the principles. Here a similar example to the one I gave before but this time written out: This works: 3 |> function(x) x + 1 but this does not: foo <- function(x) x + 1 3 |> foo so it breaks the principle of functions being first class objects. foo and its definition are not interchangeable. You have to write 3 |> foo() but don't have to write 3 |> (function(x) x + 1)(). This isn't just a matter of notation, i.e. foo vs foo(), but is a matter of breaking the way R works as a functional language with first class functions. On Sun, Dec 6, 2020 at 4:06 PM Gabriel Becker wrote: > > Hi Gabor, > > On Sun, Dec 6, 2020 at 12:52 PM Gabor Grothendieck > wrote: >> >> I think the real issue here is that functions are supposed to be >> first class objects in R >> or are supposed to be and |> would break that if if is possible >> to write function(x) x + 1 on the RHS but not foo (assuming foo >> was defined as that function). >> >> I don't think getting experience with using it can change that >> inconsistency which seems serious to me and needs to >> be addressed even if it complicates the implementation >> since it drives to the heart of what R is. >> > > With respect I think this is a misunderstanding of what is happening here. > > Functions are first class citizens. |> is, for all intents and purposes, a > macro. > > LHS |> RHS(arg2=5) > > parses to > > RHS(LHS, arg2 = 5) > > There are no functions at the point in time when the pipe transformation > happens, because no code has been evaluated. To know if a symbol is going to > evaluate to a function requires evaluation which is a step entirely after the > one where the |> pipe is implemented. > > Another way to think about it is that > > LHS |> RHS(arg2 = 5) > > is another way of writing RHS(LHS, arg2 = 5), NOT R code that is (or even can > be) evaluated. > > > Now this is a subtle point that only really has implications in as much as it > is not the case for magrittr pipes, but its relevant for discussions like > this, I think. > > ~G > >> On Sat, Dec 5, 2020 at 1:08 PM Gabor Grothendieck >> wrote: >> > >> > The construct utils::head is not that common but bare functions are >> > very common and to make it harder to use the common case so that >> > the uncommon case is slightly easier is not desirable. >> > >> > Also it is trivial to write this which does work: >> > >> > mtcars %>% (utils::head) >> > >> > On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage >> > wrote: >> > > >> > > I'm surprised by the aversion to >> > > >> > > mtcars |> nrow >> > > >> > > over >> > > >> > > mtcars |> nrow() >> > > >> > > and I think the decision to disallow the former should be >> > > reconsidered. The pipe operator is only going to be used when the rhs >> > > is a function, so there is no ambiguity with omitting the parentheses. >> > > If it's disallowed, it becomes inconsistent with other treatments like >> > > sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be >> > > noise. I'm not sure why this decision was taken >> > > >> > > If the only issue is with the double (and triple) colon operator, then >> > > ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` >> > > -- in other words, demote the precedence of |> >> > > >> > > Obviously (looking at the R-Syntax branch) this decision was >> > > considered, put into place, then dropped, but I can't see why >> > > precisely. >> > > >> > > Best, >> > > >> > > >> > > Hugh. >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar >> > > wrote: >> > > > >> > > > On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch >> > > > wrote: >> > > > > >> > > > > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: >> > > > > >> Error: function '::' not supported in RHS call of a pipe >> > > > > > >> > > > > > To me, this error looks much more friendly than magrittr
Re: [Rd] New pipe operator
I think the real issue here is that functions are supposed to be first class objects in R or are supposed to be and |> would break that if if is possible to write function(x) x + 1 on the RHS but not foo (assuming foo was defined as that function). I don't think getting experience with using it can change that inconsistency which seems serious to me and needs to be addressed even if it complicates the implementation since it drives to the heart of what R is. On Sat, Dec 5, 2020 at 1:08 PM Gabor Grothendieck wrote: > > The construct utils::head is not that common but bare functions are > very common and to make it harder to use the common case so that > the uncommon case is slightly easier is not desirable. > > Also it is trivial to write this which does work: > > mtcars %>% (utils::head) > > On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage > wrote: > > > > I'm surprised by the aversion to > > > > mtcars |> nrow > > > > over > > > > mtcars |> nrow() > > > > and I think the decision to disallow the former should be > > reconsidered. The pipe operator is only going to be used when the rhs > > is a function, so there is no ambiguity with omitting the parentheses. > > If it's disallowed, it becomes inconsistent with other treatments like > > sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be > > noise. I'm not sure why this decision was taken > > > > If the only issue is with the double (and triple) colon operator, then > > ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` > > -- in other words, demote the precedence of |> > > > > Obviously (looking at the R-Syntax branch) this decision was > > considered, put into place, then dropped, but I can't see why > > precisely. > > > > Best, > > > > > > Hugh. > > > > > > > > > > > > > > > > On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar > > wrote: > > > > > > On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch > > > wrote: > > > > > > > > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > > > > >> Error: function '::' not supported in RHS call of a pipe > > > > > > > > > > To me, this error looks much more friendly than magrittr's error. > > > > > Some of them got too used to specify functions without (). This > > > > > is OK until they use `::`, but when they need to use it, it takes > > > > > hours to figure out why > > > > > > > > > > mtcars %>% base::head > > > > > #> Error in .::base : unused argument (head) > > > > > > > > > > won't work but > > > > > > > > > > mtcars %>% head > > > > > > > > > > works. I think this is a too harsh lesson for ordinary R users to > > > > > learn `::` is a function. I've been wanting for magrittr to drop the > > > > > support for a function name without () to avoid this confusion, > > > > > so I would very much welcome the new pipe operator's behavior. > > > > > Thank you all the developers who implemented this! > > > > > > > > I agree, it's an improvement on the corresponding magrittr error. > > > > > > > > I think the semantics of not evaluating the RHS, but treating the pipe > > > > as purely syntactical is a good decision. > > > > > > > > I'm not sure I like the recommended way to pipe into a particular > > > > argument: > > > > > > > >mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d) > > > > > > > > or > > > > > > > >mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d) > > > > > > > > both of which are equivalent to > > > > > > > >mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = > > > > d))() > > > > > > > > It's tempting to suggest it should allow something like > > > > > > > >mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) > > > > > > Which is really not that far off from > > > > > > mtcars |> subset(cyl == 4) |> \(.) lm(mpg ~ disp, data = .) > > > > > > once you get used to it. > > > > > > One consequence of the implementation is that it's not c
Re: [Rd] [External] Re: New pipe operator
Why is that ambiguous? It works in magrittr. > library(magrittr) > 1 %>% `+`() [1] 1 On Sun, Dec 6, 2020 at 1:09 PM wrote: > > On Sun, 6 Dec 2020, Gabor Grothendieck wrote: > > > The following gives an error. > > > > 1 |> `+`(2) > > ## Error: function '+' is not supported in RHS call of a pipe > > > > 1 |> `+`() > > ## Error: function '+' is not supported in RHS call of a pipe > > > > but this does work: > > > > 1 |> (`+`)(2) > > ## [1] 3 > > > > 1 |> (`+`)() > > ## [1] 1 > > > > The error message suggests that this was intentional. > > It isn't mentioned in ?"|>" > > ?"|>" says: > > To avoid ambiguities, functions in ‘rhs’ calls may not > be syntactically special, such as ‘+’ or ‘if’. > > (used to say lhs; fixed now). > > Best, > > luke > > > > > On Sat, Dec 5, 2020 at 1:19 PM wrote: > >> > >> We went back and forth on this several times. The key advantage of > >> requiring parentheses is to keep things simple and consistent. Let's > >> get some experience with that. If experience shows requiring > >> parentheses creates too many issues then we can add the option of > >> dropping them later (with special handling of :: and :::). It's easier > >> to add flexibility and complexity than to restrict it after the fact. > >> > >> Best, > >> > >> luke > >> > >> On Sat, 5 Dec 2020, Hugh Parsonage wrote: > >> > >>> I'm surprised by the aversion to > >>> > >>> mtcars |> nrow > >>> > >>> over > >>> > >>> mtcars |> nrow() > >>> > >>> and I think the decision to disallow the former should be > >>> reconsidered. The pipe operator is only going to be used when the rhs > >>> is a function, so there is no ambiguity with omitting the parentheses. > >>> If it's disallowed, it becomes inconsistent with other treatments like > >>> sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be > >>> noise. I'm not sure why this decision was taken > >>> > >>> If the only issue is with the double (and triple) colon operator, then > >>> ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` > >>> -- in other words, demote the precedence of |> > >>> > >>> Obviously (looking at the R-Syntax branch) this decision was > >>> considered, put into place, then dropped, but I can't see why > >>> precisely. > >>> > >>> Best, > >>> > >>> > >>> Hugh. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar > >>> wrote: > >>>> > >>>> On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch > >>>> wrote: > >>>>> > >>>>> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > >>>>>>> Error: function '::' not supported in RHS call of a pipe > >>>>>> > >>>>>> To me, this error looks much more friendly than magrittr's error. > >>>>>> Some of them got too used to specify functions without (). This > >>>>>> is OK until they use `::`, but when they need to use it, it takes > >>>>>> hours to figure out why > >>>>>> > >>>>>> mtcars %>% base::head > >>>>>> #> Error in .::base : unused argument (head) > >>>>>> > >>>>>> won't work but > >>>>>> > >>>>>> mtcars %>% head > >>>>>> > >>>>>> works. I think this is a too harsh lesson for ordinary R users to > >>>>>> learn `::` is a function. I've been wanting for magrittr to drop the > >>>>>> support for a function name without () to avoid this confusion, > >>>>>> so I would very much welcome the new pipe operator's behavior. > >>>>>> Thank you all the developers who implemented this! > >>>>> > >>>>> I agree, it's an improvement on the corresponding magrittr error. > >>>>> > >>>>> I think the semantics of not evaluating
Re: [Rd] [External] Re: New pipe operator
The following gives an error. 1 |> `+`(2) ## Error: function '+' is not supported in RHS call of a pipe 1 |> `+`() ## Error: function '+' is not supported in RHS call of a pipe but this does work: 1 |> (`+`)(2) ## [1] 3 1 |> (`+`)() ## [1] 1 The error message suggests that this was intentional. It isn't mentioned in ?"|>" On Sat, Dec 5, 2020 at 1:19 PM wrote: > > We went back and forth on this several times. The key advantage of > requiring parentheses is to keep things simple and consistent. Let's > get some experience with that. If experience shows requiring > parentheses creates too many issues then we can add the option of > dropping them later (with special handling of :: and :::). It's easier > to add flexibility and complexity than to restrict it after the fact. > > Best, > > luke > > On Sat, 5 Dec 2020, Hugh Parsonage wrote: > > > I'm surprised by the aversion to > > > > mtcars |> nrow > > > > over > > > > mtcars |> nrow() > > > > and I think the decision to disallow the former should be > > reconsidered. The pipe operator is only going to be used when the rhs > > is a function, so there is no ambiguity with omitting the parentheses. > > If it's disallowed, it becomes inconsistent with other treatments like > > sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be > > noise. I'm not sure why this decision was taken > > > > If the only issue is with the double (and triple) colon operator, then > > ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` > > -- in other words, demote the precedence of |> > > > > Obviously (looking at the R-Syntax branch) this decision was > > considered, put into place, then dropped, but I can't see why > > precisely. > > > > Best, > > > > > > Hugh. > > > > > > > > > > > > > > > > On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar > > wrote: > >> > >> On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch > >> wrote: > >>> > >>> On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > > Error: function '::' not supported in RHS call of a pipe > > To me, this error looks much more friendly than magrittr's error. > Some of them got too used to specify functions without (). This > is OK until they use `::`, but when they need to use it, it takes > hours to figure out why > > mtcars %>% base::head > #> Error in .::base : unused argument (head) > > won't work but > > mtcars %>% head > > works. I think this is a too harsh lesson for ordinary R users to > learn `::` is a function. I've been wanting for magrittr to drop the > support for a function name without () to avoid this confusion, > so I would very much welcome the new pipe operator's behavior. > Thank you all the developers who implemented this! > >>> > >>> I agree, it's an improvement on the corresponding magrittr error. > >>> > >>> I think the semantics of not evaluating the RHS, but treating the pipe > >>> as purely syntactical is a good decision. > >>> > >>> I'm not sure I like the recommended way to pipe into a particular > >>> argument: > >>> > >>>mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d) > >>> > >>> or > >>> > >>>mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d) > >>> > >>> both of which are equivalent to > >>> > >>>mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))() > >>> > >>> It's tempting to suggest it should allow something like > >>> > >>>mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) > >> > >> Which is really not that far off from > >> > >> mtcars |> subset(cyl == 4) |> \(.) lm(mpg ~ disp, data = .) > >> > >> once you get used to it. > >> > >> One consequence of the implementation is that it's not clear how > >> multiple occurrences of the placeholder would be interpreted. With > >> magrittr, > >> > >> sort(runif(10)) %>% ecdf(.)(.) > >> ## [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > >> > >> This is probably what you would expect, if you expect it to work at all, > >> and not > >> > >> ecdf(sort(runif(10)))(sort(runif(10))) > >> > >> There would be no such ambiguity with anonymous functions > >> > >> sort(runif(10)) |> \(.) ecdf(.)(.) > >> > >> -Deepayan > >> > >>> which would be expanded to something equivalent to the other versions: > >>> but that makes it quite a bit more complicated. (Maybe _ or \. should > >>> be used instead of ., since those are not legal variable names.) > >>> > >>> I don't think there should be an attempt to copy magrittr's special > >>> casing of how . is used in determining whether to also include the > >>> previous value as first argument. > >>> > >>> Duncan Murdoch > >>> > >>> > > Best, > Hiroaki Yutani > > 2020年12月4日(金) 20:51 Duncan Murdoch : > > > > Just saw this on the R-devel news: > > > > > > R now provides a simple native pipe syntax ‘|>’ as well as a shorthand > > notation for creating functions, e.g
Re: [Rd] installling R-devel on Windows
I meant on the R devel download page. (I was just installing Rtools40 on another computer.) On Sun, Dec 6, 2020 at 10:27 AM Gabor Grothendieck wrote: > > I tried it from another computer and it did work. Is there some way > of installing R devel using the analog of the R --vanilla flag so that I can > do it in a reproducible manner. It seems to remember prior settings > and maybe that is a problem although one would not expect a setting > that could lead to what occurs. I don't see anything documenting flags > on the Rtools40 page. > > On Sat, Dec 5, 2020 at 9:52 AM Gabor Grothendieck > wrote: > > > > I clicked on the download link at > > https://cran.r-project.org/bin/windows/base/rdevel.html > > and then opened the downloaded file which starts the installation process. > > I specified a new directory that does not exist, R-test, to be sure that > > it would not get confused with an old directory. > > > > I repeated this using different directories and on different days. > > > > I tried it from a user and an Admin account. > > > > If I use the exact same procedure to install R-4.0.3patched it works. > > > > I have successfully downloaded and installed R maybe hundreds > > of times over the last 10 to 20 years and have never before > > encountered this. > > > > > > > > > > > > On Sat, Dec 5, 2020 at 9:13 AM Jeroen Ooms wrote: > > > > > > On Sat, Dec 5, 2020 at 3:00 PM Gabor Grothendieck > > > wrote: > > > > > > > > When I try to install r-devel on Windows all I get is this. No other > > > > files. This also occurred yesterday as well. > > > > > > It just tested it to be sure, but it works fine for me. Are you using > > > the official installer from > > > https://cran.r-project.org/bin/windows/base/rdevel.html ? > > > > > > The default install path is not R-test C:\Program Files\R\R-devel. > > > Perhaps you have old files lingering from previous installations that > > > cause permission problems during the installation process? > > > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] installling R-devel on Windows
I tried it from another computer and it did work. Is there some way of installing R devel using the analog of the R --vanilla flag so that I can do it in a reproducible manner. It seems to remember prior settings and maybe that is a problem although one would not expect a setting that could lead to what occurs. I don't see anything documenting flags on the Rtools40 page. On Sat, Dec 5, 2020 at 9:52 AM Gabor Grothendieck wrote: > > I clicked on the download link at > https://cran.r-project.org/bin/windows/base/rdevel.html > and then opened the downloaded file which starts the installation process. > I specified a new directory that does not exist, R-test, to be sure that > it would not get confused with an old directory. > > I repeated this using different directories and on different days. > > I tried it from a user and an Admin account. > > If I use the exact same procedure to install R-4.0.3patched it works. > > I have successfully downloaded and installed R maybe hundreds > of times over the last 10 to 20 years and have never before > encountered this. > > > > > > On Sat, Dec 5, 2020 at 9:13 AM Jeroen Ooms wrote: > > > > On Sat, Dec 5, 2020 at 3:00 PM Gabor Grothendieck > > wrote: > > > > > > When I try to install r-devel on Windows all I get is this. No other > > > files. This also occurred yesterday as well. > > > > It just tested it to be sure, but it works fine for me. Are you using > > the official installer from > > https://cran.r-project.org/bin/windows/base/rdevel.html ? > > > > The default install path is not R-test C:\Program Files\R\R-devel. > > Perhaps you have old files lingering from previous installations that > > cause permission problems during the installation process? > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.POSIXct.numeric change default of origin argument
For example, this works: library(zoo) as.Date(0) ## [1] "1970-01-01" On Sun, Dec 6, 2020 at 7:10 AM Achim Zeileis wrote: > > On Sun, 6 Dec 2020, Jan Gorecki wrote: > > > Hello all, > > > > I would like to propose to change the default value for "origin" > > argument in as.POSIXct.numeric method, from current missing to new > > "1970-01-01". > > My proposal is motivated by the fact that this is the most commonly > > needed value for "origin" argument and having that as a default seems > > reasonable. > > Proposed change seems to be pretty safe because it is now an error. > > I would also be in favor of this (and have been for years), mostly to make > it consistent with the as.numeric() method. Same for "Date". > > To support the latter, the "zoo" package provides a separate as.Date() > generic that enables the as.Date.numeric() with different default. > > The main argument of R Core against it is that it is too uncertain whether > the origin is really 1970-01-01, e.g., when importing from Excel or SAS. > > Best wishes, > Z > > > __ > > 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 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
The construct utils::head is not that common but bare functions are very common and to make it harder to use the common case so that the uncommon case is slightly easier is not desirable. Also it is trivial to write this which does work: mtcars %>% (utils::head) On Sat, Dec 5, 2020 at 11:59 AM Hugh Parsonage wrote: > > I'm surprised by the aversion to > > mtcars |> nrow > > over > > mtcars |> nrow() > > and I think the decision to disallow the former should be > reconsidered. The pipe operator is only going to be used when the rhs > is a function, so there is no ambiguity with omitting the parentheses. > If it's disallowed, it becomes inconsistent with other treatments like > sapply(mtcars, typeof) where sapply(mtcars, typeof()) would just be > noise. I'm not sure why this decision was taken > > If the only issue is with the double (and triple) colon operator, then > ideally `mtcars |> base::head` should resolve to `base::head(mtcars)` > -- in other words, demote the precedence of |> > > Obviously (looking at the R-Syntax branch) this decision was > considered, put into place, then dropped, but I can't see why > precisely. > > Best, > > > Hugh. > > > > > > > > On Sat, 5 Dec 2020 at 04:07, Deepayan Sarkar > wrote: > > > > On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch > > wrote: > > > > > > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > > > >> Error: function '::' not supported in RHS call of a pipe > > > > > > > > To me, this error looks much more friendly than magrittr's error. > > > > Some of them got too used to specify functions without (). This > > > > is OK until they use `::`, but when they need to use it, it takes > > > > hours to figure out why > > > > > > > > mtcars %>% base::head > > > > #> Error in .::base : unused argument (head) > > > > > > > > won't work but > > > > > > > > mtcars %>% head > > > > > > > > works. I think this is a too harsh lesson for ordinary R users to > > > > learn `::` is a function. I've been wanting for magrittr to drop the > > > > support for a function name without () to avoid this confusion, > > > > so I would very much welcome the new pipe operator's behavior. > > > > Thank you all the developers who implemented this! > > > > > > I agree, it's an improvement on the corresponding magrittr error. > > > > > > I think the semantics of not evaluating the RHS, but treating the pipe > > > as purely syntactical is a good decision. > > > > > > I'm not sure I like the recommended way to pipe into a particular > > > argument: > > > > > >mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d) > > > > > > or > > > > > >mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d) > > > > > > both of which are equivalent to > > > > > >mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))() > > > > > > It's tempting to suggest it should allow something like > > > > > >mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) > > > > Which is really not that far off from > > > > mtcars |> subset(cyl == 4) |> \(.) lm(mpg ~ disp, data = .) > > > > once you get used to it. > > > > One consequence of the implementation is that it's not clear how > > multiple occurrences of the placeholder would be interpreted. With > > magrittr, > > > > sort(runif(10)) %>% ecdf(.)(.) > > ## [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 > > > > This is probably what you would expect, if you expect it to work at all, > > and not > > > > ecdf(sort(runif(10)))(sort(runif(10))) > > > > There would be no such ambiguity with anonymous functions > > > > sort(runif(10)) |> \(.) ecdf(.)(.) > > > > -Deepayan > > > > > which would be expanded to something equivalent to the other versions: > > > but that makes it quite a bit more complicated. (Maybe _ or \. should > > > be used instead of ., since those are not legal variable names.) > > > > > > I don't think there should be an attempt to copy magrittr's special > > > casing of how . is used in determining whether to also include the > > > previous value as first argument. > > > > > > Duncan Murdoch > > > > > > > > > > > > > > Best, > > > > Hiroaki Yutani > > > > > > > > 2020年12月4日(金) 20:51 Duncan Murdoch : > > > >> > > > >> Just saw this on the R-devel news: > > > >> > > > >> > > > >> R now provides a simple native pipe syntax ‘|>’ as well as a shorthand > > > >> notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as > > > >> ‘function(x) x + 1’. The pipe implementation as a syntax transformation > > > >> was motivated by suggestions from Jim Hester and Lionel Henry. These > > > >> features are experimental and may change prior to release. > > > >> > > > >> > > > >> This is a good addition; by using "|>" instead of "%>%" there should be > > > >> a chance to get operator precedence right. That said, the ?Syntax help > > > >> topic hasn't been updated, so I'm not sure where it fits in. > > > >> > > > >> There are some choices that take a little getting used to: > > > >> > > > >> > mtcars |> head > > > >
Re: [Rd] installling R-devel on Windows
I clicked on the download link at https://cran.r-project.org/bin/windows/base/rdevel.html and then opened the downloaded file which starts the installation process. I specified a new directory that does not exist, R-test, to be sure that it would not get confused with an old directory. I repeated this using different directories and on different days. I tried it from a user and an Admin account. If I use the exact same procedure to install R-4.0.3patched it works. I have successfully downloaded and installed R maybe hundreds of times over the last 10 to 20 years and have never before encountered this. On Sat, Dec 5, 2020 at 9:13 AM Jeroen Ooms wrote: > > On Sat, Dec 5, 2020 at 3:00 PM Gabor Grothendieck > wrote: > > > > When I try to install r-devel on Windows all I get is this. No other > > files. This also occurred yesterday as well. > > It just tested it to be sure, but it works fine for me. Are you using > the official installer from > https://cran.r-project.org/bin/windows/base/rdevel.html ? > > The default install path is not R-test C:\Program Files\R\R-devel. > Perhaps you have old files lingering from previous installations that > cause permission problems during the installation process? -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] installling R-devel on Windows
When I try to install r-devel on Windows all I get is this. No other files. This also occurred yesterday as well. Directory of C:\Program Files\R\R-test 12/05/2020 08:56 AM . 12/05/2020 08:56 AM .. 12/05/2020 08:56 AM11,503 unins000.dat 12/05/2020 08:56 AM 2,594,145 unins000.exe 2 File(s) 2,605,648 bytes -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ftable <-> data.frame etc {was "justify hard coded in format.ftable"}
That's not the problem. The problem is that if you have
ft <- ftable(UCBAdmissions, row.vars = 3:2)
ft
## Admit Admitted Rejected
## Dept Gender
## AMale 512 313
## Female 89 19
## BMale 353 207
## Female 178
## CMale 120 205
## ... etc ...
then as.data.frame(ft) gives a deconstructed 24x4 data.frame
like this:
as.data.frame(ft)
##Dept GenderAdmit Freq
## 1 A Male Admitted 512
## 2 B Male Admitted 353
## 3 C Male Admitted 120
## 4 D Male Admitted 138
## ... etc ...
which is fine but it does not address the problem here. The
problem here is that we want a a usable data.frame
having columns that correspond to ft. We want this 12x4
data.frame:
##Dept Gender Admitted Rejected
## 1 A Male 512 313
## 2 A Female 89 19
## 3 B Male 353 207
## 4 B Female 178
## ... etc ...
The links I provided already pointed to the code below which
someone posted on SO and solves the problem but I would
have thought this would be easy to do in base R and natural
to provide.
ftable2df <- function(mydata) {
ifelse(class(mydata) == "ftable",
mydata <- mydata, mydata <- ftable(mydata))
dfrows <- rev(expand.grid(rev(attr(mydata, "row.vars"
dfcols <- as.data.frame.matrix(mydata)
names(dfcols) <- do.call(
paste, c(rev(expand.grid(rev(attr(mydata, "col.vars", sep = "_"))
cbind(dfrows, dfcols)
}
ftable2df(ft)
##Dept Gender Admitted Rejected
## 1 A Male 512 313
## 2 A Female 89 19
## 3 B Male 353 207
## 4 B Female 178
## ... etc ...
Fri, May 15, 2020 at 12:25 PM Martin Maechler
wrote:
>
> >>>>> Gabor Grothendieck
> >>>>> on Thu, 14 May 2020 06:56:06 -0400 writes:
>
> > If you are looking at ftable could you also consider adding
> > a way to convert an ftable into a usable data.frame such as
> > the ftable2df function defined here:
>
> > https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
>
> > and there is an example of using it here:
>
> > https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
>
> > Being able to move back and forth between various base class representations
> > seems like something that would be natural to provide.
>
> Sure!
>
> But there is already an as.data.frame() method for "ftable",
> {and I would not want theif(! .. ftable) ftable(x) part anyway.
>
> What I think many useRs / programmeRs very often forget about
> is more-than-2-dimensional arrays {which *are* at the beginning
> of that SO question} and that these are often by far the most
> efficient data structure (rather than the corresponding data frames).
>
> and even less people forget that a "table" in base R is just a
> special case of a 1-D, 2-D, 3-D, array.
> (Semantically a special case: "array" with non-negative integer content
>
> I'd claim that everything you here ("move back and forth between
> ...") is already there in the "ftable" implementation in stats,
> notably in the source file src/library/stats/R/ftable.R
> -> https://svn.r-project.org/R/trunk/src/library/stats/R/ftable.R
>
> The problem may be in
>
> 1) too sparse documentation about the close relations
>"ftable" <-> "array" <-> "table" <-> "data.frame"
>
> 2) people not thinking often enough about more-than-2D-arrays and the
> special corresponding class "table" in R.
>
> To start with one:
>
> > str(UCBAdmissions)
> 'table' num [1:2, 1:2, 1:6] 512 313 89 19 353 207 17 8 120 205 ...
> - attr(*, "dimnames")=List of 3
> ..$ Admit : chr [1:2] "Admitted" "Rejected"
> ..$ Gender: chr [1:2] "Male" "Female"
> ..$ Dept : chr [1:6] "A" "B" "C" "D" ...
> >
>
> and look at the *examples* in the help files and the S3 methods
>
> methods(class = "ftable")
> [1] as.data.frame as.matrix as.table formathead
> print
> [7] tail
> see '?methods' for accessing help and source code
> > methods(class = "table")
> [1] [ aperm as.data.frame Axis coerce
> initialize
> [7] lines plot pointsprint
Re: [Rd] justify hard coded in format.ftable
If you are looking at ftable could you also consider adding
a way to convert an ftable into a usable data.frame such as
the ftable2df function defined here:
https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
and there is an example of using it here:
https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
Being able to move back and forth between various base class representations
seems like something that would be natural to provide.
Thanks.
On Thu, May 14, 2020 at 5:32 AM Martin Maechler
wrote:
>
> > SOEIRO Thomas
> > on Wed, 13 May 2020 20:27:15 + writes:
>
> > Dear all,
> > I haven't received any feedback so far on my proposal to make "justify"
> argument available in stats:::format.ftable
>
> > Is this list the appropriate place for this kind of proposal?
>
> Yes, it is.. Actually such a post is even a "role model" post
> for R-devel.
>
> > I hope this follow-up to my message won't be taken as rude. Of course
> it's not meant to be, but I'm not used to the R mailing lists...
>
> well, there could be said much, and many stories told here ... ;-)
>
> > Thank you in advance for your comments,
>
> > Best,
> > Thomas
>
> The main reasons for "no reaction" (for such nice post) probably
> are combination of the following
>
> - we are busy
> - if we have time, we think other things are more exciting
> - we have not used ftable much/at all and are not interested.
>
> Even though the first 2 apply to me, I'll have a 2nd look into
> your post now, and may end up well agreeing with your proposal.
>
> Martin Maechler
> ETH Zurich and R Core team
>
>
>
>
> >> Dear all,
> >>
> >> justify argument is hard coded in format.ftable:
> >>
> >> cbind(apply(LABS, 2L, format, justify = "left"),
> >> apply(DATA, 2L, format, justify = "right"))
> >>
> >> It would be useful to have the possibility to modify the argument
> between c("left", "right", "centre", "none") as in format.default.
> >>
> >> The lines could be changed to:
> >>
> >> if(length(justify) != 2)
> >> stop("justify must be length 2")
> >> cbind(apply(LABS, 2L, format, justify = justify[1]),
> >> apply(DATA, 2L, format, justify = justify[2]))
> >>
> >> The argument justify could defaults to c("left", "right") for backward
> compatibility.
> >>
> >> It could then allow:
> >> ftab <- ftable(wool + tension ~ breaks, warpbreaks)
> >> format.ftable(ftab, justify = c("none", "none"))
> >>
> >> Best regards,
> >>
> >> Thomas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] justify hard coded in format.ftable
One can use as.data.frame(as.matrix(tab)) to avoid calling
as.data.frame.matrix directly
(although I find I do use as.data.frame.matrix anyways sometimes even
though it is generally
better to call the generic.).
Also note that the various as.data.frame methods do not address the examples
in the SO links I posted which is why I mentioned it.
On Thu, May 14, 2020 at 9:22 AM SOEIRO Thomas wrote:
>
> Thanks for the links. I agree that such a feature would be a nice addition,
> and could make ftable even more useful.
>
> In the same spirit, I think it could be useful to mention the undocumented
> base::as.data.frame.matrix function in documentation of table and xtabs (in
> addition to the already mentioned base::as.data.frame.table). The conversion
> from ftable/table/xtabs to data.frame is a common task that some users seem
> to struggle with
> (https://stackoverflow.com/questions/10758961/how-to-convert-a-table-to-a-data-frame).
>
> tab <- table(warpbreaks$wool, warpbreaks$tension)
> as.data.frame(tab) # reshaped table
> as.data.frame.matrix(tab) # non-reshaped table
>
> To sum up, for the sake of clarity, these proposals address two different
> topics:
> - The justify argument would reduce the need to reformat the exported ftable
> - An ftable2df-like function (and the mention of as.data.frame.matrix in the
> documentation) would facilitate the reuse of ftable results for further
> analysis.
>
> Thank you very much,
>
> Thomas
>
> > If you are looking at ftable could you also consider adding a way to
> > convert an ftable into a usable data.frame such as the ftable2df function
> > defined here:
> >
> > https://stackoverflow.com/questions/11141406/reshaping-an-array-to-data-frame/11143126#11143126
> >
> > and there is an example of using it here:
> >
> > https://stackoverflow.com/questions/61333663/manipulating-an-array-into-a-data-frame-in-base-r/61334756#61334756
> >
> > Being able to move back and forth between various base class
> > representations seems like something that would be natural to provide.
> >
> > Thanks.
> >
> > On Thu, May 14, 2020 at 5:32 AM Martin Maechler
> > wrote:
> >>
> >>> SOEIRO Thomas
> >>> on Wed, 13 May 2020 20:27:15 + writes:
> >>
> >>> Dear all,
> >>> I haven't received any feedback so far on my proposal to make
> >> "justify" argument available in stats:::format.ftable
> >>
> >>> Is this list the appropriate place for this kind of proposal?
> >>
> >> Yes, it is.. Actually such a post is even a "role model" post for
> >> R-devel.
> >>
> >>> I hope this follow-up to my message won't be taken as rude. Of course
> >>> it's not meant to be, but I'm not used to the R mailing lists...
> >>
> >> well, there could be said much, and many stories told here ... ;-)
> >>
> >>> Thank you in advance for your comments,
> >>
> >>> Best,
> >>> Thomas
> >>
> >> The main reasons for "no reaction" (for such nice post) probably are
> >> combination of the following
> >>
> >> - we are busy
> >> - if we have time, we think other things are more exciting
> >> - we have not used ftable much/at all and are not interested.
> >>
> >> Even though the first 2 apply to me, I'll have a 2nd look into your
> >> post now, and may end up well agreeing with your proposal.
> >>
> >> Martin Maechler
> >> ETH Zurich and R Core team
> >>
> >>
> >>
> >>
> Dear all,
>
> justify argument is hard coded in format.ftable:
>
> cbind(apply(LABS, 2L, format, justify = "left"),
> apply(DATA, 2L, format, justify = "right"))
>
> It would be useful to have the possibility to modify the argument
> between c("left", "right", "centre", "none") as in format.default.
>
> The lines could be changed to:
>
> if(length(justify) != 2)
> stop("justify must be length 2")
> cbind(apply(LABS, 2L, format, justify = justify[1]),
> apply(DATA, 2L, format, justify = justify[2]))
>
> The argument justify could defaults to c("left", "right") for backward
> compatibility.
>
> It could then allow:
> ftab <- ftable(wool + tension ~ breaks, warpbreaks)
> format.ftable(ftab, justify = c("none", "none"))
>
> Best regards,
>
> Thomas
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion: "." in [lsv]apply()
I wouldn't drive my choices using unlikely edge cases
but rather focus on the vast majority of practical cases.
The popularity of tidyverse shows that this philosophy
works well from a user's perspective.
For the vast majority of practical cases it works well, and for the
others you can either use function as usual or do it like this:
lapply(quote(a + b), fn$identity(~ as.character(x)))
or (we used dot here but you can use any name you like)
. <- fn$identity
lapply(quote(a + b), .(~ as.character(x)))
For the vast majority of practical cases it has the advantages that the function
can be represented more naturally using whatever argument names are most
convenient rather than being forced to use reserved names and it supports
multiple arguments and dot dot dot.
Also it does more than just represent functions. It also interpolates strings
so it can be used for multiple purposes.
library(sqldf)
mytime <- 4
fn$sqldf("select * from BOD where Time < $mytime")
On Mon, Apr 20, 2020 at 9:32 AM Sokol Serguei wrote:
>
> Le 19/04/2020 à 20:46, Gabor Grothendieck a écrit :
> > You can get pretty close to that already using fn$ in the gsubfn package:
> >> library(gsubfn) fn$sapply(split(mtcars, mtcars$cyl), x ~
> >> summary(lm(mpg ~ wt, x))$r.squared)
> > 4 6 8 0.5086326 0.4645102 0.4229655
> Right, I thought about similar syntax but this implementation has
> similar flaws pointed by Simon, i.e. it reduces the domain of valid
> inputs (though not on the same parameters). Take an example:
>
> library(gsubfn)
> fn$sapply(quote(x+y), as.character)
> #Error in lapply(X = X, FUN = FUN, ...) : object 'x' not found
>
> while
>
> sapply(quote(x+y), as.character)
> #[1] "+" "x" "y"
>
> This makes me think that it could be advantageous to replace
> match.fun(FUN) in *apply() family by as.function(FUN) with obvious
> additional methods:
> as.function.character <- function(x) match.fun(x)
> as.function.name <- function(x) match.fun(x)
>
> Such replacement would leave current usage of *apply() as is but at the
> same time would leave enough space for users who want to adapt *apply()
> to their objects like formula or whatever class that is currently not
> convertible to functions by match.fun()
>
> Would it be possible?
>
> Best,
> Serguei.
>
> > It is not specific to sapply but rather fn$ can preface most
> > functions. If the only free variables are the arguments to the
> > function then you can omit the left hand side of the formula, i.e. the
> > arguments to the function are implied by the free variables in the
> > right hand side. Here x is the implied argument to the function
> > because it is a free variable. We did not have use the name x. Any
> > name could be used. It is the fact that it is a free variable, not its
> > name, that matters.
> >> fn$sapply(split(mtcars, mtcars$cyl), ~ sum(dim(x)))
> > 4 6 8 22 18 25 On Fri, Apr 17, 2020 at 4:11 AM Sokol Serguei
> > wrote:
> >> Thanks Simon, Now, I see better your argument. Le 16/04/2020 à 22:48,
> >> Simon Urbanek a écrit :
> >>> ... I'm not arguing against the principle, I'm arguing about your
> >>> particular proposal as it is inconsistent and not general.
> >> This sounds promising for me. May be in a (new?) future, R core will
> >> come with a correct proposal for this principle? Meanwhile, to avoid
> >> substitute(), I'll look on the side of formula syntax deviation as
> >> your example x ~> i + x suggested. Best, Serguei.
> >>> Personally, I find the current syntax much clearer and readable
> >>> (defining anything by convention like . being the function variable
> >>> seems arbitrary and "dirty" to me), but if you wanted to define a
> >>> shorter syntax, you could use something like x ~> i + x. That said,
> >>> I really don't see the value of not using function(x) [especially
> >>> these days when people are arguing for long variable names with the
> >>> justification that IDEs do all the work anyway], but as I said, my
> >>> argument was against the actual proposal, not general ideas about
> >>> syntax improvement. Cheers, Simon
> >>>> On 17/04/2020, at 3:53 AM, Sokol Serguei
> >>>> wrote: Simon, Thanks for replying. In what follows I won't try to
> >>>> argue (I understood that you find this a bad idea) but I would like
> >>>> to make clearer some of your point for me (and may be for others).
> >>>> Le 16/04/2020 à 16:48, Simon Urbanek a écrit :
> >>>>> Serguei,
> >&g
Re: [Rd] suggestion: "." in [lsv]apply()
You can get pretty close to that already using fn$ in the gsubfn package:
> library(gsubfn)
> fn$sapply(split(mtcars, mtcars$cyl), x ~ summary(lm(mpg ~ wt, x))$r.squared)
4 6 8
0.5086326 0.4645102 0.4229655
It is not specific to sapply but rather fn$ can preface most functions.
If the only free variables are the arguments to the function then you
can omit the left hand side of the formula, i.e. the arguments to the
function are implied by the free variables in the right hand side. Here
x is the implied argument to the function because it is a free variable.
We did not have use the name x. Any name could be used. It is the
fact that it is a free variable, not its name, that matters.
> fn$sapply(split(mtcars, mtcars$cyl), ~ sum(dim(x)))
4 6 8
22 18 25
On Fri, Apr 17, 2020 at 4:11 AM Sokol Serguei wrote:
>
> Thanks Simon,
>
> Now, I see better your argument.
>
> Le 16/04/2020 à 22:48, Simon Urbanek a écrit :
> > ... I'm not arguing against the principle, I'm arguing about your
> > particular proposal as it is inconsistent and not general.
> This sounds promising for me. May be in a (new?) future, R core will
> come with a correct proposal for this principle?
> Meanwhile, to avoid substitute(), I'll look on the side of formula
> syntax deviation as your example x ~> i + x suggested.
>
> Best,
> Serguei.
>
> > Personally, I find the current syntax much clearer and readable
> > (defining anything by convention like . being the function variable
> > seems arbitrary and "dirty" to me), but if you wanted to define a
> > shorter syntax, you could use something like x ~> i + x. That said, I
> > really don't see the value of not using function(x) [especially these
> > days when people are arguing for long variable names with the
> > justification that IDEs do all the work anyway], but as I said, my
> > argument was against the actual proposal, not general ideas about
> > syntax improvement. Cheers, Simon
> >> On 17/04/2020, at 3:53 AM, Sokol Serguei
> >> wrote: Simon, Thanks for replying. In what follows I won't try to
> >> argue (I understood that you find this a bad idea) but I would like
> >> to make clearer some of your point for me (and may be for others). Le
> >> 16/04/2020 à 16:48, Simon Urbanek a écrit :
> >>> Serguei,
> On 17/04/2020, at 2:24 AM, Sokol Serguei
> wrote: Hi, I would like to make a suggestion for a small syntactic
> modification of FUN argument in the family of functions
> [lsv]apply(). The idea is to allow one-liner expressions without
> typing "function(item) {...}" to surround them. The argument to the
> anonymous function is simply referred as ".". Let take an example.
> With this new feature, the following call sapply(split(mtcars,
> mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared) # 4 6
> 8 #0.5086326 0.4645102 0.4229655 could be rewritten as
> sapply(split(mtcars, mtcars$cyl), summary(lm(mpg ~ wt,
> .))$r.squared) "Not a big saving in typing" you can say but
> multiplied by the number of [lsv]apply usage and a neater look, I
> think, the idea merits to be considered.
> >>> It's not in any way "neater", not only is it less readable, it's
> >>> just plain wrong. What if the expression returned a function?
> >> do you mean like in l=sapply(1:3, function(i) function(x) i+x)
> >> l[[1]](3) # 4 l[[2]](3) # 5 This is indeed a corner case but a pair
> >> of () or {} can keep wsapply() in course: l=wsapply(1:3, (function(x)
> >> .+x)) l[[1]](3) # 4 l[[2]](3) # 5
> >>> How do you know that you don't want to apply the result of the call?
> >> A small example (if it is significantly different from the one above)
> >> would be very helpful for me to understand this point.
> >>> For the same reason the implementation below won't work - very often
> >>> you just pass a symbol that evaluates to a function and always en
> >>> expression that returns a function and there is no way to
> >>> distinguish that from your new proposed syntax.
> >> Even with () or {} around such "dotted" expression? Best, Serguei.
> >>> When you feel compelled to use substitute() you should hear alarm
> >>> bells that something is wrong ;). You can certainly write a new
> >>> function that uses a different syntax (and I'm sure someone has
> >>> already done that in the package space), but what you propose is
> >>> incompatible with *apply in R (and very much not R syntax). Cheers,
> >>> Simon
> To illustrate a possible implementation, I propose a wrapper
> example for sapply(): wsapply=function(l, fun, ...) {
> s=substitute(fun) if (is.name(s) || is.call(s) &&
> s[[1]]==as.name("function")) { sapply(l, fun, ...) # legacy call }
> else { sapply(l, function(d) eval(s, list(.=d)), ...) } } Now, we
> can do: wsapply(split(mtcars, mtcars$cyl), summary(lm(mpg ~ wt,
> .))$r.squared) or, traditional way: wsapply(split(mtcars,
> mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared
Re: [Rd] New matrix function
The link you posted used the same inputs as in my example. If that is not what you meant maybe a different example is needed. Regards. On Fri, Oct 11, 2019 at 2:39 PM Pages, Herve wrote: > > Has someone looked into the image processing area for this? That sounds > a little bit too high-level for base R to me (and I would be surprised > if any mainstream programming language had this kind of functionality > built-in). > > H. > > On 10/11/19 03:44, Morgan Morgan wrote: > > Hi All, > > > > I was looking for a function to find a small matrix inside a larger matrix > > in R similar to the one described in the following link: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mathworks.com_matlabcentral_answers_194708-2Dindex-2Da-2Dsmall-2Dmatrix-2Din-2Da-2Dlarger-2Dmatrix&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=v96tqHMO3CLNBS7KTmdshM371i6W_v8_2H5bdVy_KHo&s=9Eu0WySIEzrWuYXFhwhHETpZQzi6hHLd84DZsbZsXYY&e= > > > > I couldn't find anything. > > > > The above function can be seen as a "generalisation" of the "which" > > function as well as the function described in the following post: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__coolbutuseless.github.io_2018_04_03_finding-2Da-2Dlength-2Dn-2Dneedle-2Din-2Da-2Dhaystack_&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=v96tqHMO3CLNBS7KTmdshM371i6W_v8_2H5bdVy_KHo&s=qZ3SJ8t8zEDA-em4WT7gBmN66qvvCKKKXRJunoF6P3k&e= > > > > Would be possible to add such a function to base R? > > > > I am happy to work with someone from the R core team (if you wish) and > > suggest an implementation in C. > > > > Thank you > > Best regards, > > Morgan > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=v96tqHMO3CLNBS7KTmdshM371i6W_v8_2H5bdVy_KHo&s=tyVSs9EYVBd_dmVm1LSC23GhUzbBv8ULvtsveo-COoU&e= > > > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New matrix function
I pressed return too soon. If we had such a multiply then which(embed(A, x) %==.&% reverse(x)) On Fri, Oct 11, 2019 at 10:57 AM Gabor Grothendieck wrote: > > Also note that the functionality discussed could be regarded as a > generalization > of matrix multiplication where * and + are general functions and in this case > we have * replaced by == and + replaced by &. > > On Fri, Oct 11, 2019 at 10:46 AM Gabor Grothendieck > wrote: > > > > Using the example in the link here are two one-liners: > > > > A <- c(2,3,4,1,2,3,4,1,1,2) > > x <- c(1,2) > > > > # 1 - zoo > > library(zoo) > > which( rollapply(A, length(x), identical, x, fill = FALSE, align = > > "left") ) > > ## [1] 4 9 > > > > # 2 - Base R using conversion to character > > gregexpr(paste(x, collapse = ""), paste(A, collapse = ""))[[1]] > > ## [1] 4 9 > > ...snip ... > > > > On Fri, Oct 11, 2019 at 3:45 AM Morgan Morgan > > wrote: > > > > > > Hi All, > > > > > > I was looking for a function to find a small matrix inside a larger matrix > > > in R similar to the one described in the following link: > > > > > > https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix > > > > > > I couldn't find anything. > > > > > > The above function can be seen as a "generalisation" of the "which" > > > function as well as the function described in the following post: > > > > > > https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/ > > > > > > Would be possible to add such a function to base R? > > > > > > I am happy to work with someone from the R core team (if you wish) and > > > suggest an implementation in C. > > > > > > Thank you > > > Best regards, > > > Morgan > > > > > > [[alternative HTML version deleted]] > > > > > > __ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > -- > > Statistics & Software Consulting > > GKX Group, GKX Associates Inc. > > tel: 1-877-GKX-GROUP > > email: ggrothendieck at gmail.com > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New matrix function
Also note that the functionality discussed could be regarded as a generalization of matrix multiplication where * and + are general functions and in this case we have * replaced by == and + replaced by &. On Fri, Oct 11, 2019 at 10:46 AM Gabor Grothendieck wrote: > > Using the example in the link here are two one-liners: > > A <- c(2,3,4,1,2,3,4,1,1,2) > x <- c(1,2) > > # 1 - zoo > library(zoo) > which( rollapply(A, length(x), identical, x, fill = FALSE, align = "left") ) > ## [1] 4 9 > > # 2 - Base R using conversion to character > gregexpr(paste(x, collapse = ""), paste(A, collapse = ""))[[1]] > ## [1] 4 9 > ...snip ... > > On Fri, Oct 11, 2019 at 3:45 AM Morgan Morgan > wrote: > > > > Hi All, > > > > I was looking for a function to find a small matrix inside a larger matrix > > in R similar to the one described in the following link: > > > > https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix > > > > I couldn't find anything. > > > > The above function can be seen as a "generalisation" of the "which" > > function as well as the function described in the following post: > > > > https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/ > > > > Would be possible to add such a function to base R? > > > > I am happy to work with someone from the R core team (if you wish) and > > suggest an implementation in C. > > > > Thank you > > Best regards, > > Morgan > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New matrix function
Using the example in the link here are two one-liners: A <- c(2,3,4,1,2,3,4,1,1,2) x <- c(1,2) # 1 - zoo library(zoo) which( rollapply(A, length(x), identical, x, fill = FALSE, align = "left") ) ## [1] 4 9 # 2 - Base R using conversion to character gregexpr(paste(x, collapse = ""), paste(A, collapse = ""))[[1]] ## [1] 4 9 ...snip ... On Fri, Oct 11, 2019 at 3:45 AM Morgan Morgan wrote: > > Hi All, > > I was looking for a function to find a small matrix inside a larger matrix > in R similar to the one described in the following link: > > https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix > > I couldn't find anything. > > The above function can be seen as a "generalisation" of the "which" > function as well as the function described in the following post: > > https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/ > > Would be possible to add such a function to base R? > > I am happy to work with someone from the R core team (if you wish) and > suggest an implementation in C. > > Thank you > Best regards, > Morgan > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recall
Please ignore. Looking at this again I realize the problem is that
Recall is not direclty within my.compose2 but rather is within the
anonymous function in the else.
On Sun, Sep 23, 2018 at 9:23 AM Gabor Grothendieck
wrote:
>
> This works:
>
> my.compose <- function(f, ...) {
> if (missing(f)) identity
> else function(x) f(my.compose(...)(x))
> }
>
> my.compose(sin, cos, tan)(pi/4)
> ## [1] 0.5143953
>
> sin(cos(tan(pi/4)))
> ## [1] 0.5143953
>
> But replacing my.compose with Recall in the else causes it to fail:
>
> my.compose2 <- function(f, ...) {
> if (missing(f)) identity
> else function(x) f(Recall(...)(x))
> }
>
> my.compose2(sin, cos, tan)(pi/4)
> ## Error in my.compose2(sin, cos, tan)(pi/4) : unused argument (tan)
>
> Seems like a bug in R.
>
> This is taken from:
> https://stackoverflow.com/questions/52463170/a-recursive-compose-function-in-r
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Recall
This works:
my.compose <- function(f, ...) {
if (missing(f)) identity
else function(x) f(my.compose(...)(x))
}
my.compose(sin, cos, tan)(pi/4)
## [1] 0.5143953
sin(cos(tan(pi/4)))
## [1] 0.5143953
But replacing my.compose with Recall in the else causes it to fail:
my.compose2 <- function(f, ...) {
if (missing(f)) identity
else function(x) f(Recall(...)(x))
}
my.compose2(sin, cos, tan)(pi/4)
## Error in my.compose2(sin, cos, tan)(pi/4) : unused argument (tan)
Seems like a bug in R.
This is taken from:
https://stackoverflow.com/questions/52463170/a-recursive-compose-function-in-r
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply with zero-row matrix
Try pmap and related functions in purrr:
pmap(as.data.frame(m), ~ { cat("Called...\n"); print(c(...)) })
## list()
On Mon, Jul 30, 2018 at 12:33 AM, David Hugh-Jones
wrote:
> Forgive me if this has been asked many times before, but I couldn't find
> anything on the mailing lists.
>
> I'd expect apply(m, 1, foo) not to call `foo` if m is a matrix with zero
> rows.
> In fact:
>
> m <- matrix(NA, 0, 5)
> apply(m, 1, function (x) {cat("Called...\n"); print(x)})
> ## Called...
> ## [1] FALSE FALSE FALSE FALSE FALSE
>
> Similarly for apply(m, 2,...) if m has no columns.
> Is there a reason for this? Could it be documented?
>
> David
> --
> Sent from Gmail Mobile
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] odd behavior of names
The first component name has backticks around it and the second does not. Though not wrong, it seems inconsistent. list(a = 1, b = 2) ## $`a` ## [1] 1 ## ## $b ## [1] 2 R.version.string ## [1] "R version 3.5.1 Patched (2018-07-02 r74950)" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] oddity in transform
The idea is that one wants to write the line of code below in a general way which works the same whether you specify ix as one column or multiple columns but the naming entirely changes when you do this and BOD[, 1] and transform(BOD, X=..., Y=...) or other hard coding solutions still require writing multiple cases. ix <- 1:2 transform(BOD, X = BOD[ix] * seq(6)) On Tue, Jul 24, 2018 at 7:14 AM, Emil Bode wrote: > I think you meant to call BOD[,1] > From ?transform, the ... arguments are supposed to be vectors, and BOD[1] is > still a data.frame (with one column). So I don't think it's surprising > transform gets confused by which name to use (X, or Time?), and kind of > compromises on the name "Time". It's also in a note in ?transform: "If some > of the values are not vectors of the appropriate length, you deserve whatever > you get!" > And if you want to do it with multiple extra columns (and are not satisfied > with these labels), I think the proper way to go would be " transform(BOD, > X=BOD[,1]*seq(6), Y=BOD[,2]*seq(6))" > > If you want to trace it back further, it's not in transform but in > data.frame. Column-names are prepended with a higher-level name if the object > has more than one column. > And it uses the tag-name if simply supplied with a vector: > data.frame(BOD[1:2], X=BOD[1]*seq(6)) takes the name of the only column of > BOD[1], Time. Only because that column name is already present, it's changed > to Time.1 > data.frame(BOD[1:2], X=BOD[,1]*seq(6)) gives third column-name X (as X is now > a vector) > data.frame(BOD[1:2], X=BOD[1:2]*seq(6)) or with BOD[,1:2] gives columns names > X.Time and X.demand, to show these (multiple) columns are coming from X > > So I don't think there's much to fix here. I this case having X.Time in all > cases would have been better, but in general the column-naming of data.frame > works, changing it would likely cause a lot of problems. > You can always change the column-names later. > > Best regards, > Emil Bode > > Data-analyst > > +31 6 43 83 89 33 > emil.b...@dans.knaw.nl > > DANS: Netherlands Institute for Permanent Access to Digital Research Resources > Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | > i...@dans.knaw.nl <mailto:i...@dans.kn> | dans.knaw.nl > > DANS is an institute of the Dutch Academy KNAW <http://knaw.nl/nl> and > funding organisation NWO <http://www.nwo.nl/>. > > On 23/07/2018, 16:52, "R-devel on behalf of Gabor Grothendieck" > wrote: > > Note the inconsistency in the names in these two examples. X.Time in > the first case and Time.1 in the second case. > > > transform(BOD, X = BOD[1:2] * seq(6)) > Time demand X.Time X.demand > 118.3 1 8.3 > 22 10.3 4 20.6 > 33 19.0 9 57.0 > 44 16.0 16 64.0 > 55 15.6 25 78.0 > 67 19.8 42118.8 > > > transform(BOD, X = BOD[1] * seq(6)) > Time demand Time.1 > 118.3 1 > 22 10.3 4 > 33 19.0 9 > 44 16.0 16 > 55 15.6 25 > 67 19.8 42 > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] oddity in transform
Note the inconsistency in the names in these two examples. X.Time in the first case and Time.1 in the second case. > transform(BOD, X = BOD[1:2] * seq(6)) Time demand X.Time X.demand 118.3 1 8.3 22 10.3 4 20.6 33 19.0 9 57.0 44 16.0 16 64.0 55 15.6 25 78.0 67 19.8 42118.8 > transform(BOD, X = BOD[1] * seq(6)) Time demand Time.1 118.3 1 22 10.3 4 33 19.0 9 44 16.0 16 55 15.6 25 67 19.8 42 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Setting the path to Rtools for package compilation on Windows
If there is work going on to improve Rtools 1. one of the most annoying aspects of it is that it does not play nice with builtin Windows commands. In particular, it defines a command called find which works like UNIX find but it masks Windows find if you add the Rtools folders to your PATH making it quite dangerous to do so. 2. Another annoyance is that what to put on the PATH can change from one Rtools version to another and it is not straight forward to discover that automatically. One can extract it from the unins000.dat (and I have done that) but it is not straight forward. 3. Ideally it would be nice if it were as easy to install Rtools as installing an R package. In fact, maybe Rtools could be an R package or maybe it could be part of the R installation process itself. On Wed, Feb 14, 2018 at 7:32 AM, Jeroen Ooms wrote: > On Tue, Feb 13, 2018 at 7:58 PM, Peter Langfelder > wrote: >> On Tue, Feb 13, 2018 at 2:20 AM, Jeroen Ooms wrote: >> >>> Thanks for your question. Your logs show that 'gcc' is not found. As >>> of R 3.3 you need to set the path to the compiler using the BINPREF >>> variable. This is because we ship two separate versions of gcc, one >>> targeting win32 and one targeting win64. I am not sure what your >>> rtools installation looks like, but could you try setting this >>> environment variable: >>> >>> BINPREF="M:/R/Rtools-3.4/mingw_$(WIN)/bin/" >>> >>> I think this will do the job. >> >> Thanks, that indeed did the trick. May I suggest that this hint be >> also included in "REMAINING TASKS" section of the file Rtools.txt that >> is part of the Rtools distribution? The R installation manual does >> mention BINPREF and BINPREF64 but I missed that part... > > Glad it worked. Actually BINPREF64 only exists when building R itself. > For the R user there is no BINPREF64. There is only BINPREF which has > to point to a 32bit gcc when R runs in 32bit, and a 64bit compiler > when R runs in 64bit. But if you compile R packages you need both at > the same time. Hence the "$(WIN)" variable in the BINPREF above. > > Yes the rtools setup is a bit convoluted, and we're currently > discussing ways to improve this. Thanks for your suggestion. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A few suggestions and perspectives from a PhD student
Regarding the anonymous-function-in-a-pipeline point one can already
do this which does use brackets but even so it involves fewer
characters than the example shown. Here { . * 2 } is basically a
lambda whose argument is dot. Would this be sufficient?
library(magrittr)
1.5 %>% { . * 2 }
## [1] 3
Regarding currying note that with magrittr Ista's code could be written as:
1:5 %>% lapply(foo, y = 3)
or at the expense of slightly more verbosity:
1:5 %>% Map(f = . %>% foo(y = 3))
On Fri, May 5, 2017 at 1:00 PM, Antonin Klima wrote:
> Dear Sir or Madam,
>
> I am in 2nd year of my PhD in bioinformatics, after taking my Master’s in
> computer science, and have been using R heavily during my PhD. As such, I
> have put together a list of certain features in R that, in my opinion, would
> be beneficial to add, or could be improved. The first two are already
> implemented in packages, but given that it is implemented as user-defined
> operators, it greatly restricts its usefulness. I hope you will find my
> suggestions interesting. If you find time, I will welcome any feedback as to
> whether you find the suggestions useful, or why you do not think they should
> be implemented. I will also welcome if you enlighten me with any features I
> might be unaware of, that might solve the issues I have pointed out below.
>
> 1) piping
> Currently available in package magrittr, piping makes the code better
> readable by having the line start at its natural starting point, and
> following with functions that are applied - in order. The readability of
> several nested calls with a number of parameters each is almost zero, it’s
> almost as if one would need to come up with the solution himself. Pipeline in
> comparison is very straightforward, especially together with the point (2).
>
> The package here works rather good nevertheless, the shortcomings of piping
> not being native are not quite as severe as in point (2). Nevertheless, an
> intuitive symbol such as | would be helpful, and it sometimes bothers me that
> I have to parenthesize anonymous function, which would probably not be
> required in a native pipe-operator, much like it is not required in f.ex.
> lapply. That is,
> 1:5 %>% function(x) x+2
> should be totally fine
>
> 2) currying
> Currently available in package Curry. The idea is that, having a function
> such as foo = function(x, y) x+y, one would like to write for example
> lapply(foo(3), 1:5), and have the interpreter figure out ok, foo(3) does not
> make a value result, but it can still give a function result - a function of
> y. This would be indeed most useful for various apply functions, rather than
> writing function(x) foo(3,x).
>
> I suggest that currying would make the code easier to write, and more
> readable, especially when using apply functions. One might imagine that there
> could be some confusion with such a feature, especially from people
> unfamiliar with functional programming, although R already does take function
> as first-order arguments, so it could be just fine. But one could address it
> with special syntax, such as $foo(3) [$foo(x=3)] for partial application.
> The current currying package has very limited usefulness, as, being limited
> by the user-defined operator framework, it only rarely can contribute to less
> code/more readability. Compare yourself:
> $foo(x=3) vs foo %<% 3
> goo = function(a,b,c)
> $goo(b=3) vs goo %><% list(b=3)
>
> Moreover, one would often like currying to have highest priority. For
> example, when piping:
> data %>% foo %>% foo1 %<% 3
> if one wants to do data %>% foo %>% $foo(x=3)
>
> 3) Code executable only when running the script itself
> Whereas the first two suggestions are somewhat stealing from Haskell and the
> like, this suggestion would be stealing from Python. I’m building quite a
> complicated pipeline, using S4 classes. After defining the class and its
> methods, I also define how to build the class to my likings, based on my
> input data, using various now-defined methods. So I end up having a list of
> command line arguments to process, and the way to create the class instance
> based on them. If I write it to the class file, however, I end up running the
> code when it is sourced from the next step in the pipeline, that needs the
> previous class definitions.
>
> A feature such as pythonic “if __name__ == __main__” would thus be useful. As
> it is, I had to create run scripts as separate files. Which is actually not
> so terrible, given the class and its methods often span a few hundred lines,
> but still.
>
> 4) non-exported global variables
> I also find it lacking, that I seem to be unable to create constants that
> would not get passed to files that source the class definition. That is, if
> class1 features global constant CONSTANT=3, then if class2 sources class1, it
> will also include the constant. This 1) clutters the namespace when running
> the code interactively,
Re: [Rd] RFC: tapply(*, ..., init.value = NA)
If xtabs is enhanced then as.data.frame.table may also need to be
modified so that it continues to be usable as an inverse, at least to
the degree feasible.
On Thu, Jan 26, 2017 at 5:42 AM, Martin Maechler
wrote:
> Last week, we've talked here about "xtabs(), factors and NAs",
> -> https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html
>
> In the mean time, I've spent several hours on the issue
> and also committed changes to R-devel "in two iterations".
>
> In the case there is a *Left* hand side part to xtabs() formula,
> see the help page example using 'esoph',
> it uses tapply(..., FUN = sum) and
> I now think there is a missing feature in tapply() there, which
> I am proposing to change.
>
> Look at a small example:
>
>> D2 <- data.frame(n = gl(3,4), L = gl(6,2, labels=LETTERS[1:6]),
>> N=3)[-c(1,5), ]; xtabs(~., D2)
> , , N = 3
>
>L
> n A B C D E F
> 1 1 2 0 0 0 0
> 2 0 0 1 2 0 0
> 3 0 0 0 0 2 2
>
>> DN <- D2; DN[1,"N"] <- NA; DN
>n L N
> 2 1 A NA
> 3 1 B 3
> 4 1 B 3
> 6 2 C 3
> 7 2 D 3
> 8 2 D 3
> 9 3 E 3
> 10 3 E 3
> 11 3 F 3
> 12 3 F 3
>> with(DN, tapply(N, list(n,L), FUN=sum))
>A B C D E F
> 1 NA 6 NA NA NA NA
> 2 NA NA 3 6 NA NA
> 3 NA NA NA NA 6 6
>>
>
> and as you can see, the resulting matrix has NAs, all the same
> NA_real_, but semantically of two different kinds:
>
> 1) at ["1", "A"], the NA comes from the NA in 'N'
> 2) all other NAs come from the fact that there is no such factor combination
>*and* from the fact that tapply() uses
>
>array(dim = .., dimnames = ...)
>
> i.e., initializes the array with NAs (see definition of 'array').
>
> My proposition is the following patch to tapply(), adding a new
> option 'init.value':
>
> -
>
> -tapply <- function (X, INDEX, FUN = NULL, ..., simplify = TRUE)
> +tapply <- function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify =
> TRUE)
> {
> FUN <- if (!is.null(FUN)) match.fun(FUN)
> if (!is.list(INDEX)) INDEX <- list(INDEX)
> @@ -44,7 +44,7 @@
> index <- as.logical(lengths(ans)) # equivalently, lengths(ans) > 0L
> ans <- lapply(X = ans[index], FUN = FUN, ...)
> if (simplify && all(lengths(ans) == 1L)) {
> - ansmat <- array(dim = extent, dimnames = namelist)
> + ansmat <- array(init.value, dim = extent, dimnames = namelist)
> ans <- unlist(ans, recursive = FALSE)
> } else {
> ansmat <- array(vector("list", prod(extent)),
>
> -
>
> With that, I can set the initial value to '0' instead of array's
> default of NA :
>
>> with(DN, tapply(N, list(n,L), FUN=sum, init.value=0))
>A B C D E F
> 1 NA 6 0 0 0 0
> 2 0 0 3 6 0 0
> 3 0 0 0 0 6 6
>>
>
> which now has 0 counts and NA as is desirable to be used inside
> xtabs().
>
> All fine... and would not be worth a posting to R-devel,
> except for this:
>
> The change will not be 100% back compatible -- by necessity: any new argument
> for
> tapply() will make that argument name not available to be
> specified (via '...') for 'FUN'. The new function would be
>
>> str(tapply)
> function (X, INDEX, FUN = NULL, ..., init.value = NA, simplify = TRUE)
>
> where the '...' are passed FUN(), and with the new signature,
> 'init.value' then won't be passed to FUN "anymore" (compared to
> R <= 3.3.x).
>
> For that reason, we could use 'INIT.VALUE' instead (possibly decreasing
> the probability the arg name is used in other functions).
>
>
> Opinions?
>
> Thank you in advance,
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] On implementing zero-overhead code reuse
Have a look at the CRAN modules package and the import package.
On Sun, Oct 2, 2016 at 1:29 PM, Kynn Jones wrote:
> I'm looking for a way to approximate the "zero-overhead" model of code
> reuse available in languages like Python, Perl, etc.
>
> I've described this idea in more detail, and the motivation for this
> question in an earlier post to R-help
> (https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).
>
> (One of the responses I got advised that I post my question here instead.)
>
> The best I have so far is to configure my PROJ_R_LIB environment
> variable to point to the directory with my shared code, and put a
> function like the following in my .Rprofile file:
>
> import <- function(name){
> ## usage:
> ## import("foo")
> ## foo$bar()
> path <- file.path(Sys.getenv("PROJ_R_LIB"),paste0(name,".R"))
> if(!file.exists(path)) stop('file "',path,'" does not exist')
> mod <- new.env()
> source(path,local=mod)
> list2env(setNames(list(mod),list(name)),envir=parent.frame())
> invisible()
> }
>
> (NB: the idea above is an elaboration of the one I showed in my first post.)
>
> But this is very much of an R noob's solution. I figure there may
> already be more solid ways to achieve "zero-overhead" code reuse.
>
> I would appreciate any suggestions/critiques/pointers/comments.
>
> TIA!
>
> kj
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strcapture enhancement
Note that read.pattern in gsubfn does accept stringsAsFactors = FALSE,
e.g. using your input lines and pattern:
library(gsubfn)
Lines <- c("Three 3", "Twenty 20")
pat <- "([[:alpha:]]*) +([[:digit:]]*)"
s2 <- read.pattern(text = Lines, pattern = pat, stringsAsFactors = FALSE,
col.names = c("Name", "Number"))
giving:
> str(s2)
'data.frame': 2 obs. of 2 variables:
$ Name : chr "Three" "Twenty"
$ Number: int 3 20
On Wed, Sep 21, 2016 at 2:06 PM, William Dunlap via R-devel
wrote:
> The new strcapture function in R-devel is handy, capturing
> the matches to the parenthesized subpatterns in a regular
> expression in the columns of a data.frame, whose column
> names and classes are given by the 'proto' argument. E.g.,
>
>> p1 <- data.frame(Name="", Number=0)
>> str(strcapture("([[:alpha:]]*) +([[:digit:]]*)", c("Three 3", "Twenty
> 20"), proto=p1))
> 'data.frame': 2 obs. of 2 variables:
> $ Name : Factor w/ 2 levels "Three","Twenty": 1 2
> $ Number: num 3 20
>
> I think it would be even nicer if it constructed its data.frame
> using the check.names=FALSE and stringsAsFactors=FALSE
> arguments. Then the names and types specified in the proto
> argument would be respected instead of changing them as
> in the following example
>
>> p2 <- data.frame("The Name"="", "The Number"=0, stringsAsFactors=FALSE,
> check.names=FALSE)
>> str(strcapture("([[:alpha:]]*) +([[:digit:]]*)", c("Three 3", "Twenty
> 20"), proto=p2))
> 'data.frame': 2 obs. of 2 variables:
> $ The.Name : Factor w/ 2 levels "Three","Twenty": 1 2
> $ The.Number: num 3 20
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stack problem
One would normally want the original order that so that one can stack a list, operate on the result and then unstack it back with the unstacked result having the same ordering as the original. LL <- list(z = 1:3, a = list()) # since we can't do s <- stack(LL,. drop = FALSE) do this instead: s <- transform(stack(LL), ind = factor(as.character(ind), levels = names(LL))) unstack(s) On Mon, Jun 27, 2016 at 2:55 PM, Michael Lawrence wrote: > I'll add the drop argument but I'm wondering about the order of the > levels. Should we set the levels to unique(names(x)) or sort them, > too? > > On Mon, Jun 27, 2016 at 10:39 AM, Gabor Grothendieck > wrote: >> stack() seems to drop empty levels. Perhaps there could be a >> drop=FALSE argument if one wanted all the original levels. In the >> example below, we may wish to retain level "b" in s$ind even though >> component LL$b has length 0. >> >>> LL <- list(a = 1:3, b = list()) >>> s <- stack(LL) >>> str(s) >> 'data.frame': 3 obs. of 2 variables: >> $ values: int 1 2 3 >> $ ind : Factor w/ 1 level "a": 1 1 1 >> >> >> -- >> Statistics & Software Consulting >> GKX Group, GKX Associates Inc. >> tel: 1-877-GKX-GROUP >> email: ggrothendieck at gmail.com >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stack problem
stack() seems to drop empty levels. Perhaps there could be a drop=FALSE argument if one wanted all the original levels. In the example below, we may wish to retain level "b" in s$ind even though component LL$b has length 0. > LL <- list(a = 1:3, b = list()) > s <- stack(LL) > str(s) 'data.frame': 3 obs. of 2 variables: $ values: int 1 2 3 $ ind : Factor w/ 1 level "a": 1 1 1 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ctrl-R in Rgui
When in the Rgui editor sometimes ctrl-R does not cause anything to be sent to the R console. It can be reproduced like this: - when in the Rgui console press ctrl-F N to get a new editor window - enter: pi + 3 followed by Enter - while still in the editor window press ctrl-A ctrl-R and pi + 3 gets entered into the console and runs as expected - while still in the editor window press ctrl-A ctrl-R again In the last case nothing happens whereas one would have expected it to be entered into the console again and run again. I am using [1] "R version 3.3.0 Patched (2016-05-03 r70575)" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] for in r-devel
Regarding, this news item for r-devel: ‘for()’ loops are generalized to iterate over any object with ‘[[’ and ‘length()’ methods. Thanks to Hervé Pagès for the idea and the patch. Below dd is an object for which [[ and length work but the result is still numeric rather than Date class in "R Under development (unstable) (2016-03-15 r70334)" as observed in the comments to: http://stackoverflow.com/questions/36074344/why-does-for-convert-date-to-numeric#comment59794873_36074344 Expanding on that: dd <- Sys.Date() + 0:1 dd[[1]] # [[ works ## [1] "2016-03-18" length(dd) # length works ## [1] 2 for(d in dd) str(d) # gives numeric rather than Date class ## num 16878 ## num 16879 -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled by eval
This code which I think I wrote but might have gotten from elsewhere a
long time ago shows the environments that are searched from a given
function, in this case chart.RelativePerformance in
PerformanceAnalytics package. Try it on some of your functions in
and out of packages to help determine the sequence of environments R
searches along:
library( PerformanceAnalytics ) ## change as needed
x <- environment(chart.RelativePerformance) ## change as needed
str(x)
while (!identical(x, emptyenv())) {
p <- parent.env(x)
cat(" child is above this line and parent is below \n")
str(p)
if (isBaseNamespace(p)) cat("Same as .BaseNamespaceEnv\n")
if (identical(p, baseenv())) cat("Same as baseenv()\n")
if (identical(p, emptyenv())) cat("Same as emptyenv()\n")
if (identical(p, globalenv())) cat("Same as globalenv()\n")
x <- p
}
On Fri, Nov 6, 2015 at 9:47 AM, Duncan Murdoch wrote:
> On 06/11/2015 8:20 AM, Therneau, Terry M., Ph.D. wrote:
>>
>> Duncan,
>> That's helpful. Two follow-up questions:
>> 1. Where would I have found this information? I had looked at eval and
>> model.frame.
>
>
> I think the best description is Luke's article on namespaces, "Name space
> management for R". Luke Tierney, R News, 3(1):2-6, June 2003. There's a link
> to it from the "Technical papers" section of the HTML help index. There's
> also a short description of this in the R Language Definition manual in the
> "Search path" section 3.5.4.
>
>
>> 2. What stops the following code from falling down the same rabbit hole?
>> Shouldn't it
>> find base::cos first?
>>
>> library(survival)
>> cos <- lung
>> coxph(Surv(time, status) ~ age, data=cos)
>
>
> If that code is in a function anywhere (package or not), cos will be a local
> variable created there in the evaluation environment created when you
> evaluate the function. If you execute it at the command line, you'll create
> a variable called "cos" in the global environment. Local variables come
> ahead of the 3 places I listed. (This is why Luke's article is good: it
> doesn't oversimplify.)
>
> There's one other twist. Even with cos being a local variable, cos(theta)
> would find base::cos, because the evaluator knows it is looking for a
> function (since it's a function call) and will skip over the local dataframe
> named cos.
>
> Duncan Murdoch
>
>>
>> Terry T.
>>
>>
>> On 11/06/2015 07:51 AM, Duncan Murdoch wrote:
>>>
>>> On 06/11/2015 7:36 AM, Therneau, Terry M., Ph.D. wrote:
I am currently puzzled by a seach path behavior. I have a library of a
dozen routines
getlabs(), getssn(), getecg(), ... that interface to local repositories
and pull back
patient information. All have a the first 6 arguments in common, and
immediately call a
second routine to do initial processing of these 6. The functions "joe"
and "fred" below
capture the relevant portion of them.
My puzzle is this: the last test in the "test" file works fine if
these routines are
sourced and executed at the command line, it fails if the routines are
bundled up and
loaded as a library. That test is motivated by a user who called his
data set "t", and
ended up with a match to base:::t instead of his data, resulting in a
strange error
message out of model.frame --- you can always count on the users!
(There are a few
hundred.)
I'm attempting to be careful with envr and enclos arguments -- how
does base end up
earlier in the search path? Perhaps this is clearly stated in the docs
and just not
clear to me? A working solution to the dilemma is of course more than
welcome.
>>>
>>>
>>> I haven't followed through all the details in fred(), but I can answer
>>> the last question.
>>> In package code, the search order is:
>>>
>>> - the package environment
>>> - the imports to the package (with base being an implicit import)
>>> - the global environment and the rest of the search list.
>>>
>>> In code sourced to the global environment, only the third of these is
>>> searched. Since
>>> base is in the second one, it is found first in the package version.
>>>
>>> Duncan Murdoch
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] returnValue()
Please disregard. I was running an older version of R at the time. In R version 3.2.0 Patched (2015-04-19 r68205) returnValue() does work. On Fri, May 22, 2015 at 6:25 PM, Gabor Grothendieck wrote: > In R devel rev.66393 (2014-08-15) it was possible to do this: > >trace(optim, exit = quote(str(returnValue( > > but returnValue() does not seem to be available any more. The above > was useful to get the output of a function when it was called deep > within another function that I have no control over. > > Has this been replaced by some other equivalent function? > > P.S. This demonstrates that it no longer works. The error message is > that it cannot find function 'returnValue`: > >> trace(optim, exit = quote(str(returnValue( > Tracing function "optim" in package "stats" > [1] "optim" >> arima(presidents, order = c(1, 0, 0)) > Tracing optim(init[mask], armafn, method = optim.method, hessian = > TRUE, on exit > Error in str(returnValue()) : could not find function "returnValue" > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] returnValue()
In R devel rev.66393 (2014-08-15) it was possible to do this: trace(optim, exit = quote(str(returnValue( but returnValue() does not seem to be available any more. The above was useful to get the output of a function when it was called deep within another function that I have no control over. Has this been replaced by some other equivalent function? P.S. This demonstrates that it no longer works. The error message is that it cannot find function 'returnValue`: > trace(optim, exit = quote(str(returnValue( Tracing function "optim" in package "stats" [1] "optim" > arima(presidents, order = c(1, 0, 0)) Tracing optim(init[mask], armafn, method = optim.method, hessian = TRUE, on exit Error in str(returnValue()) : could not find function "returnValue" -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xtabs and NA
On Mon, Feb 9, 2015 at 8:52 AM, Kirill Müller
wrote:
> Hi
>
>
> I haven't found a way to produce a tabulation from factor data with NA
> values using xtabs. Please find a minimal example below, it's also on R-pubs
> [1]. Tested with R 3.1.2 and R-devel r67720.
>
> It doesn't seem to be documented explicitly that it's not supported. From
> reading the code [2] it looks like the relevant call to table() doesn't set
> the "useNA" parameter, which I think is necessary to make NAs show up in the
> result.
>
> Am I missing anything? If this a bug -- would a patch be welcome? Do we need
> compatibility with the current behavior?
>
> I'm aware of workarounds, I just prefer xtabs() over table() for its
> interface.
>
Passing table the output of model.frame would still allow the use of a
formula interface:
> mf <- model.frame( ~ data, na.action = na.pass)
> do.call("table", c(mf, useNA = "ifany"))
abc
1111
--
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN and ggplot2 geom and stat extensions
On Tue, Dec 23, 2014 at 11:21 AM, Ista Zahn wrote: > On Tue, Dec 23, 2014 at 10:34 AM, Frank Harrell > wrote: >> I am thinking about adding several geom and stat extensions to ggplot2 >> in the Hmisc package. To do this requires using non-exported ggplot2 >> functions as discussed in >> http://stackoverflow.com/questions/18108406/creating-a-custom-stat-object-in-ggplot2 >> >> If I use the needed ggplot2::: notation the package will no longer pass >> CRAN checks. Does anyone know of a solution? > > the ggthemes package is on CRAN and uses ggplot2::: so it is at least > possible that this will be allowed for Hmisc as well. > Packages ggmap, ggtern and ggsubplot also define their own geom's and/or stat's. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 8:43 PM, Gábor Csárdi wrote: > On Fri, Oct 31, 2014 at 8:10 PM, Gabor Grothendieck > wrote: > [...] >>> Is there a better way? I have a feeling that this is already supported >>> somehow, I just can't find out how. >>> >> >> Try the settings package. > > I could, but I don't see how it would solve my problem. > https://github.com/markvanderloo/settings/issues/1 Isn't your problem really just that you want multiple sets of settings? That's what settings provides. pkgA would provide a class whose instances are created by the clients. Assuming you wrap this in a function create: inst1 <- create(a = 1, b = 2) where create sets up a settings object and does anything else returning the handle inst1. When you want to do something you would pass the instance to the function or method that actually carries it out. This could be done with any OO system in R without settings but if you are looking for an options type interface which I thought you were then you might be able to leverage that package. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 7:34 PM, Gábor Csárdi wrote: > Dear All, > > I am trying to do the following, and could use some hints. > > Suppose I have a package called pkgA. pkgA exposes an API that > includes setting some options, e.g. pkgA works with color palettes, > and the user of the package can define new palettes. pkgA provides an > API to manipulate these palettes, including defining them. > > pkgA is intended to be used in other packages, e.g. in pkgB1 and > pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA. > They might set palettes with the same name, of course, they do not > know about each other. > > My question is, is there a straightforward way to implement pkgA's > API, such that pkgB1 and pkgB2 do not interfere? In other words, if > pkgB1 and pkgB2 both define a palette 'foo', but they define it > differently, each should see her own version of it. > > I guess this requires that I put something (a function?) in both > pkgB1's and pkgB2's package namespace. As I see it, this can only > happen when pkgA's API is called from pkgB1 (and pkgB2). > > So at this time I could just walk up the call tree and put the palette > definition in the first environment that is not pkgA's. This looks > somewhat messy, and I am probably missing some caveats. > > Is there a better way? I have a feeling that this is already supported > somehow, I just can't find out how. > Try the settings package. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using Rtools with gcc 4.8.3
On Sun, Oct 5, 2014 at 6:51 AM, Uwe Ligges wrote: > > > On 05.10.2014 12:20, Jeroen Ooms wrote: >> >> I started working on some R bindings for mongo-c-driver [1]. The C >> library compiles fine on Ubuntu Trusty (gcc 4.8.2) and osx (clang), >> however on my windows machine (gcc 4.6.3 from Rtools 3.1) it fails >> with: 'INIT_ONCE_STATIC_INIT' undeclared. Google suggests that this >> might be a problem in older versions of mingw-w64. So I grabbed a copy >> of mingw-w64 version 4.8.3 and indeed, here the library compiles >> without errors. >> >> Now I am unsure how to make mingw 4.8.3 work with Rtools. I extracted >> the contents of [2] into "C:\RBuildTools\3.1\gcc-4.8.3\" and my >> package Makevars contains >> >>CC = "c:/RBuildTools/3.1/gcc-4.8.3/bin/gcc" >> >> However it seems like R still uses the old gcc 4.6.3 for R CMD >> INSTALL. What am I doing wrong? Is there a recommended setup for >> building packages on Windows using a Rtools but with another compiler? >> >> In addition: will I be able to publish this package to CRAN, or do I >> have to wait for Rtools to get updated with a more recent gcc? > > > Currently only 4.6.3 is supported and that is the one used to build binary > packages on CRAN. Hence you need to wait until it is updated. > > Best, > Uwe Ligges > > >> >> [1] https://github.com/mongodb/mongo-c-driver >> [2] >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.3/threads-posix/dwarf/ >> Are there any plans for this? gcc is already up to 4.9.1 and I am sure a lot of people would like to see the latest version available as part of Rtools. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
Yes, Depends certainly has a role. The ability of one package to automatically provide all the facilities of another package to the user is important. There are many situations where the functionality you want to provide to the user is split among multiple packages. For example, 1. xts uses zoo and the user ought to be able to use all the functionality of zoo when they issue a library(zoo) call. The alternatives are that the user must tediously issue library(zoo) every time they issue library(xts) or else that the zoo code be copied or partially replicated into xts which would be undesirable maintenance-wise. 2. Another example is sqldf. The user wants to be able to use fn$ and other string manipulation functions in gsubfn when using sqldf in order to perform string substitution on the SQL statement. Also its desirable to be able to directly access sqlite which means the user needs access to RSQLite. 3. At one time one could just issue library(ggplot2) but now that ggplot2 does not use Depends for scales one annoyingly needs to issue library(scales) if one wants to specify a scale. I use ggplot2 enough that I can remember it despite the ongoing annoyance but I would hate to think that every package with split functionality suddenly adds such onerous requirements onto all its users. (I am not really picking on ggplot2 which is a very nice package - just this one aspect.) I am not sure but there might be additional problems if the secondary package defines an S3 generic that the primary package needs to use if one does not use Depends. On Thu, Aug 28, 2014 at 2:43 PM, Gavin Simpson wrote: > I fully agree. > > This is how I have come to understand Depends vs Imports and why I > currently will not be removing vegan from Depends for my analogue package. > This is also why I was pushing back against the notion that was voiced > early in this thread that *nothing* should be in Depends. > > Cheers > > G > > > On 28 August 2014 08:47, Bert Gunter wrote: > >> This is a nice explanation of the Imports/Depends distinction. It >> ought to go into the Extensions ref manual imho. >> >> Cheers, >> Bert >> >> Bert Gunter >> Genentech Nonclinical Biostatistics >> (650) 467-7374 >> >> "Data is not information. Information is not knowledge. And knowledge >> is certainly not wisdom." >> Clifford Stoll >> >> >> >> >> On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek >> wrote: >> > >> > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: >> > >> >> On 27 August 2014 15:24, Hadley Wickham wrote: >> >> >> Is that the cause of these NOTEs? Is the expectation that if I am >> using a >> function from a package, even a package that I have in Depends:, that >> I >> have to explicitly declare these imports in NAMESPACE? >> >>> >> >>> Yes. >> >>> >> >>> (Otherwise your package won't work if it's only attached and not >> >>> loaded. i.e. if someone does analogue::foo() only the imported >> >>> functions are available, not the functions in packages you depend on) >> >>> >> >> >> >> Cheers Hadley. Thanks for the confirmation, but... >> >> >> >> ...I don't get this; what is the point of Depends? I thought it was "my >> >> package needs these other packages to work, i.e. be loaded". Hence it is >> >> user error (IMHO ;-) to do `analogue::foo()` without having the >> >> dependencies loaded too. >> >> >> > >> > No. The point of Depends is that if your package is attached, it also >> attaches the other packages to make them available for the user. >> Essentially you're saying "if you want to use my package interactively, you >> will also want to use those other packages interactively". You still need >> to use import() to define what exactly is used by your package - as opposed >> to what you want to be available to the user in case it is attached. >> > >> > Cheers, >> > Simon >> > >> > >> > >> >> This check (whilst having found some things I should have imported and >> >> didn't - which is a good thing!) seems to be circumventing the >> intention of >> >> having something in Depends. Is Depends going to go away? >> >> >> >> >> >>> (And really you shouldn't have any packages in depends, they should >> >>> all be in imports) >> >> >> >> >> >> I disagree with *any*; having say vegan loaded when one is using >> analogue >> >> is a design decision as the latter borrows heavily from and builds upon >> >> vegan. In general I have moved packages that didn't need to be in >> Depends >> >> into Imports; in the version I am currently doing final tweaks on >> before it >> >> goes to CRAN I have remove all but vegan from Depends. >> >> >> >> Or am I thinking about this in the wrong way? >> >> >> >> Thanks again >> >> >> >> Gavin >> >> >> >> >> >>> >> >>> Hadley >> >>> >> >>> >> >>> -- >> >>> http://had.co.nz/ >> >>> >> >> >> >> >> >> >> >> -- >> >> Gavin Simpson, PhD >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> http
Re: [Rd] Licence for datasets in a R-package
On Mon, Jul 21, 2014 at 12:54 PM, Gábor Csárdi wrote: > In practice, CRAN maintainers do not allow multiple licenses for parts > of the same package. At least they did not for my package a couple of > months ago. > If that is the case then you could put your data files in a separate package from the code with one depending on the other. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] useDynLib
I would like to be able to load two versions of a package at once and to do that was thinking of giving each version a different package name in the DESCRIPTION file and the building and installing each such version separately. library(myPkg1) library(myPkg2) and then use myPkg1::myFun() and myPkg2::myFun(). To do that easily it would be convenient if one could change the package name in only one place (the DESCRIPTION file) and have that propagate to all other uses of the package name in the package. Suppose the package were named "myPkg". Then the problem areas are: 1. The NAMESPACE file has myPkg hard-coded like this: useDynLib(myPkg, .registration=TRUE) 2. The configure.ac file has myPkg hard-coded like this: AC_INIT([myPkg], 1.0.0) 3. There are various references to myPkg hard-code throughout the R code, e.g. myPkg::myFun, but I am ok here as I assume this would work where an .onLoad would be used to grab the package name from the .onLoad's pkgname argument: `::`(pkgname, MyFun) (Also some or all of these may not be needed in the first place.) 1. Is there some way to cause these instances to change when the package name in the DESCRIPTION file changes or is there some other approach that would make it easy to change the package name in just one spot or some other way to load two packages that are versions of each other at one time. (The fact that the package has C++ code seems to be the complicating factor.) 2. Are there any examples of CRAN packages that have been set up to make this easy to do? Thanks. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] type.convert and doubles
On Sat, Apr 19, 2014 at 1:06 PM, Simon Urbanek wrote: > On Apr 19, 2014, at 9:00 AM, Martin Maechler > wrote: > > I think there should be two separate discussions: > > a) have an option (argument to type.convert and possibly read.table) to > enable/disable this behavior. I'm strongly in favor of this. > > b) decide what the default for a) will be. I have no strong opinion, I can > see arguments in both directions > > But most importantly I think a) is better than the status quo - even if the > discussion about b) drags out. > > Cheers, > Simon Another possibility is: (c) Return the column as factor/character but with a distinguishing class so that the user can reset its class later. e.g. DF <- read.table(...) DF[] <- lapply(DF, function(x) if (inherits(x, "special.class")) as.numeric(x) else x) Personally I would go with (a) in both type.convert and read.table with a default that reflects the historical behavior rather than the current 3.1 behavior. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Can the output of Sys.getenv() be improved?
On Fri, Apr 18, 2014 at 12:38 PM, Zhang,Jun wrote: > Within an R session, type Sys.getenv() will list all the environment > variables, but each one of them occupies about a page, so scrolling to find > one is difficult. Is this because I don't know how to use it or something > could be improved? Usually I'm not sure the exact name of a variable but want > to look it up. Recently I installed rjags, with the JAGS-3.4.0's lib, > include, modules information provided during compilation. When I load rjags, > I was told that it linked to JAGS 3.3.0 (a package also available in my > environment). This made me think there must be a variable to make that to > happen. What can I do to make rjags to link to JAGS 3.4.0? > Try this: str(as.list(Sys.getenv())) or this: View(as.matrix(Sys.getenv())) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] type.convert and doubles
On Thu, Apr 17, 2014 at 2:21 PM, Murray Stokely wrote: > If you later want to do arithmetic on them, you can choose to lose > precision by using as.numeric() or use one of the large number > packages on CRAN (GMP, int64, bit64, etc.). But once you've dropped > the precision with as.numeric you can never get it back, which is why > the previous behavior was clearly dangerous. Only if you knew that that column was supposed to be numeric. There is nothing in type.convert or read.table to allow you to override how it works (colClasses only works if you knew which columns are which in the first place) nor is there anything to allow you to know which columns were affected so that you know which columns to look at to fix it yourself afterwards. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
On Tue, Oct 29, 2013 at 1:58 AM, wrote: > Le 2013-10-29 03:01, Whit Armstrong a écrit : > >> I would love to see optional c++0x support added for R. > > > c++0x was the name given for when this was in development. Now c++11 is a > published standard backed by implementations by major compilers. > people need to stop calling it c++0x > > >> If there is anything I can do to help, please let me know. > > > Come here https://github.com/romainfrancois/cpp11_article where I'm writing > an article on C++11 and what would be the benefits. > Unless you are willing to do it yourself currently Rtools on Windows uses g++ 4.6.3 and that requires that one specify -std=c++0x or -std=gnu++0x . Ubuntu 12.04 LTS also provides g++ 4.6.3. g++ 4.7 is the first version of g++ that accepts -std=c++11 or -std=gnu++11 More info at: http://gcc.gnu.org/projects/cxx0x.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
