[Rd] Inconsistent documentation of the return value of .getXlevels()

Hi all, I would like to report an inconsistency in the documentation regarding .getXlevels(). The return value states that: ".getXlevels returns a named character vector, or NULL." This is not consistent with what is actually returned, as seen further below in this message. I would suggest statin

[Rd] NextMethod() and argument laziness

Hi all, I'd like to ask if the following behavior is a bug. To me it certainly feels surprising, at the very least. In this example, I would like to call NextMethod() from my `child` object, have `cols` be left untouched, and then substitute(cols) in the parent method. It works when you use a `pare

[Rd] ALTREP "wrapper" classes needs an Extract_subset method

Hi all, I believe I have found a bug (or perhaps just an oversight) with the ALTREP wrapper classes. The short form of this is that I believe that the wrapper classes need to override the default ALTREP `Extract_subset_method()` with a method that calls `Extract_subset()` on the "wrapped" object.

Re: [Rd] Demo for linking native routines between R packages

Nice David! I also wrote up something similar a little while back https://github.com/DavisVaughan/cexport -Davis On Fri, Apr 17, 2020 at 7:09 AM Zhang, Jitao David via R-devel < r-devel@r-project.org> wrote: > Dear R developers, > > I want to advertise a small project for the educational purpose

Re: [Rd] Demo for linking native routines between R packages

I tried to do this a little. I mentioned xts along with: bdsmatrix https://github.com/cran/bdsmatrix cleancall https://github.com/r-lib/cleancall/ On Fri, Apr 17, 2020 at 9:40 AM Dirk Eddelbuettel wrote: > > Jitao, > > Thanks for writing this up. > > You could add a section on 'prior art' and re

[Rd] Allowing S3 methods of rounding functions to take `...`

Hi all, I would like to propose adding `...` to the signatures of the following rounding functions: - floor(x) - ceiling(x) - round(x, digits = 0) - And possibly signif(x, digits = 6) The purpose would be to allow S3 methods to add additional arguments as required. A few arguments in favor of t

Re: [Rd] Allowing S3 methods of rounding functions to take `...`

I should also say that I would be willing to attempt a patch for this, if others agree that this would be useful. - Davis On Thu, Jan 28, 2021 at 9:14 AM Davis Vaughan wrote: > Hi all, > > I would like to propose adding `...` to the signatures of the following > rounding functions:

[Rd] Corrupt internal row names when creating a data.frame with `attributes<-`

Hi all, I believe that the internal row names object created at this line in `row_names_gets()` should be using `-n`, not `n`. https://github.com/wch/r-source/blob/b30641d3f58703bbeafee101f983b6b263b7f27d/src/main/attrib.c#L71 This can currently generate corrupt internal row names when using `att

Re: [Rd] Corrupt internal row names when creating a data.frame with `attributes<-`

row > > names. > > > > so one could argue that it's incorrect in light of that documentation > > (the row names are "automatic", but the row count is not marked with a > > negative sign). Or perhaps this is a different "type" of internal > > a

[Rd] formatC(character()) returns length 1 result, but is documented otherwise

14500255efd622b5021c10ec/src/library/base/R/format.R#L149 Thanks, Davis Vaughan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] as.list.factor() should shift input names onto the resulting list

; [1] "2019-01-01" #> #> $b #> [1] "2019-01-02" # The factor behavior breaks the lapply() invariant that names # of `X` will be propagated onto the result lapply(x, identity) #> [[1]] #> a #> f1 #> Levels: f1 f2 #> #>

[Rd] A potential POSIXlt->Date bug introduced in r-devel

he `as.Date()` conversion seems inconsistent with the `as.POSIXct()` conversion. It looks like this comes up because the conversion to Date now defaults to using `sec` if any of the date-like fields are `NA_INTEGER`, but this means the `NA` in the `mon` field is ignored. https://github.com/wch/r-sou

[Rd] Bug with `[<-.POSIXlt` on specific OSes

Hi all, I have found another POSIXlt bug while I've been fiddling around with it. This one only appears on specific OSes, because it has to do with the fact that the `gmtoff` field is optional, and isn't always used on all OSes. It also doesn't seem to be specific to r-devel, I think it has been t

Re: [Rd] A potential POSIXlt->Date bug introduced in r-devel

AM Martin Maechler wrote: > >>>>> Martin Maechler > >>>>> on Thu, 6 Oct 2022 10:15:29 +0200 writes: > > >>>>> Davis Vaughan > >>>>> on Wed, 5 Oct 2022 17:04:11 -0400 writes: > > >> Hi all, > >

Re: [Rd] Bug with `[<-.POSIXlt` on specific OSes

rameworks/R.framework/Versions/4.2/Resources/lib/libRlapack.dylib locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4

[Rd] Small typo in Writing R Extensions

Hi all, Writing R Extensions describes `R_NewEnv()` as: ``` At times it may also be useful to create a new environment frame in C code. R_NewEnv is a C version of the R function new.env: SEXP R_NewEnv(SEXP enclos, int hash, ins size) ``` There is a typo here where `ins size` should be `int size

[Rd] On optimizing `R_NewEnv()`

Hi all, I really like the addition of `R_NewEnv()` back in 4.1.0 https://github.com/wch/r-source/blob/625ab8d45f86f65561e53627e1f0c220bdc5f752/src/main/envir.c#L3619-L3630 I have a use case where I'm likely to call this function a large number of times to generate many small hashed environments,

[Rd] An alternative algorithm for `which()`

of `x` is `TRUE`, then the i+1-th element might also be `TRUE`. I've received a few comments on the bugzilla page, but I'd love it if anyone else could chime in and provide their own thoughts! Thanks, Davis Vaughan __ R-devel@r-project.org mailing

[Rd] Possible inconsistency between `as.complex(NA_real_)` and the docs

It does seem to be the case for `NA_integer_` x <- as.complex(NA_integer_) Re(x) #> [1] NA Im(x) #> [1] NA ``` Thanks, Davis Vaughan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] range() for Date and POSIXct could respect `finite = TRUE`

quot;2019-01-14" ``` It seems like one option is to create a `range.Date()` method that unclasses, forwards the arguments on to a second call to `range()`, and then reclasses? ``` range.Date <- function(x, ..., na.rm = FALSE, finite = FALSE) { .Date(range(unclass(x), na.rm = na.rm, finite = finite), oldClass(x)) } ``` This is similar to how `rep.Date()` works. Thanks, Davis Vaughan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] range() for Date and POSIXct could respect `finite = TRUE`

`finite`. Because `is.numeric.Date()` is defined, that always returns `FALSE` for Dates (and POSIXt). Because of that, it may still be easier to just write a specific `range.Date()` method, but I'm not sure. -Davis On Sat, Apr 29, 2023 at 4:47 PM Martin Maechler wrote: > > >>>&g

Re: [Rd] range() for Date and POSIXct could respect `finite = TRUE`

developers to also use the pattern of: ``` if (allows.infinite(x)) { # conditionally do stuff with is.infinite(x) } ``` and that seems like it could be rather nice. It would avoid the need for `range.Date()` and `range.POSIXct()` methods too. -Davis On Thu, May 4, 2023 at 5:29 AM

[Rd] Should `expand.grid()` consistently drop `NULL` inputs?

Hi all, I noticed that `expand.grid()` has somewhat inconsistent behavior with dropping `NULL` inputs. In particular, if there is a leading `NULL`, then it ends up as a column in the resulting data frame, which seems pretty undesirable. Also, notice in the last example that `Var3` is used as the c

[Rd] `as.data.frame.matrix()` can produce a data frame without a `names` attribute

lected # This is weird! df <- as.data.frame(matrix(nrow = 0, ncol = 0)) df[1] #> NULL #> <0 rows> (or 0-length row.names) ``` The one exception to requiring a `names` attribute that I can think of is `as.data.frame(optional = TRUE)`, mostly for internal use by `data.frame()