[Rd] Possible bug in predict.lm when x is a poly

Hi all, As always, thank you all for your incredible work maintaining and improving R. mdl <- lm(data = mtcars, mpg ~ I(poly(disp, 2))) predict(mdl, newdata = data.frame(disp = c(120, 120))) #> Error in poly(disp, 2): 'degree' must be less than number of unique points predict(mdl, new

Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

I also tried just upgrading to 20.04 and that seemed to fix it. On Tue, May 26, 2020 at 5:38 PM Kenny Bell wrote: > I can also confirm that the latest https://hub.docker.com/_/r-base has > the correct behaviour. > > On Tue, May 26, 2020 at 5:05 PM Kenny Bell wrote: > >> I

Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

I can also confirm that the latest https://hub.docker.com/_/r-base has the correct behaviour. On Tue, May 26, 2020 at 5:05 PM Kenny Bell wrote: > I was actually able to reproduce this on a relatively fresh install of > 18.04 (a virtualbox). Paul, did you run apt update && apt

Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

I was actually able to reproduce this on a relatively fresh install of 18.04 (a virtualbox). Paul, did you run apt update && apt upgrade before trying to reproduce? On Tue, May 26, 2020 at 4:36 PM Kenny Bell wrote: > Hi Paul, > > I tried downgrading to R 3.4.4 and I still s

Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and n

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

Hi all, I have found after upgrading to R 4.0.0 (among other upgrades so this may not be the cause) that the degree symbol doesn't work correctly on Ubuntu 18.04. Googling brought me to this thread that appears related. I tried running: cairo_pdf() plot.new(); text(0.5,0.5, bquote(120*degree*N),

Re: [Rd] Model object, when generated in a function, saves entire environment when saved

the rds does not save_size_qs(normal_lm()) #> [1] 848396 save_size_rds(normal_lm()) #> [1] 4163 save_size_qs(normal_ggplot()) #> [1] 857446 save_size_rds(normal_ggplot()) #> [1] 12895 # Both exclude the junk when separating the lm into its own environment save_size_qs(clean_lm()) #>

[Rd] Writing files with long paths on Windows fails even after enabling long paths

Hello all, We now can have long file paths on Windows by setting the LongPathsEnabled key to 1 at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem in the Registry Editor. I can successfully rename files to have long paths in File Explorer. R still isn't able to take advantage of the

Re: [Rd] Problem with compiling OpenBLAS to work with R

This person has had apparent success - you could follow what they did or just download their product (with appropriate caution downloading a random .exe). https://github.com/thequackdaddy/R-OpenBLAS On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess wrote: > Hello! > > I'm not sure if this is the rig

[Rd] Request: make `var` a generic

Hi all, I am running into problems using `summary.lm` as calling `var` on a `units` object does not retain the `units` attribute. The units package addresses this issue for `mean` by implementing `mean.units`: units:::mean.units function (x, ...) { .as.units(NextMethod(), units(x)) } This i

Re: [Rd] Is this a bug in `[`?

This should more clearly illustrate the issue: c(1, 2, 3, 4)[-seq_len(4)] #> numeric(0) c(1, 2, 3, 4)[-seq_len(3)] #> [1] 4 c(1, 2, 3, 4)[-seq_len(2)] #> [1] 3 4 c(1, 2, 3, 4)[-seq_len(1)] #> [1] 2 3 4 c(1, 2, 3, 4)[-seq_len(0)] #> numeric(0) Created on 2018-08-05 by the reprex package (v0.2.0.900

Re: [Rd] R Compilation gets stuck on Windows 64

You can see how the appveyor build works here: https://github.com/rwinlib/base I suggest that you work off the build process in the rwinlib repository so you are starting from something that you know works and already incorporates the set of dependencies you need. On Fri, Feb 9, 2018, 5:33 AM A

[Rd] saveRDS() overwrites file when object is not found

I ran into this behaviour when accidentally running a line of code that I shouldn't have. When saving over an rds with an object that's not found, I would have expected saveRDS to not touch the file. saveRDS(iris, "test.rds") file.size("test.rds") #> [1] 1080 saveRDS(no_object_here, "test.rds") #

Re: [Rd] Best practices in developing package: From a single file

In response to Duncan regarding the use of roxygen2 from the point of view of a current user, I believe the issue he brings up is one of correlation rather than causation. Writing my first piece of R documentation was made much easier by using roxygen2, and it shallowed the learning curve substant

Re: [Rd] OpenBLAS in everyday R?

h GPL libraries, shipping R by default with Non-GPL is > illegal. > > Cheers, > Juan > > El 17/12/2017 2:50 a. m., "Avraham Adler" > escribió: > >> On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell wrote: >> > It seems like many of the multi-threaded B

Re: [Rd] OpenBLAS in everyday R?

or produce wrong answers with large data, and they > all come from OpenBLAS users. I am yet to reproduce any of their > crashes when using MKL and ATLAS BLAS implementations. > > Just my 2 cents... > > Peter > > On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell wrote: >

Re: [Rd] OpenBLAS in everyday R?

> I'm not sure how pervasive a problem this is, though. > > Keith > > > On Sat, Dec 16, 2017 at 4:01 PM, Dirk Eddelbuettel wrote: > >> >> Kenny, >> >> On 17 December 2017 at 09:28, Kenny Bell wrote: >> | Hi R-devel list, >> | >> | O

Re: [Rd] OpenBLAS in everyday R?

On Sun, Dec 17, 2017 at 10:01 AM, Dirk Eddelbuettel wrote: > > Kenny, > > On 17 December 2017 at 09:28, Kenny Bell wrote: > | Hi R-devel list, > | > | OpenBLAS is readily available for unix-likes: > | > | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd

[Rd] OpenBLAS in everyday R?

Hi R-devel list, OpenBLAS is readily available for unix-likes: https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf However, my questions are: 1) Would R-devel consider using OpenBLAS for the main distribution of R for all platforms including Windows? 2) If so, would R-devel set the

Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?

User here: incorporating Intel's MKL, as MRO does, would be a very welcome addition. I was an MRO user before and it improved my experience with medium data immensely. They did, however, leave behind bugs here and there, especially related to development with Rcpp, so I switched back to vanilla R

[Rd] Parallel compression support for saving to rds/rdata files?

Hi, I have tried to follow the instructions in the ``save`` documentation and it doesn't seem to work (see below): mydata <- do.call(rbind, rep(iris, 1)) con <- pipe("pigz -p8 > fname.gz", "wb"); save(mydata, file = con); close(con) # This runs R.utils::gunzip("fname.gz", "fname.RData", over

[Rd] Spam messages

Have others received spam messages after posting to this list? The two problem emails are hodgesdonna...@yahoo.com and amykristen4...@octbm.com. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mai

[Rd] unlist strips date class

Is this a bug? > unlist(list(as.Date("2015-01-01"))) [1] 16436 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

ked on, it had the advantage of existing. > > Hadley > > On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell wrote: > > Why is the described system preferable to Julia? > > > > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard wrote: > > > >> > >> On 05 Aug

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

Why is the described system preferable to Julia? On Fri, Aug 5, 2016, 4:50 AM peter dalgaard wrote: > > On 05 Aug 2016, at 06:41 , Andrew Judson wrote: > > > I read this paper > > and > > haven't been able to find out what hap

Re: [Rd] Model object, when generated in a function, saves entire environment when saved

1] 910 > > instead of the 2129743 bytes in the save file when using the naive > method. > > > > saveSize <- function (object) { > > tf <- tempfile(fileext = ".RData") > > on.exit(unlink(tf)) > > save(object, file = tf) > > file.s

[Rd] Model object, when generated in a function, saves entire environment when saved

In the below, I generate a model from an environment that isn't .GlobalEnv with a large object that is unrelated to the model generation. It seems to save the irrelevant object unnecessarily. In my actual use case, I am running and saving many models in a loop that each use a single large data.fram