Re: [Rd] [External] Re: zapsmall(x) for scalar x

Thanks for sharing, Martin. You're right that the interface for mFUN should be more general than I initially thought.* Perhaps you have other cases/examples where the ina argument is useful, in which case ignore me, but your example with the robust mFUN doesn't use the ina argument. What about

Re: [Rd] Partial matching performance in data frame rownames using [

Hi Hilmar and Ivan, I have used your code examples to write a blog post about this topic, which has figures that show the asymptotic time complexity of the various approaches, https://tdhock.github.io/blog/2023/df-partial-match/ The asymptotic complexity of partial matching appears to be quadratic

Re: [Rd] Partial matching performance in data frame rownames using [

Hi Hilmar and Ivan, I have used your code examples to write a blog post about this topic, which has figures that show the asymptotic time complexity of the various approaches, https://tdhock.github.io/blog/2023/df-partial-match/ The asymptotic complexity of partial matching appears to be quadratic

Re: [Rd] tools:: extracting pkg dependencies from DCF

Hello all, Following up on this old thread as I have recently observed, rather a bad practice (maintaining order of installation for R packages rather than relying on R for that), for solving a problem that R branch tools4pkgs (mentioned in this email) addresses very well. More details can be

Re: [Rd] [External] Re: zapsmall(x) for scalar x

> Steve Martin > on Mon, 18 Dec 2023 07:56:46 -0500 writes: > Does mFUN() really need to be a function of x and the NA values of x? I > can't think of a case where it would be used on anything but the non-NA > values of x. > I think it would be easier to specify a

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Does mFUN() really need to be a function of x and the NA values of x? I can't think of a case where it would be used on anything but the non-NA values of x. I think it would be easier to specify a different mFUN() (and document this new argument) if the function has one argument and is applied to

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Le 18/12/2023 à 11:24, Martin Maechler a écrit : Serguei Sokol via R-devel on Mon, 18 Dec 2023 10:29:02 +0100 writes: > Le 17/12/2023 à 18:26, Barry Rowlingson a écrit : >> I think what's been missed is that zapsmall works relative to the absolute >> largest value in the

Re: [Rd] [External] Re: zapsmall(x) for scalar x

> Serguei Sokol via R-devel > on Mon, 18 Dec 2023 10:29:02 +0100 writes: > Le 17/12/2023 à 18:26, Barry Rowlingson a écrit : >> I think what's been missed is that zapsmall works relative to the absolute >> largest value in the vector. Hence if there's only one >>

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Le 17/12/2023 à 18:26, Barry Rowlingson a écrit : I think what's been missed is that zapsmall works relative to the absolute largest value in the vector. Hence if there's only one item in the vector, it is the largest, so its not zapped. The function's raison d'etre isn't to replace absolutely

Re: [Rd] [External] Re: zapsmall(x) for scalar x

Sorry for being unclear. I was commenting on the edge case that Gregory brought up when calling zapsmall() with a vector of small values. I thought Gregory was asking for thoughts on that as well, but maybe I misunderstood. IMO it would be weird for zapsmall() to make a small scalar zero but not a

Re: [Rd] [External] Re: zapsmall(x) for scalar x

I think what's been missed is that zapsmall works relative to the absolute largest value in the vector. Hence if there's only one item in the vector, it is the largest, so its not zapped. The function's raison d'etre isn't to replace absolutely small values, but small values relative to the

Re: [Rd] zapsmall(x) for scalar x

I'm really confused. Steve's example wasn't a scalar x, it was a vector. Your zapsmall() proposal wouldn't zap it to zero, and I don't see why summary() would if it was using your proposal. Duncan Murdoch On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote: Isn’t that the correct outcome?

Re: [Rd] zapsmall(x) for scalar x

Isn’t that the correct outcome? The user can change the number of digits if they want to see small values… -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On Dec 17, 2023, at 12:11 AM, Steve Martin wrote: > > Zapping a vector of small numbers to zero would

Re: [Rd] zapsmall(x) for scalar x

Zapping a vector of small numbers to zero would cause problems when printing the results of summary(). For example, if zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then print(summary(2.220446e-16), digits = 7) would print Min. 1st Qu. MedianMean 3rd Qu.Max. 0

[Rd] zapsmall(x) for scalar x

I was quite suprised to discover that applying `zapsmall` to a scalar value has no apparent effect. For example: > y <- 2.220446e-16 > zapsmall(y,) [1] 2.2204e-16 I was expecting zapsmall(x)` to act like > round(y, digits=getOption('digits')) [1] 0 Looking at the current source code,

Re: [Rd] Partial matching performance in data frame rownames using [

On Wed, 13 Dec 2023 09:04:18 +0100 Hilmar Berger via R-devel wrote: > Still, I feel that default partial matching cripples the functionality > of data.frame for larger tables. Changing the default now would require a long deprecation cycle to give everyone who uses `[.data.frame` and relies on

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

Thank you for your answers. Just let me disagree slightly with Tomas view. On 13/12/2023 12:05, Tomas Kalibera wrote: > On 12/13/23 11:27, Duncan Murdoch wrote: >> I doubt if anyone will take you up on this request.  Only R Core >> members can change those manuals, and it's hard work to write

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

On 12/13/23 11:27, Duncan Murdoch wrote: I doubt if anyone will take you up on this request.  Only R Core members can change those manuals, and it's hard work to write clear and correct documentation.  This probably won't make it high enough on their lists of priorities to actually be

Re: [Rd] Request: documenting more specifically language objects in the R Language Definition document

I doubt if anyone will take you up on this request. Only R Core members can change those manuals, and it's hard work to write clear and correct documentation. This probably won't make it high enough on their lists of priorities to actually be addressed. What you could do is try to write it

[Rd] Request: documenting more specifically language objects in the R Language Definition document

Dear all, This is a request to get language objects more documented in the R Language Definition document (CRAN version, ETHZ R-devel version). Section '2.1.3 Language

Re: [Rd] Partial matching performance in data frame rownames using [

Dear Ivan, thanks a lot, that is helpful. Still, I feel that default partial matching cripples the functionality of data.frame for larger tables. Thanks again and best regards Hilmar On 12.12.23 13:55, Ivan Krylov wrote: В Mon, 11 Dec 2023 21:11:48 +0100 Hilmar Berger via R-devel пишет:

Re: [Rd] Partial matching performance in data frame rownames using [

В Mon, 11 Dec 2023 21:11:48 +0100 Hilmar Berger via R-devel пишет: > What was unexpected is that in this case was that [.data.frame was > hanging for a long time (I waited about 10 minutes and then restarted > R). Also, this cannot be interrupted in interactive mode. That's unfortunate. If an

[Rd] Partial matching performance in data frame rownames using [

Dear all, I have seen that others have discussed the partial matching behaviour of data.frame[idx,] in the past, in particular with respect to unexpected results sets. I am aware of the fact that one can work around this using either match() or switching to tibble/data.table or similar

Re: [Rd] Small typo in Sweave.Rnw

> Enrico Schumann writes: Great, thanks: changed now. Best -k > In the first paragraph of Sweave.Rnw > (./src/library/utils/vignettes/Sweave.Rnw), it reads > for literate programming \cite{fla:Knuth:1984}. > but probably should be > for literate programming \citep{fla:Knuth:1984}. >

Re: [Rd] Base R wilcox.test gives incorrect answers, has been fixed in DescTools, solution can likely be ported to Base R

You could request a bugzilla account and post it to https://bugs.r-project.org/ yourself: from https://www.r-project.org/bugs.html, > In order to get a bugzilla account (i.e., become “member”), please send an e-mail (from the address you want to use as your login) to

[Rd] Base R wilcox.test gives incorrect answers, has been fixed in DescTools, solution can likely be ported to Base R

While using the Hodges Lehmann Mean in DescTools (DescTools::HodgesLehmann), I found that it generated incorrect answers (see https://github.com/AndriSignorell/DescTools/issues/97). The error is driven by the existence of tied values forcing

[Rd] Small typo in Sweave.Rnw

In the first paragraph of Sweave.Rnw (./src/library/utils/vignettes/Sweave.Rnw), it reads for literate programming \cite{fla:Knuth:1984}. but probably should be for literate programming \citep{fla:Knuth:1984}. ^ kind regards Enrico -- Enrico

[Rd] capabilities() could report strict-barrier

Hi, I would like to propose for capabilities() function to include information about strict-barrier (--enable-strict-barrier flag). I can now do "grep barrier /usr/local/lib/R/etc/Makeconf" but having that in R, in platform independent way, would be useful. Best Regards, Jan Gorecki

[Rd] option to silence/quieten stats::confint.glm ?

confint.glm prints a message "Waiting for profiling to be done..." I could have sworn that there used to be an option (quiet = TRUE?) to turn this message off without resorting to suppressMessages() (finer/more specific control is always preferable ...) -- but on the basis of looking

Re: [Rd] capture error messages from loading shared objects

Thanks Henrik and Bill, Indeed, but I do have a function called tryCatchWEM() in package admisc that captures all that. My use case was to test for different architectures (for instance, arm64 vs Intel MacOS) embedding R in cross-platform applications. I needed to test if the package could be

Re: [Rd] capture error messages from loading shared objects

Careful; tryCatch() on non-error conditions will break out of what's evaluated, e.g. res <- tryCatch({ cat("1\n") message("2") cat("3\n") 42 }, message = identity) will output '1' but not '3', because it returns as soon as the first message() is called. To "record" messages (same for

Re: [Rd] capture error messages from loading shared objects

If you would like to save the error message instead of suppressing it, you can use tryCatch(message=function(e)e, ...). -BIll On Tue, Nov 28, 2023 at 3:55 AM Adrian Dusa wrote: > Once again, Ivan, many thanks. > Yes, that does solve it. > Best wishes, > Adrian > > On Tue, Nov 28, 2023 at 11:28 

Re: [Rd] capture error messages from loading shared objects

Once again, Ivan, many thanks. Yes, that does solve it. Best wishes, Adrian On Tue, Nov 28, 2023 at 11:28 AM Ivan Krylov wrote: > В Tue, 28 Nov 2023 10:46:45 +0100 > Adrian Dusa пишет: > > > tryCatch(requireNamespace("foobar"), error = function(e) e) > > I think you meant loadNamespace()

Re: [Rd] capture error messages from loading shared objects

В Tue, 28 Nov 2023 10:46:45 +0100 Adrian Dusa пишет: > tryCatch(requireNamespace("foobar"), error = function(e) e) I think you meant loadNamespace() (which throws errors), not requireNamespace() (which internally uses tryCatch(loadNamespace(...)) and may or may not print the error depending on

[Rd] capture error messages from loading shared objects

Fellow R developers, I can capture usual error message using the normal way: > tc <- tryCatch(1 + a, error = function(e) e) > tc However I have troubles capturing the error message from this type of error: > tc <- tryCatch(requireNamespace("foobar"), error = function(e) e) Loading required

Re: [Rd] R test coverage

Hi Jim, Thanks for the info. I disregarded covr in my search results as I thought it would only apply to packages outside base and recommended. The code is pure R code so it might work, but it reads a file so it might involve some C code. Thanks! Lluís On Mon, 27 Nov 2023 at 20:11, Jim Hester

Re: [Rd] R test coverage

It should be possible to use covr to do this, see this old issue (https://github.com/r-lib/covr/issues/59). However interpreting the results can prove challenging as naturally covr uses functions from the base internally. Unfortunately the base and many of the internal and recommended packages

Re: [Rd] Rtools error

On 11/27/23 18:58, Rui Barradas wrote: Às 05:07 de 27/11/2023, Neha gupta escreveu: Hello, I want to download a package and it gives me the error: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 4.2.0 was found. (Only the following incompatible

Re: [Rd] Rtools error

Às 05:07 de 27/11/2023, Neha gupta escreveu: Hello, I want to download a package and it gives me the error: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 4.2.0 was found. (Only the following incompatible version(s) of Rtools were found: 4.3.5550)

[Rd] R test coverage

Hi all, I recently proposed a change in R that has led to the addition of new code to the R source code. The code added, as far as I know, has no tests and it might affect many packages in CRAN. I was wondering if adding a test would be helpful or it is already covered by some other test. Which

Re: [Rd] Rtools error

On 11/27/23 06:07, Neha gupta wrote: Hello, I want to download a package and it gives me the error: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 4.2.0 was found. (Only the following incompatible version(s) of Rtools were found: 4.3.5550) This

[Rd] Rtools error

Hello, I want to download a package and it gives me the error: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 4.2.0 was found. (Only the following incompatible version(s) of Rtools were found: 4.3.5550) Please download and install Rtools 4.2 from

Re: [Rd] More Detail on "Error : vector memory exhausted (limit reached?)"

On 11/27/23 05:42, ivo welch wrote: Would it be possible to enhance this error message? Could the message say how large the limit was that was reached? Is it that the limit for one particular vector has been exceeded (and to how much would it have grown vs. how much was allowed?), or is it

[Rd] More Detail on "Error : vector memory exhausted (limit reached?)"

Would it be possible to enhance this error message? Could the message say how large the limit was that was reached? Is it that the limit for one particular vector has been exceeded (and to how much would it have grown vs. how much was allowed?), or is it that the entire memory space has been

Re: [Rd] tune "checking installed package size" NOTE

Oh, thank you. I only grep WRE. Yes it does work On Fri, Nov 24, 2023 at 12:20 PM Ivan Krylov wrote: > В Fri, 24 Nov 2023 12:15:06 +0100 > Jan Gorecki пишет: > > > Recently we got _R_CHECK_CRAN_INCOMING_TARBALL_THRESHOLD_ env var to > > tune "Size of tarball" note during R package check. > > >

Re: [Rd] tune "checking installed package size" NOTE

В Fri, 24 Nov 2023 12:15:06 +0100 Jan Gorecki пишет: > Recently we got _R_CHECK_CRAN_INCOMING_TARBALL_THRESHOLD_ env var to > tune "Size of tarball" note during R package check. > > Could we get similar one for tuning "checking installed package size" > note? Does _R_CHECK_PKG_SIZES_THRESHOLD_

[Rd] tune "checking installed package size" NOTE

Hello, Recently we got _R_CHECK_CRAN_INCOMING_TARBALL_THRESHOLD_ env var to tune "Size of tarball" note during R package check. Could we get similar one for tuning "checking installed package size" note? We can then fit R CMD check more tightly to our package and track regression in installed

Re: [Rd] Matrix 1.6.2+ versus Matrix 1.6.2-

Thanks Mikael. [I too wondered if this topic was appropriate for the list and in the end thought it might be. We can probably take this offline after this exchange and summarize if appropriate.] The actual source of the package is here:

Re: [Rd] Matrix 1.6.2+ versus Matrix 1.6.2-

Naras, Thanks. I'm a bit confused, because Rmosek does not declare Matrix as a dependency: > tools::package_dependencies("Rmosek", which = "all")[[1L]] [1] "pkgbuild" nor does it contain code needing compilation: > packageDescription("Rmosek", fields="NeedsCompilation") [1]

[Rd] seq edge cases

I think that, if called with |length.out=1|, |seq| and |seq.int| should return |start| - no matter the value of the other parameters. Currently they always return |NaN| / error if called with |by=Inf|, for example. |for (n in 4:0) print(seq(1, by=1/(n-1), length.out=n)) # [1] 1.00

[Rd] Matrix 1.6.2+ versus Matrix 1.6.2-

Package Rmosek compiles fine using Matrix versions 1.6.2- but not with anything beyond Matrix 1.6.2.  (FYI, Rmosek provides R interfaces to the excellent MOSEK solver; academic licenses are free.) Here is the error message: rmsk_obj_matrices.cc:50:9: error: use of undeclared identifier

Re: [Rd] R-4.3 version list.files function could not work correctly in chinese

characters.     https://stackoverflow.com/q/77527167/12685768 Great, thanks! Tomas Mikael On 2023-08-17 6:00 am, r-devel-requ...@r-project.org wrote: Message: 5 Date: Wed, 16 Aug 2023 16:00:13 +0200 From: Tomas Kalibera To: Ivan Krylov Cc:"r-devel@r-project.org"  Subject: Re: [Rd]  R-4

Re: [Rd] R-4.3 version list.files function could not work correctly in chinese

/77527167/12685768 Mikael On 2023-08-17 6:00 am, r-devel-requ...@r-project.org wrote: Message: 5 Date: Wed, 16 Aug 2023 16:00:13 +0200 From: Tomas Kalibera To: Ivan Krylov Cc:"r-devel@r-project.org" Subject: Re: [Rd] R-4.3 version list.files function could not work correctly

Re: [Rd] Regenerate news feeds?

Tim, thanks. I have updated R to the latest R-devel on the machine in the hope that is may help, but I suspect it will only affect new entries as they are generated progressively each day. Cheers, Simon > On Nov 18, 2023, at 11:38 AM, Tim Taylor > wrote: > > The news feeds (e.g. >

[Rd] Regenerate news feeds?

The news feeds (e.g. https://developer.r-project.org/blosxom.cgi/R-devel/NEWS) have some stray "\abbr" floating around. Do they need generating with a more recent version of R-devel? I've run tools::Rd2txt on https://svn.r-project.org/R/trunk/doc/NEWS.Rd and r85550 does seem to remove these

Re: [Rd] system()/system2() using short paths of commands on Windows?

The problem in TeX Live has just been fixed. Now it will expand short names: https://tug.org/pipermail/tex-live/2023-November/049706.html Therefore please feel free to ignore my original request. Thank you! Regards, Yihui -- https://yihui.org On Thu, Nov 16, 2023 at 8:28 AM Tomas Kalibera

Re: [Rd] system()/system2() using short paths of commands on Windows?

On 10/31/23 10:05, Duncan Murdoch wrote: On 31/10/2023 4:32 a.m., Tomas Kalibera wrote: On 10/30/23 19:07, Yihui Xie wrote: Sure. I'm not sure if it's possible to make it easier to reproduce, but for now the example would require installing TinyTeX (via tinytex::install_tinytex(), which can

Re: [Rd] saveRDS()/readRDS() on environments

On Wed, 15 Nov 2023 19:49:00 +0100 Antoine Fabri wrote: > I would like to know what rules are followed, if I had to guess I > would think that parents are saved until a "special environment" is > reached (such as global env, empty env, package envs, namespaces, > imports, datasets), but I'd like

[Rd] saveRDS()/readRDS() on environments

Dear r-devel, I was surprised to see that saveRDS() and readRDS() work quite well with environments, see below: ``` z <- 3 # in global env y <- new.env() y$a <- 1 x <- new.env(parent = y) x$b <- 2 saveRDS(x, "x.RDS") # in a new session x <- readRDS("x.RDS") y <- parent.env(x) x$b #> [1] 2 y$a

Re: [Rd] Segmentation fault early in compilation of revision 85514

On 11/14/23 19:19, Joshua Ulrich wrote: On Mon, Nov 13, 2023 at 12:45 PM Avraham Adler wrote: On Mon, Nov 13, 2023 at 1:13 AM Dirk Eddelbuettel wrote: Avi, Might be toolchain-dependent, might be options-dependent--it built fine here. Easier for you to vary option two so maybe try that?

Re: [Rd] Segmentation fault early in compilation of revision 85514

On Mon, Nov 13, 2023 at 12:45 PM Avraham Adler wrote: > > On Mon, Nov 13, 2023 at 1:13 AM Dirk Eddelbuettel wrote: > > > > > > Avi, > > > > Might be toolchain-dependent, might be options-dependent--it built fine > > here. > > Easier for you to vary option two so maybe try that? > > > > Dirk > >

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 >

Re: [Rd] data.frame weirdness

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

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

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

Re: [Rd] data.frame weirdness

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

[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]),

Re: [Rd] Segmentation fault early in compilation of revision 85514

On Mon, Nov 13, 2023 at 1:13 AM Dirk Eddelbuettel wrote: > > > Avi, > > Might be toolchain-dependent, might be options-dependent--it built fine here. > Easier for you to vary option two so maybe try that? > > Dirk Thank you, Dirk. I think it was more a PEBCAK issue. When I deleted the entire

Re: [Rd] Segmentation fault early in compilation of revision 85514

Avi, Might be toolchain-dependent, might be options-dependent--it built fine here. Easier for you to vary option two so maybe try that? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list

Re: [Rd] Wayland Display Support in R Plot

Hi, following on this topic, having full support for Wayland in R would be great indeed. In the news this week, after GNOME removed X11 support, KDE is doing the same. I really love X11, but maybe it's time to move forward. I've been using GNOME + Wayland for more than a year now, including

[Rd] Segmentation fault early in compilation of revision 85514

When trying to compile R on Windows 10 64-bit using LTO as I always do, I encountered a segmentation fault early in the compilation. I am uncertain as to what it means (please see below for error extract). I am using the most recent version of Rtools43 (5863) and updated its libraries prior to

Re: [Rd] New syntax for positional-only function parameters?

6 ноября 2023 г. 22:54:24 GMT+03:00, mikkmart via R-devel пишет: >The pattern of functions accepting other functions as inputs and >passing additional ... arguments to them is prevalent throughout >the R ecosystem. Currently, however, all such functions must one >way or another tackle the

Re: [Rd] [R] Why Rprofile.site is not built with manual installation of R devel in linux?

Per a: Martin Maechler A/c: Iago Gin� V�zquez ; r-sig-deb...@r-project.org ; r-devel@r-project.org ; Jeff Newmiller Tema: Re: [Rd] [R] Why Rprofile.site is not built with manual installation of R devel in linux? On 10 November 2023 at 14:19, Martin Maechler wrote: | >

Re: [Rd] [R] Why Rprofile.site is not built with manual installation of R devel in linux?

On 10 November 2023 at 14:19, Martin Maechler wrote: | >> 2. In the installed R in /where/you/want/R/to/go, there is no even etc folder, there are only the folders bin, lib and share. That would appear to be an error in the locally installed R. What the package does has been discussed

Re: [Rd] [R] Why Rprofile.site is not built with manual installation of R devel in linux?

> Jeff Newmiller via R-help > on Thu, 09 Nov 2023 12:08:07 -0800 writes: > No clue. Tip: R-devel is the mailing list for anything > related to development versions of R. Off-topic here. Yes. Alternatively, as he uses Debian, there's the R-SIG-Debian mailing list, too. -->

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

On 2023-11-09 3:13 am, Martin Maechler wrote: Mikael Jagan on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first

Re: [Rd] New syntax for positional-only function parameters?

l on behalf of mikkmart via R-devel Date: Monday, November 6, 2023 at 17:41 To: r-devel@r-project.org Subject: [Rd] New syntax for positional-only function parameters? Dear List, I'm writing to gauge interest in new syntax for positional-only function parameters to be added to R. The patter

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

> Mikael Jagan > on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x),

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0)

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

Am 07.11.23 um 23:59 schrieb Sebastian Meyer: This is a known issue already reported to the Rdpack maintainer. In some cases, the Rd code generated by Rdpack's macros contains unnecessary braces that trigger the check note because they match the pattern "text{text}" that dete

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

Am 07.11.23 um 23:00 schrieb Ivan Krylov: On Tue, 7 Nov 2023 17:13:05 +0100 Martin Becker wrote: More specifically, a 'Lost braces' NOTE is issued (at least sometimes) when using the \insertRef{...}{...} command from the Rdpack package. Does anything change if you use the development

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

This is a known issue already reported to the Rdpack maintainer. In some cases, the Rd code generated by Rdpack's macros contains unnecessary braces that trigger the check note because they match the pattern "text{text}" that detects common mistakes like "code{x}"

Re: [Rd] False positives in check for lost braces (in tools::checkRd())

On Tue, 7 Nov 2023 17:13:05 +0100 Martin Becker wrote: > More specifically, a 'Lost braces' NOTE is issued (at least > sometimes) when using the \insertRef{...}{...} command from the > Rdpack package. Does anything change if you use the development version of Rdpack (not currently on CRAN)?

[Rd] False positives in check for lost braces (in tools::checkRd())

Dear developers, while preparing to submit a package to CRAN, I noticed that a check for lost braces in Rd files (which is enabled in the current r-devel when checking with the '--as-cran' option) seems to return false positives. More specifically, a 'Lost braces' NOTE is issued (at least

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

> Michael Chirico > on Mon, 6 Nov 2023 23:18:40 -0800 writes: > Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) > should be, but rather, how I should read code like c(x, y) generally. Till > now, I have thought of it like 'c(x, y)' is c(as(x,

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

l_+0i) > which now differs from > NA_complex > although both print as NA. > I haven't been quite alert when this change was discussed, The discussion was here, at first 1) started by Davis Vaughan on 14 Apr 2023 "[Rd] Possible inconsistency between `as.compl

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) should be, but rather, how I should read code like c(x, y) generally. Till now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when "type(y) > type(x)". Basically in my mind, "coercion" in R <-> as.(.) (or

[Rd] Inconsistency in paired t.test() interface?

Hi all, In the next release of R (4.4) the option to obtain a paired t.test with the formula interface for "long" data has been removed: t.test(x ~ group, paired = TRUE) # now results in an error. Exploring how one might obtain a paired t.test, there seems to be some inconsistency between the

[Rd] New syntax for positional-only function parameters?

Dear List, I'm writing to gauge interest in new syntax for positional-only function parameters to be added to R. The pattern of functions accepting other functions as inputs and passing additional ... arguments to them is prevalent throughout the R ecosystem. Currently, however, all such

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

> Michael Chirico > on Sun, 5 Nov 2023 09:41:42 -0800 writes: > This is another follow-up to the thread from September > "Recent changes to as.complex(NA_real_)". > A test in data.table was broken by the changes for NA > coercion to complex; the breakage essentially

Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was

[Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?

This is another follow-up to the thread from September "Recent changes to as.complex(NA_real_)". A test in data.table was broken by the changes for NA coercion to complex; the breakage essentially comes from c(NA, 0+1i) # vs c(as.complex(NA), 0+1i) The former is the output we tested against;

Re: [Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0

I see. We'll update soon. Thanks Martin. On 11/4/23 06:52, Martin Maechler wrote: >> Hervé Pagès >> on Fri, 3 Nov 2023 15:10:40 -0700 writes: > > Hi list, > > > Here is an example: > > >     hpages@XPS15:~$ R CMD INSTALL CoreGx     * installing > > > >    

Re: [Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0

> Hervé Pagès > on Fri, 3 Nov 2023 15:10:40 -0700 writes: > Hi list, > Here is an example: >     hpages@XPS15:~$ R CMD INSTALL CoreGx     * installing >     hpages@XPS15:~$ R CMD INSTALL CoreGx >     * installing to library

Re: [Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0

Forgot to mention that the package actually got installed, but is unloadable (not surprisingly):     > "CoreGx" %in% rownames(installed.packages())     [1] TRUE     > suppressWarnings(suppressMessages(library(CoreGx)))     Error : in method for ‘updateObject’ with signature

[Rd] 'R CMD INSTALL' keeps going on despite serious errors, and returns exit code 0

Hi list, Here is an example:     hpages@XPS15:~$ R CMD INSTALL CoreGx     * installing to library ‘/home/hpages/R/R-4.4.r85388/site-library’     * installing *source* package ‘CoreGx’ ...     ** using staged installation     ** R     ** data     *** moving datasets to lazyload DB     **

[Rd] svd() of a 30000 by 30000 matrix segfaults: 32-bit length overflow in LAPACK?

Dear Dr. Robert M Flight, dear R-developers, By an accident, I've noticed this problem reported on Mastodon [1]. On a computer with ≥32G of RAM, running the following code (which may take 5 CPU-hours and allocate 27G of RAM!) results in a segfault: n_val <- 3 tmp_matrix <-

Re: [Rd] configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]

On 11/1/23 13:29, Iñaki Ucar wrote: On Wed, 1 Nov 2023 at 12:57, Tomas Kalibera wrote: On 10/31/23 10:45, Iñaki Ucar wrote: On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera wrote: The output of session info is based on that flexiblas is used and on what flexiblas tells R is the backend it

Re: [Rd] dim<-() changed in R-devel; no longer removing "dimnames" when doing dim(x) <- dim(x)

> I assume it did, or you would not have noticed ? I noticed it because I got a notice from CRAN about 'matrixStats' starting to fail on R-devel. It was a non-critical failure, because it was due to how the package tests compare the results to the corresponding base-R implementation. Basically,

Re: [Rd] configure output with flexiblas [was Re: About FlexiBLAS in the R-admin docs]

On Wed, 1 Nov 2023 at 12:57, Tomas Kalibera wrote: > > > On 10/31/23 10:45, Iñaki Ucar wrote: > > On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera > > wrote: > >> The output of session info is based on that flexiblas is used and on > >> what flexiblas tells R is the backend it uses. R does not

<    1   2   3   4   5   6   7   8   9   10   >