[Rd] aggregate() naming -- bug or feature
In the examples below, the first loses the name attached by foo(), the second
retains names attached by bar(). Is this an intentional difference? I’d
prefer that the names be retained in both cases.
foo <- function(x) { c(mean = base::mean(x)) }
bar <- function(x) { c(mean = base::mean(x), sd = stats::sd(x))}
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = foo)
#> Group.1 x
#> 1 setosa 5.006
#> 2 versicolor 5.936
#> 3 virginica 6.588
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = bar)
#> Group.1x.mean x.sd
#> 1 setosa 5.006 0.3524897
#> 2 versicolor 5.936 0.5161711
#> 3 virginica 6.588 0.6358796
—rjp
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] aggregate() naming -- bug or feature
Thanks.
I’m aware of the other syntax. My example was just to illustrate the issue
minimally, not to indicate how I am using aggregate(). In my application,
aggregate() will be called within another function, and the information passed
to aggregate() is columns of a matrix returned by model.frame().
For now, I’ve written by own local version of aggregate() with a few tweaks to
retain the names I want.
But my question remains: Is this a bug or a feature?
—rjp
On Mar 23, 2018, at 6:57 PM, Ista Zahn
mailto:istaz...@gmail.com>> wrote:
On Fri, Mar 23, 2018 at 6:43 PM, Rui Barradas
mailto:ruipbarra...@sapo.pt>> wrote:
Hello,
Not exactly an answer but here it goes.
If you use the formula interface the names will be retained.
Also if you pass named arguments:
aggregate(iris["Sepal.Length"], by = iris["Species"], FUN = foo)
# Species Sepal.Length
# 1 setosa5.006
# 2 versicolor5.936
# 3 virginica6.588
If fact, this
is even better than those names assigned by bar.
aggregate(Sepal.Length ~ Species, data = iris, FUN = foo)
# Species Sepal.Length
#1 setosa5.006
#2 versicolor5.936
#3 virginica6.588
Hope this helps,
Rui Barradas
On 3/23/2018 1:29 PM, Randall Pruim wrote:
In the examples below, the first loses the name attached by foo(), the
second retains names attached by bar(). Is this an intentional difference?
I’d prefer that the names be retained in both cases.
foo <- function(x) { c(mean = base::mean(x)) }
bar <- function(x) { c(mean = base::mean(x), sd = stats::sd(x))}
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = foo)
#> Group.1 x
#> 1 setosa 5.006
#> 2 versicolor 5.936
#> 3 virginica 6.588
aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = bar)
#> Group.1x.mean x.sd
#> 1 setosa 5.006 0.3524897
#> 2 versicolor 5.936 0.5161711
#> 3 virginica 6.588 0.6358796
—rjp
[[alternative HTML version deleted]]
__
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFaQ&c=4rZ6NPIETe-LE5i2KBR4rw&r=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00&m=wR-DoggMzZ5fX3PJlgbTQe2njoPJ03CTiimaCc_OHe0&s=rehyeJZBteb4wYmKFPvE74AzY4Nm__6Cm4h2q4xfXnk&e=
__
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFaQ&c=4rZ6NPIETe-LE5i2KBR4rw&r=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00&m=wR-DoggMzZ5fX3PJlgbTQe2njoPJ03CTiimaCc_OHe0&s=rehyeJZBteb4wYmKFPvE74AzY4Nm__6Cm4h2q4xfXnk&e=
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel Digest, Vol 181, Issue 22
Thanks.
I am fully aware of what aggregate() returnes, and I can post-process this into
the form I want — if the names are available.
But for foo, the returned object is both different in structure and loses the
name altogether:
foo <- function(x) { c(mean = base::mean(x)) }
str(aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = foo))
## 'data.frame': 3 obs. of 2 variables:
## $ Group.1: Factor w/ 3 levels "setosa","versicolor",..: 1 2 3
## $ x : num 5.01 5.94 6.59
If $x were $mean, or if $x were a matrix with one column named “mean”, then I
would not have had to write a custom aggregate.
For anyone interested, I’m doing this to create a function that can compute
(multiple, group-wise) summary statistics easily, and return them in a tidy
data frame with one row for each group. Naming depends on whether … arguments
are named and on some optional arguments. Here is an example.
args(df_stats)
## function (formula, data, ..., drop = TRUE, fargs = list(), sep = "_",
## format = c("wide", "long"), groups = NULL, long_names = TRUE,
## nice_names = FALSE, na.action = "na.warn")
df_stats(Sepal.Length ~ Species, data = iris, mean, sd, R = range, Q = quantile)
## Species mean_Sepal.Length sd_Sepal.Length R_1 R_2 Q_0% Q_25% Q_50%
Q_75% Q_100%
## 1 setosa 5.006 0.3524897 4.3 5.8 4.3 4.800 5.0
5.25.8
## 2 versicolor 5.936 0.5161711 4.9 7.0 4.9 5.600 5.9
6.37.0
## 3 virginica 6.588 0.6358796 4.9 7.9 4.9 6.225 6.5
6.97.9
As I’ve said, I solved my problem by creating a slightly modified version of
aggregate(). But it made me wonder whether this is a bug or a feature in
aggregate().
—rjp
On Mar 25, 2018, at 6:00 AM,
r-devel-requ...@r-project.org wrote:
Date: Sat, 24 Mar 2018 20:08:33 + (UTC)
From: lmo mailto:lukemol...@yahoo.com>>
To: "R-devel@r-project.org"
mailto:R-devel@r-project.org>>
Subject: [Rd] aggregate() naming -- bug or feature
Message-ID:
<1099191693.397761.1521922113...@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"
Be aware that the object that aggregate returns with bar() is more complicated
than you think.
str(aggregate(iris$Sepal.Length, by = list(iris$Species), FUN = bar))
'data.frame':3 obs. of 2 variables:
$ Group.1: Factor w/ 3 levels "setosa","versicolor",..: 1 2 3
$ x : num [1:3, 1:2] 5.006 5.936 6.588 0.352 0.516 ...
..- attr(*, "dimnames")=List of 2
.. ..$ : NULL
.. ..$ : chr "mean" "sd"
So you get a two column data.frame whose second column is a matrix.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] residual standard "error"
I see that the sigma() function has recently been introduced into R 3.3. The help for sigma() says: Extract the estimated standard deviation of the errors, the “residual standard deviation” (misnomed also “residual standard error”, e.g., in summary.lm()'s output, from a fitted model. Is there any reason not to fix the mis-naming of residual standard error now too? Both functions are in the stats package. It seems odd for one function in the package to point out an issue with another, especially when fixing it would only affect displayed output and not the rest of the API. My apologies if this has been suggested before, but a search through the archives didn’t locate the discussion. Also, there is a missing paren in the sentenced quoted from the help for sigma(). —rjp [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] {splines} package gone missing?
https://cran.r-project.org/web/packages/splines/index.html claims the the
{splines} package has been archived. If I follow the link there to the
archives, the newest version shown is from 1999. It seems like something has
gone wrong with this package.
I checked on another mirror and {splines} is missing there as well.
—rjp
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] {splines} package gone missing?
Thanks. I actually sort of checked for this:
row.names(installed.packages(priority = "base"))
[1] "base" "compiler" "datasets" "graphics" "grDevices" "grid"
"methods" "parallel" "stats" "stats4""tcltk"
[12] "tools" "utils"
But, of course, if the package is missing on my system (a newly installed 4.1
on an RStudio server), then it won’t be listed here.
I’ll have to figure out what went wrong with the install. I’ll probably start
by having our sysadmin simply reinstall R 4.1 and hope that that takes care of
the problem.
Looks like profile is missing as well.
—rjp
On May 20, 2021, at 3:14 AM, peter dalgaard
mailto:pda...@gmail.com>> wrote:
It is part of base R, so comes with the R sources:
Peters-MacBook-Air:R pd$ ls src/library/
Makefile.in compiler/ grid/ splines/ tools/
Makefile.win<http://Makefile.win> datasets/ methods/ stats/
translations/
Recommended/ grDevices/parallel/ stats4/ utils/
base/ graphics/ profile/ tcltk/
- pd
On 20 May 2021, at 06:02 , Randall Pruim
mailto:rpr...@calvin.edu>> wrote:
https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_packages_splines_index.html&d=DwIFaQ&c=4rZ6NPIETe-LE5i2KBR4rw&r=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00&m=GW4Zim0TvggrmjKt0HtW7il0NwJJaworM4-LL3H2FyI&s=69EYlZJd6di726T20ILKnX7f4GWM-VaUplRjNXfGolQ&e=
claims the the {splines} package has been archived. If I follow the link
there to the archives, the newest version shown is from 1999. It seems like
something has gone wrong with this package.
I checked on another mirror and {splines} is missing there as well.
—rjp
__
R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel&d=DwIFaQ&c=4rZ6NPIETe-LE5i2KBR4rw&r=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00&m=GW4Zim0TvggrmjKt0HtW7il0NwJJaworM4-LL3H2FyI&s=Jen0Ht23Vg-znRGxp8YPRc-qCbG0uLYGAyyECxU6kFg&e=
--
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<mailto:pd@cbs.dk> Priv:
pda...@gmail.com<mailto:pda...@gmail.com>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] {splines} package gone missing?
Thanks everyone. We are already back up and running. We just did a redo of the install and started from scratch. Actually, not quite from scratch since the packages in /usr/local that I had updated were not harmed. I’m guessing this was all a side effect of an attempt to clean up from someone previously having installed contributed packages in amongst the base packages. I’m guess splines got caught in the dragnet when cleaning up the mess. —rjp > On May 21, 2021, at 1:07 PM, Dirk Eddelbuettel wrote: > > > Randall, > > On 20 May 2021 at 07:12, Ben Bolker wrote: > | splines is 'recommended' ( not sure about capitalization), not "base' > > If you install 'r-base' rather than just the narrower 'r-base-core' you > also get 'r-recommended'. So please do that, or just do > > sudo apt install r-recommended > > The granularity offered is thought of as a feature even if it stares at you > right now with very humongous insect eyes... > > Dirk > > -- > https://urldefense.proofpoint.com/v2/url?u=https-3A__dirk.eddelbuettel.com&d=DwICAg&c=4rZ6NPIETe-LE5i2KBR4rw&r=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00&m=l1obx7tzJNQb2j6J4_wfeDktT--xuNcUP2IrIfMN5go&s=PcRNlKxDRkHI7d0Wt3SK1T5PjhYO3YJMXiy0MsXJvXE&e= > | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] combining generics/methods from multiple packages
I’m wondering if there is any way for me to create a generic function in a package that merges the generics and methods from two or more packages that each define a generic with the same name, but have non intersecting instances. Here is an example. dplyr and MASS both define an S3 generic select() but define no colliding methods. Just to make life extra interesting, there is also utils::select.list() which is not intended to be a method for select() and in fact wants to receive a character vector, not a list. I would like to create a generic select() in my package such that 1) select.ridgelm <- MASS:::select.ridgelm [Note: this is not exported.] 2) select.data.frame <- dplyr::select.data.frame [Also not exported.] etc. for other methods in this package. 3) utils::select.list does NOT act like the select method for lists. The only way I have been able to figure out how to do this requires use of the ::: operator, so let me add criterion 4: 4) The resulting package must pass CRAN checks without issues. Is this possible? If so how? My goal is to have select() work on objects that either package can handle without having to use MASS::select() or dplyr::select(). Thanks in advance for any help — even if it is an explanation for why this is impossible and I should stop trying. —rjp __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vignette index going AWOL
I’m preparing a package (fastR) for submission to CRAN, but the vignette index
keeps going AWOL, or at least R CMD check —as-cran thinks so. I’ve tried
several things and gave myself the weekend to think of other things, but I
can’t figure it out. Perhaps someone on the list can lend a hand.
Here’s one example situation, where I build the index.html file myself and put
it in inst/doc/index.html
$ cat fastR.Rcheck/00check.log | grep -v OK
* using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
* using R Under development (unstable) (2014-08-21 r66456)
* using platform: x86_64-apple-darwin13.1.0 (64-bit)
* using session charset: UTF-8
* checking extension type ... Package
* this is package ‘fastR’ version ‘0.8-0’
* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Randall Pruim ’
Package has a VignetteBuilder field but no prebuilt vignette index.
NOTE: There was 1 note.
$ tar -tf fastR_0.8-0.tar.gz | grep inst/doc
fastR/inst/doc/
fastR/inst/doc/Errata.Rnw
fastR/inst/doc/Errata.pdf
fastR/inst/doc/Updates.R
fastR/inst/doc/Updates.Rnw
fastR/inst/doc/Updates.pdf
fastR/inst/doc/index.html
There is an index.html in the tar ball. And If I install the package from the
tar ball, the index appears as it should in the package.
I would be happy with the auto-generated index, but that doesn’t seem to be
working either. If I remove index.html I get
$ grep -v OK fastR.Rcheck/00check.log
* using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
* using R Under development (unstable) (2014-08-21 r66456)
* using platform: x86_64-apple-darwin13.1.0 (64-bit)
* using session charset: UTF-8
* checking extension type ... Package
* this is package ‘fastR’ version ‘0.8-1’
* checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Randall Pruim ’
Package has a VignetteBuilder field but no prebuilt vignette index.
NOTE: There was 1 note.
$ tar -tf fastR_0.8-1.tar.gz | grep inst/doc
fastR/inst/doc/
fastR/inst/doc/Errata.Rnw
fastR/inst/doc/Errata.pdf
fastR/inst/doc/Updates.R
fastR/inst/doc/Updates.Rnw
fastR/inst/doc/Updates.pdf
Comparing with other successful packages created last week, it doesn’t appear
that the tar ball contains the vignette index for those either — or perhaps I
don’t know what I’m looking for.
$ tar -tf mosaic_0.9.1-3.tar.gz | grep -i index
mosaic/demo/00Index
(mosaic passes checks fine and are already on CRAN.)
Both packages use knitr to convert Rnw to PDF. mosaic also uses R.rsp to
include static PDFs.
$ grep -i vig mosaic/DESCRIPTION
VignetteBuilder: knitr, R.rsp
[09:22][rpruim@Mac21521:~/projects/github]
$ grep -i vig fastR/DESCRIPTION
VignetteBuilder: knitr
$ grep Vig mosaic/vignettes/*Rnw
%\VignetteIndexEntry{mosaic resources}
%\VignettePackage{mosaic}
%\VignetteKeywords{mosaic, vignettes, resources, references}
%\VignetteEngine{knitr::knitr}
$ grep Vig fastR/vignettes/*Rnw
fastR/vignettes/Errata.Rnw:%\VignetteEngine{knitr::knitr}
fastR/vignettes/Errata.Rnw:%\VignetteIndexEntry{Errata}
fastR/vignettes/Errata.Rnw:%\VignettePackage{fastR}
fastR/vignettes/Errata.Rnw:%\VignetteKeywords{fastR, vignettes}
fastR/vignettes/Updates.Rnw:%\VignetteEngine{knitr::knitr}
fastR/vignettes/Updates.Rnw:%\VignetteIndexEntry{Updates to R Programming in
FASt}
fastR/vignettes/Updates.Rnw:%\VignettePackage{fastR}
fastR/vignettes/Updates.Rnw:%\VignetteKeywords{mosaic, fastR, vignettes,
resources}
There must be some subtle difference between my two packages that I just can’t
spot.
Thanks in advance for any pointers about where to look.
—rjp
PS. The package is on github and installs fine (vignette index included, even
though there is no index.html in the repo) using install_github("fastR",
"rpruim")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette index going AWOL
Indeed! That should say “builds” rather than “build”. It is the directory
where I keep old tar balls from the package. I see builds is there as well.
Somewhere along the way I must have stuttered while editing and introduced the
problematic line. I’ve removed it and things are back to sanity.
Sometimes it just takes another set of eyes to see the obvious.
—rjp
On Aug 25, 2014, at 2:17 PM, Kevin Ushey wrote:
> Hi Randall,
>
> I notice that, in your .Rbuildignore, you have the entry:
>
>^build$
>
> and I suspect this is the culprit (having being bitten by a similar
> problem before). Some part of the R build / install process creates /
> uses that directory, but having it excluded in .Rbuildignore will
> cause you grief.
>
> In general, you probably have to consider `build` reserved for use by
> R, when developing R packages.
>
> Cheers,
> Kevin
>
> On Mon, Aug 25, 2014 at 11:10 AM, Randall Pruim wrote:
>> I’m preparing a package (fastR) for submission to CRAN, but the vignette
>> index keeps going AWOL, or at least R CMD check —as-cran thinks so. I’ve
>> tried several things and gave myself the weekend to think of other things,
>> but I can’t figure it out. Perhaps someone on the list can lend a hand.
>>
>> Here’s one example situation, where I build the index.html file myself and
>> put it in inst/doc/index.html
>>
>> $ cat fastR.Rcheck/00check.log | grep -v OK
>> * using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
>> * using R Under development (unstable) (2014-08-21 r66456)
>> * using platform: x86_64-apple-darwin13.1.0 (64-bit)
>> * using session charset: UTF-8
>> * checking extension type ... Package
>> * this is package ‘fastR’ version ‘0.8-0’
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘Randall Pruim ’
>> Package has a VignetteBuilder field but no prebuilt vignette index.
>> NOTE: There was 1 note.
>>
>> $ tar -tf fastR_0.8-0.tar.gz | grep inst/doc
>> fastR/inst/doc/
>> fastR/inst/doc/Errata.Rnw
>> fastR/inst/doc/Errata.pdf
>> fastR/inst/doc/Updates.R
>> fastR/inst/doc/Updates.Rnw
>> fastR/inst/doc/Updates.pdf
>> fastR/inst/doc/index.html
>>
>> There is an index.html in the tar ball. And If I install the package from
>> the tar ball, the index appears as it should in the package.
>>
>> I would be happy with the auto-generated index, but that doesn’t seem to be
>> working either. If I remove index.html I get
>>
>> $ grep -v OK fastR.Rcheck/00check.log
>> * using log directory ‘/Users/rpruim/projects/github/fastR/fastR.Rcheck’
>> * using R Under development (unstable) (2014-08-21 r66456)
>> * using platform: x86_64-apple-darwin13.1.0 (64-bit)
>> * using session charset: UTF-8
>> * checking extension type ... Package
>> * this is package ‘fastR’ version ‘0.8-1’
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘Randall Pruim ’
>> Package has a VignetteBuilder field but no prebuilt vignette index.
>> NOTE: There was 1 note.
>>
>> $ tar -tf fastR_0.8-1.tar.gz | grep inst/doc
>> fastR/inst/doc/
>> fastR/inst/doc/Errata.Rnw
>> fastR/inst/doc/Errata.pdf
>> fastR/inst/doc/Updates.R
>> fastR/inst/doc/Updates.Rnw
>> fastR/inst/doc/Updates.pdf
>>
>> Comparing with other successful packages created last week, it doesn’t
>> appear that the tar ball contains the vignette index for those either — or
>> perhaps I don’t know what I’m looking for.
>>
>> $ tar -tf mosaic_0.9.1-3.tar.gz | grep -i index
>> mosaic/demo/00Index
>>
>> (mosaic passes checks fine and are already on CRAN.)
>>
>> Both packages use knitr to convert Rnw to PDF. mosaic also uses R.rsp to
>> include static PDFs.
>>
>> $ grep -i vig mosaic/DESCRIPTION
>> VignetteBuilder: knitr, R.rsp
>>
>> [09:22][rpruim@Mac21521:~/projects/github]
>> $ grep -i vig fastR/DESCRIPTION
>> VignetteBuilder: knitr
>>
>> $ grep Vig mosaic/vignettes/*Rnw
>> %\VignetteIndexEntry{mosaic resources}
>> %\VignettePackage{mosaic}
>> %\VignetteKeywords{mosaic, vignettes, resources, references}
>> %\VignetteEngine{knitr::knitr}
>>
>> $ grep Vig fastR/vignettes/*Rnw
>> fastR/vignettes/Errata.Rnw:%\VignetteEngine{knitr::knitr}
>> fastR/vignettes/Errata.Rnw:%\VignetteIndexEntry{Errata}
>> fastR/vignettes/Errata.Rnw:%\VignettePackage{fastR}
>> fastR/vignettes/Errata.Rnw:%\VignetteKeywords{fastR, vignettes}
>> fastR/vignettes/Updates.Rnw:%\VignetteEngine{knitr::knitr}
>> fas
