similar to: all.equal, classes, and order of arguments

Hi all, Do any packages implement density estimation in a modelling framework? I want to be able to do something like: dmodel <- density(~ a + b, data = mydata) predict(dmodel, newdata) This isn't how sm or KernSmooth or base density estimation works. Are there other packages that do density estimation? Or is there some reason that this is a bad idea. Hadley -- http://had.co.nz/

Hi, The description of all.equal states "is.all.equal should be used for programming, typically in if expressions. It is a simple wrapper using identical as shown in the documentation there.", but is.all.equal is not explicitly defined there (although there is a hint in the comments that is.all.equal <- function(x,y) isTRUE(all.equal(x,y))). Could the documentation be corrected? (or

Ok, here's another best practices question - let's say I'm writing a package and I want to use a function name that is already claimed by a function in the base R packages. For the sake of argument, let's pretend this function is for profiling the performance of a function (like Rprof for example), and so an obvious name that comes to mind is profile. This, of course, clashes

You might find http://adv-r.hadley.nz/s3.html to be helpful (in particular, http://adv-r.hadley.nz/s3.html#constructors-1, gives my advice about subclass constructors) Hadley On Mon, Aug 7, 2017 at 7:06 PM, Kym Nitschke <kym.nitschke at icloud.com> wrote: > Hi R Users, > > I am relatively new to programming in R ? so I apologise if my questions appear ?dumb?. > > I am using

Just noticed these two functions (clearNames is stats and unname in base) that do the same thing. Hadley -- http://had.co.nz/

?On 30/08/2018, 20:15, "R-devel on behalf of Hadley Wickham" <r-devel-bounces at r-project.org on behalf of h.wickham at gmail.com> wrote: On Thu, Aug 30, 2018 at 10:58 AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Joris Meys > >>>>> on Thu, 30 Aug 2018 14:48:01 +0200 writes: >

Should the following two functions should always give the same result, except for possible differences in the 'call' component of the warning or error message?: f0 <- function(x, y) x || y f1 <- function(x, y) if (x) { TRUE } else { if (y) {TRUE } else { FALSE } } And the same for the 'and' version? g0 <- function(x, y) x && y g1 <- function(x, y) if

>>>>> Joris Meys >>>>> on Thu, 30 Aug 2018 14:48:01 +0200 writes: > On Thu, Aug 30, 2018 at 2:09 PM D?nes T?th > <toth.denes at kogentum.hu> wrote: >> Note that `||` and `&&` have never been symmetric: >> >> TRUE || stop() # returns TRUE stop() || TRUE # returns an >> error >>

# Issue 'x || y' performs 'x[1] || y' for length(x) > 1. For instance (here using R 3.5.1), > c(TRUE, TRUE) || FALSE [1] TRUE > c(TRUE, FALSE) || FALSE [1] TRUE > c(TRUE, NA) || FALSE [1] TRUE > c(FALSE, TRUE) || FALSE [1] FALSE This property is symmetric in LHS and RHS (i.e. 'y || x' behaves the same) and it also applies to 'x && y'.

Hi Hadley, Thanks for the counterpoint. Response below. On Thu, May 16, 2019 at 1:59 PM Hadley Wickham <h.wickham at gmail.com> wrote: > The existing behaviour seems inutitive to me. I would consider these > invariants for n vector x_i's each with size m: > > * nrow(rbind(x_1, x_2, ..., x_n)) equals n > Personally, no I wouldn't. I would consider m==0 a degenerate

Hi all, Because str uses the generic version of length and names, it's currently very easy to create objects that break str: a <- structure(list(1:5), class = "a") length.a <- function(x) 2L str(a) b <- structure(list(1:5), class = "b") names.b <- function(x) character() str(b) These are obvious toy examples, but it is a real problem if you want to create

> First off, you are using the word "type" throughout this email; You seem to > mean class (judging by your Date and factor examples, and the fact you > mention S3 dispatch) as opposed to type in the sense of what is returned by > R's typeof() function. I think it would be clearer if you called it class > throughout unless that isn't actually what you mean (in

Could of requests: 1) Is there any example or writeup on the difficulties of extending reference classes across packages? Just so I can fully understand the issues. 2) In what sorts of situations does the performance of reference classes cause problems? Sure, it's an order of magnitude slower than constructing a simple environment, but those timings are in microseconds, so one would need a

As suggested by the following code: A <- setRefClass("A", fields = list(x = "logical"), methods = list(initialize = function(...) { x <<- FALSE initFields(...) })) A$new() # Works as expected quote <- as.character A$new() # Error in function (value) : # invalid replacement for field ?x?, should be from class ?logical? or a subclass (was class

Dear all, I have been using the proto package to create objects with mutable state for my ggplot package. This has been very successful so far, but I have run into a problem when building/installing the package, because the source files need to be loaded in a specific order so that dependencies are initialised correctly. I have named the files so that dependencies are loaded before they are

Hi all, Would someone mind pointing to me to the inspiration for the use of the L suffix to mean "integer"? This is obviously hard to google for, and the R language definition (https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Constants) is silent. Hadley -- http://hadley.nz

But you can easily fall back to R from within Julia; see http://juliastats.github.io/RCall.jl/latest/ On Aug 5, 2016 1:27 PM, "Hadley Wickham" <h.wickham at gmail.com> wrote: > No. > > Hadley > > On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell <kmbell56 at gmail.com> wrote: > > Is it conceivable that Julia could be ported to use R syntax in a way > that

Is it conceivable that Julia could be ported to use R syntax in a way that would allow the vastly larger numbers of R programmers to seamlessly switch? Or equivalently, could an iteration of R itself do this? On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham <h.wickham at gmail.com> wrote: > When it was being actively worked on, it had the advantage of existing. > > Hadley > > On

Millot, On Mon, Jun 15, 2015 at 9:19 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > Regardless of the value of the other arguments, the first element in > the output of seq() is _always_ `from`. > Indeed, as Hadley says, the output of seq must always start with* from*. It is a sequence starting at *from* and ending wherever the other arguments cause it to end. A sequence

Hi Martin, Thanks for chiming in. Responses inline. On Fri, May 17, 2019 at 12:32 AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > >>>>> Gabriel Becker > >>>>> on Thu, 16 May 2019 15:47:57 -0700 writes: > > > Hi Hadley, > > Thanks for the counterpoint. Response below. > > > On Thu, May 16, 2019 at 1:59