Re: [Rd] as.character.Date() strips names in R 4.3.2 beta, bug?

> Andrew Piskorski > on Tue, 24 Oct 2023 00:01:58 -0400 writes: > In previous versions of R, Not in R 4.3.0 or 4.3.1 {you are a bit late with updating ..}. > as.character.Date() retained any names on > its input vector. In R 4.3.2 beta, it removes names. Is

[Rd] as.character.Date() strips names in R 4.3.2 beta, bug?

In previous versions of R, as.character.Date() retained any names on its input vector. In R 4.3.2 beta, it removes names. Is this change intentional, or a bug? (For what it's worth, I greatly dislike this change, and hope it gets changed back.) $ grep DESCRIPTION /etc/lsb-release

[Rd] UseMethod forwarding of local variables

UseMethod has since the beginning had the 'feature' that local variables in the generic are added to the environment in which the method body is evaluated. This is documented in ?UseMethod and R-lang.texi, but use of this 'feature' has been explicitly discouraged in R-lang.texi for many years.

[Rd] R 4.3.2 scheduled for October 31

Full schedule available on developer.r-project.org in a short while. -- 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 Priv: pda...@gmail.com

Re: [Rd] About FlexiBLAS in the R-admin docs

R's sources, the latest version hence is always https://svn.r-project.org/R/trunk/doc/manual/R-admin.texi (or "almost always current" at one of its github mirrors ..) Best regards, Martin -- Martin Maechler ETH Zurich and R Core team >> Date: Wed, 27 Sep 2023 15:14:4

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

Great to know this exists in package space! Of course, using re2 validation for a regex to be executed with TRE (via grep*) is just begging for trouble (e.g. [1] suggests re2 is closer to PCRE, [2] says "mostly" PCRE compatible). And overhauling everything to use re2 just for regex validation is

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

Hi Michael, it sounds like you don't want to use a CRAN package for this, but you may try re2, see below. > grepl("(invalid","subject",perl=TRUE) Error in grepl("(invalid", "subject", perl = TRUE) : invalid regular expression '(invalid' In addition: Warning message: In grepl("(invalid",

Re: [Rd] About FlexiBLAS in the R-admin docs

rom: =?UTF-8?Q?I=C3=B1aki_Ucar?= > To: "r-devel@r-project.org" > Subject: [Rd] About FlexiBLAS in the R-admin docs > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi, > > Not sure if this is the right place for this. The "R Install

Re: [Rd] Subset has No Examples for Vector Data

> Rui Barradas > on Tue, 10 Oct 2023 12:17:19 +0100 writes: > Às 11:00 de 10/10/2023, Dario Strbenac via R-devel escreveu: >> Hello, >> >> Could the documentation page for subset gain an example of how to use it for something other than a data frame or matrix? I

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

> Grepping an empty string might work in many cases... That's precisely why a base R offering is important, as a surer way of validating in all cases. To be clear I am trying to directly access the results of tre_regcomp(). > it is probably more portable to simply be prepared to propagate such

Re: [Rd] Subset has No Examples for Vector Data

Às 11:00 de 10/10/2023, Dario Strbenac via R-devel escreveu: Hello, Could the documentation page for subset gain an example of how to use it for something other than a data frame or matrix? I arrived at random <- LETTERS[rpois(100, 10)] subset(table(random), x > 10) named integer(0) I

[Rd] Subset has No Examples for Vector Data

Hello, Could the documentation page for subset gain an example of how to use it for something other than a data frame or matrix? I arrived at > random <- LETTERS[rpois(100, 10)] > subset(table(random), x > 10) named integer(0) I expected a part of the table to be returned rather than an empty

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

On 10/10/23 01:57, Michael Chirico via R-devel wrote: > It will be useful to package authors trying to validate input which is > supposed to be a valid regular expression. > > As near as I can tell, the only way we can do so now is to run any > regex function and check for the warning and/or

Re: [Rd] FR: valid_regex() to test string validity as a regular expression

On 09/10/2023 7:57 p.m., Michael Chirico via R-devel wrote: It will be useful to package authors trying to validate input which is supposed to be a valid regular expression. As near as I can tell, the only way we can do so now is to run any regex function and check for the warning and/or

[Rd] FR: valid_regex() to test string validity as a regular expression

It will be useful to package authors trying to validate input which is supposed to be a valid regular expression. As near as I can tell, the only way we can do so now is to run any regex function and check for the warning and/or condition to bubble up: valid_regex <- function(str) {

Re: [Rd] Bug report: parLapply with capture.output(type="message") produces an error

Hi Travers, This is an implementation detail for background workers in general, in that there must be some robust way for them to exit (either upon a signal from the main session, or if the main session ends / socket disconnects). As these are background workers, their error messages are

Re: [Rd] Bug report: parLapply with capture.output(type="message") produces an error

Hi Henrik, Thanks for the detailed technical explanation! I ended up using the withCallingHandlers solution to achieve what I needed (thanks to stack overflow). If this is not technically a bug I think it is unintuitive and unexpected behavior from a user perspective. So take this as a feature

Re: [Rd] Bug report: parLapply with capture.output(type="message") produces an error

This is actually not a bug. If we really want to identify a bug, then it's actually a bug in your code. We'll get to that at the very end. Either way, it's an interesting report that reveals a lot of things. First, here's a slightly simpler version of your example: $ Rscript --vanilla -e

[Rd] Bug report: parLapply with capture.output(type="message") produces an error

Hello, I have tested this on a fresh ubuntu image with R 4.3.1. Rscript -e 'library(parallel) cl = makeCluster(2) x = parLapply(cl, 1:100, function(i) { capture.output(message("hello"), type = "message") }) print("bye")' This produces the following output: [1] "bye" Error in

Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.

> Ivan Krylov writes: Thanks: committed now. Best -k > Dear Rolf, > (Moving this one to R-devel...) > On Sun, 1 Oct 2023 21:01:13 + > Rolf Turner wrote: >> I *really* think that the instructions from CRAN could have been >> clearer! Without your guidance I'd have been at a total

Re: [Rd] as(, "dgTMatrix")' is deprecated.

Hi Martin, On 10/3/23 10:17, Martin Maechler wrote: >> Duncan Murdoch >> on Tue, 3 Oct 2023 12:59:10 -0400 writes: > > On 03/10/2023 12:50 p.m., Koenker, Roger W wrote: > >> I’ve been getting this warning for a while now (about > >> five years if memory serves) and I’m

Re: [Rd] as(, "dgTMatrix")' is deprecated.

thanks, good to know, although at my age this is the sort of knowledge that has a very short half-life. ;-) R > On Oct 4, 2023, at 9:57 AM, Mikael Jagan wrote: > > > There is a call to mosek and I assumed that this wasn’t going to be helpful > > for most R-devel recipients. I tried

Re: [Rd] as(, "dgTMatrix")' is deprecated.

> There is a call to mosek and I assumed that this wasn’t going to be helpful for most R-devel recipients. I tried Duncan’s very reasonable suggestion about options() but it didn’t produce the desired error, so perhaps this isn’t really a warning but something else??? > The details are

Re: [Rd] as(, "dgTMatrix")' is deprecated.

Thanks, Ivan, I should have had the initiative to do this myself. I’ve now written to the Mosek folks in the hope that they will update this in Rmosek. Best Roger > On Oct 3, 2023, at 8:47 PM, Ivan Krylov wrote: > > On Tue, 3 Oct 2023 16:50:55 + > "Koenker, Roger W" wrote: > >> I

Re: [Rd] Problems caused by dev.off() behaviour

Just pointing out that if you do not want to SEE an error message that is otherwise harmless, one option in R is to let the error happen but arrange to deal with it in some way including just suppressing the message. On Tue, Oct 3, 2023, 5:27 AM Duncan Murdoch wrote: > On 02/10/2023 10:17 p.m.,

Re: [Rd] as(, "dgTMatrix")' is deprecated.

On Tue, 3 Oct 2023 16:50:55 + "Koenker, Roger W" wrote: > I thought it might come from Rmosek, but mosek folks don’t think so. I downloaded the Rmosek source package using download.packages( 'Rmosek', '.', repos='https://download.mosek.com/R/10.1' ) ...and there are the deprecated

Re: [Rd] as(, "dgTMatrix")' is deprecated.

There is a call to mosek and I assumed that this wasn’t going to be helpful for most R-devel recipients. I tried Duncan’s very reasonable suggestion about options() but it didn’t produce the desired error, so perhaps this isn’t really a warning but something else??? For those who might have

Re: [Rd] as(, "dgTMatrix")' is deprecated.

> Duncan Murdoch > on Tue, 3 Oct 2023 12:59:10 -0400 writes: > On 03/10/2023 12:50 p.m., Koenker, Roger W wrote: >> I’ve been getting this warning for a while now (about >> five years if memory serves) and I’m finally tired of it, >> but also too tired to track it

Re: [Rd] as(, "dgTMatrix")' is deprecated.

On 03/10/2023 12:50 p.m., Koenker, Roger W wrote: I’ve been getting this warning for a while now (about five years if memory serves) and I’m finally tired of it, but also too tired to track it down in Matrix. As far as I can grep I have no reference to either deprecated object, only the

[Rd] as(, "dgTMatrix")' is deprecated.

I’ve been getting this warning for a while now (about five years if memory serves) and I’m finally tired of it, but also too tired to track it down in Matrix. As far as I can grep I have no reference to either deprecated object, only the apparently innocuous Matrix::Matrix(A, sparse = TRUE).

Re: [Rd] [External] On PRINTNAME() encoding, EncodeChar(), and being painted into a corner

Dear Luke Tierney, Thank you for the reply and apologies for not getting back to you earlier. On Fri, 22 Sep 2023 16:14:58 -0500 (CDT) luke-tier...@uiowa.edu wrote: > I think it would be best to modify errorcall so errorcall_cpy is not > necessary. As things are now it is just too easy to

Re: [Rd] Problems caused by dev.off() behaviour

On 02/10/2023 10:17 p.m., Trevor Davis wrote: > Thanks!  However, isn't length(dev.list()) == 0 when there are no devices?  That's what I'm seeing on MacOS. Ifthere is only one graphics device then R should automatically set it as the active graphics device so it isn't really necessary to

Re: [Rd] After package update, old S4 method is dispatched

Simon, Many thanks for your advice! The issue was that another package was inheriting from the "mirt" class in question. Apparently, some methods are cached at build time (is this documented anywhere?). After reinstalling the package that extends the "mirt" class, the proper method is now being

Re: [Rd] Problems caused by dev.off() behaviour

> Thanks! However, isn't length(dev.list()) == 0 when there are no devices? That's what I'm seeing on MacOS. If there is only one graphics device then R should automatically set it as the active graphics device so it isn't really necessary to manually set it. Although there wouldn't be any

Re: [Rd] Problems caused by dev.off() behaviour

Thanks! However, isn't length(dev.list()) == 0 when there are no devices? That's what I'm seeing on MacOS. Duncan Murdoch On 02/10/2023 4:21 p.m., Trevor Davis wrote: > Use it just like dev.off(), but it *will* restore the previous device. I'm observing that if there were no previously

Re: [Rd] Problems caused by dev.off() behaviour

> Use it just like dev.off(), but it *will* restore the previous device. I'm observing that if there were no previously open graphics devices then your `safe.dev.off()` opens up a new graphics device which may be an undesired side effect (because "surprisingly" `dev.set()` on the null graphics

[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

Re: [Rd] After package update, old S4 method is dispatched

Jan, have you re-installed all packages? If you change (update) any package that uses S4 it may be necessary to re-install all its reverse-dependencies as well since they may include cached values in their namespaces, so the easiest is to make sure you re-install all packages. Cheers, Simon

[Rd] Problems caused by dev.off() behaviour

I found some weird behaviour and reported it as https://bugs.r-project.org/show_bug.cgi?id=18604 and https://github.com/yihui/knitr/issues/2297, but it turns out it was user error. The dev.off() function was behaving as documented, but it behaves in an unexpected (by me) way, and that caused

Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.

Dear Ivan I was bitten by this recently but fortunately Rolf had beaten me to writing a question. The one thing which really surprised me is that the current message tells me how much space it would have saved if it had compressed the files in which case my immediate response was "Well, why

[Rd] After package update, old S4 method is dispatched

Hello R-devel, I hope that you are all doing well and that this is the right place to discuss my somewhat mysterious issue with S4. On our Ubuntu server, we have "mirt" package installed which defines S4 method for "coef" standard generic. We updated the package with the usual

Re: [Rd] [R-pkg-devel] Problem with "compacting" pdf files.

Dear Rolf, (Moving this one to R-devel...) On Sun, 1 Oct 2023 21:01:13 + Rolf Turner wrote: > I *really* think that the instructions from CRAN could have been > clearer! Without your guidance I'd have been at a total loss. Since the CRAN e-mails quote the R CMD check messages verbatim,

Re: [Rd] Use of `[` with array and resulting class

Às 17:33 de 29/09/2023, Joseph Wood escreveu: Hello, I recently discovered a possible inconsistency with usage of an object of class array. Consider the following example: ## Setup a <- array(1:6, dim = c(1, 3, 2)) a , , 1 [,1] [,2] [,3] [1,]123 , , 2 [,1] [,2]

Re: [Rd] Use of `[` with array and resulting class

Hi Joseph This behaviour is as expected (and as documented by ?`[`) because the default of drop=TRUE coerces the result to the lowest possible dimension, which in your case is a vector rather than array. Using for example: b[1,,,drop=FALSE] ... results in an output array with the same number

Re: [Rd] Use of `[` with array and resulting class

This is due to `[` dropping dimensions by default. In your first example, think of a[1, , ] as having dimension c(1, 3, 2), but, because drop = TRUE, all dimensions of extent 1 (the first dimension) are dropped and the result has dimension c(3, 2). In your second example, b[1, , ] would have

[Rd] Use of `[` with array and resulting class

Hello, I recently discovered a possible inconsistency with usage of an object of class array. Consider the following example: ## Setup a <- array(1:6, dim = c(1, 3, 2)) a , , 1 [,1] [,2] [,3] [1,]123 , , 2 [,1] [,2] [,3] [1,]456 class(a) [1] "array"

Re: [Bioc-devel] [Rd] is.atomic(NULL) will become FALSE

Thanks Martin for the heads-up. H. On 9/26/23 09:06, Martin Maechler wrote: > I've sent a longish post to the R-devel mailing list with this > topic here: > https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html > > In the mean time, the plan is to effectuate the change in >

Re: [Rd] Recent changes to as.complex(NA_real_)

> Martin Maechler > on Thu, 28 Sep 2023 12:11:27 +0200 writes: > Gregory R Warnes > on Sat, 23 Sep 2023 13:22:35 -0400 writes: > > It sounds like we need to add arguments (with sensible > > defaults) to complex(), Re(), Im(), is.na.complex() etc to > > allow

Re: [Rd] Recent changes to as.complex(NA_real_)

> Gregory R Warnes > on Sat, 23 Sep 2023 13:22:35 -0400 writes: > It sounds like we need to add arguments (with sensible > defaults) to complex(), Re(), Im(), is.na.complex() etc to > allow the user to specify the desired behavior. I don't think I'd like such extra

Re: [Rd] Minor bug with stats::isoreg

> Ivan Krylov > on Thu, 28 Sep 2023 00:59:57 +0300 writes: > В Wed, 27 Sep 2023 13:49:58 -0700 Travers Ching > пишет: >> Calling isoreg with an Inf value causes a segmentation >> fault, tested on R 4.3.1 and R 4.2. A reproducible >> example is:

Re: [Rd] Minor bug with stats::isoreg

В Wed, 27 Sep 2023 13:49:58 -0700 Travers Ching пишет: > Calling isoreg with an Inf value causes a segmentation fault, tested > on R 4.3.1 and R 4.2. A reproducible example is: `isoreg(c(0,Inf))` Indeed, the code in src/library/stats/src/isoreg.c contains the following loop: do {

Re: [Rd] Minor bug with stats::isoreg

Thanks! Submitted as https://bugs.r-project.org/show_bug.cgi?id=18603 On 2023-09-27 4:49 p.m., Travers Ching wrote: Hello, I'd like to file a small bug report. I searched and didn't find a duplicate report. Calling isoreg with an Inf value causes a segmentation fault, tested on R 4.3.1

[Rd] Minor bug with stats::isoreg

Hello, I'd like to file a small bug report. I searched and didn't find a duplicate report. Calling isoreg with an Inf value causes a segmentation fault, tested on R 4.3.1 and R 4.2. A reproducible example is: `isoreg(c(0,Inf))` [[alternative HTML version deleted]]

[Rd] About FlexiBLAS in the R-admin docs

Hi, Not sure if this is the right place for this. The "R Installation and Administration" guide states: > Apparently undocumented: FlexiBLAS on Fedora provides a complete LAPACK, but > not the enhanced routines from ATLAS or OpenBLAS. I'm not sure what this means. FlexiBLAS does provide 100%

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

On Tue, 26 Sep 2023 12:39:57 +1300 Paul Murrell wrote: > Yes, you can set up your own font and TeX installations are a good > source of Type 1 fonts. Here is an example (paths obviously specific > to my [Ubuntu 20.04] OS and TeX installation) ... Many thanks for the explanation! Your example

[Rd] Crashes and other problems uncovered by static analysis

Hello R-devel, I've been trying to see if static analysers could have caught PR18602. Surprisingly, the analysers I've tried don't seem to notice it, but they do uncover other problems. While most of these either stem from slightly too defensive programming ("condition is always true/false"

Re: [Rd] Tight bounding box around text in graphics?

I think this is a `ragg` device bug, so I've posted an issue there: https://github.com/r-lib/ragg/issues/143 . That issue contains slightly more detail than I included in the earlier message here. Duncan Murdoch __ R-devel@r-project.org mailing

Re: [Bioc-devel] [Rd] is.atomic(NULL) will become FALSE

I've sent a longish post to the R-devel mailing list with this topic here: https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html In the mean time, the plan is to effectuate the change in R-devel (the in-development version of R) on Sep.28, ~ 9:30 CEST ( =UTC+2) AFAIK, this will

Re: [R-pkg-devel] [Rd] is.atomic(NULL) will become FALSE

I've sent a longish post to the R-devel mailing list with this topic here: https://stat.ethz.ch/pipermail/r-devel/2023-September/082892.html In the mean time, the plan is to effectuate the change in R-devel (the in-development version of R) on Sep.28, ~ 9:30 CEST ( =UTC+2) Martin

Re: [Rd] Tight bounding box around text in graphics?

I've done some exploring, and things aren't working out as I would have expected. Here's an example: library(grid) library(ragg) agg_png("test.png") pushViewport(viewport(gp = gpar(cex = 5))) y <- c(0.2, 0.4, 0.6) texts <- c("東京", "Tokyo", "Tokyo 東京")

Re: [Rd] Tight bounding box around text in graphics?

Thanks! I said "base graphics" in my question, but I really have no objection to using grid graphics, so I'll explore those grid functions. Duncan Murdoch On 25/09/2023 3:53 p.m., Paul Murrell wrote: Hi strheight(), which is based GEStrHeight(), is pretty crude, not only ignoring

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

Hi Yes, you can set up your own font and TeX installations are a good source of Type 1 fonts. Here is an example (paths obviously specific to my [Ubuntu 20.04] OS and TeX installation) ... cmlgc <- Type1Font("cmlgc", rep("/usr/share/texlive/texmf-dist/fonts/afm/public/cm-lgc/fcmr6z.afm",

Re: [Rd] Tight bounding box around text in graphics?

Hi strheight(), which is based GEStrHeight(), is pretty crude, not only ignoring descenders, but also only considering the ascent of the overall font (capital "M"). There is a GEStrMetric(), which returns character-specific ascent and descent, but that is only currently exposed via

[Rd] Tight bounding box around text in graphics?

I've mentioned in previous messages that I'm trying to redo rgl text. Part of what I need is to measure the size of strings in pixels when they are drawn by base graphics. It appears that strwidth(texts, "user", cex = cex, font = font, family = family) gives accurate measurements of the

Re: [Rd] Recent changes to as.complex(NA_real_)

On 9/25/23 07:05, Martin Maechler wrote: >> Hervé Pagès >> on Sat, 23 Sep 2023 16:52:21 -0700 writes: > > Hi Martin, > > On 9/23/23 06:43, Martin Maechler wrote: > >>> Hervé Pagès > >>> on Fri, 22 Sep 2023 16:55:05 -0700 writes: > >> > The problem is

[Rd] is.atomic(NULL) will become FALSE

Some of you may remember posts and/or e-mails about this topic many months ago.. "Atomic vector" is a very well defined term for somewhat advanced R users. E.g., from 'The R Language Manual' (in the development version; i.e. made from latest R source code):

Re: [Rd] Recent changes to as.complex(NA_real_)

> Hervé Pagès > on Sat, 23 Sep 2023 16:52:21 -0700 writes: > Hi Martin, > On 9/23/23 06:43, Martin Maechler wrote: >>> Hervé Pagès >>> on Fri, 22 Sep 2023 16:55:05 -0700 writes: >> > The problem is that you have things that are >> > **semantically**

Re: [Rd] NROW and NCOL on NULL

> Simone Giannerini > on Sun, 24 Sep 2023 16:57:00 +0200 writes: > Thank you for your comment, On Sat, Sep 23, 2023 at > 9:51 PM Ben Bolker wrote: >> >> This is certainly worth discussing, but there's always a >> heavy burden of back-compatibility; how much

Re: [Rd] Help requested: writing text to a raster in memory

Since I'm working with Paul on the glyph changes to the R graphics engine I'm quite interested in this so I had the idea to take out the guts from my Cairo package into a self-contained C code. Your request is good to bump is up on my stack. I already have code that draws text into OpenGL

Re: [Rd] Help requested: writing text to a raster in memory

I'm somewhat aware of how tricky it all is. For now I'm going to do it in R (usng textshaping for layout and base graphics on the ragg::agg_capture device to draw to the bitmap). I'll avoid allowing changes to happen in the C++ code. Eventually I'll see if I can translate the code into C++.

Re: [Rd] Help requested: writing text to a raster in memory

Duncan, drawing text is one of the most complicated things you can do, so it really depends how for you want to go. You can do it badly with a simple cairo show_text API. The steps involved in doing it properly are detecting the direction of the language, finding fonts, finding glyphs

[Rd] Suggestion: User defined sampling

Hi everybody, Currently one can alter R's random number generation via RNGkind() in three aspects: the RNG itself, the method for drawing from the normal distribution and the method for generating integers within a range. For the first and second aspect it is possible to supply user defined

Re: [Rd] NROW and NCOL on NULL

Thank you for your comment, On Sat, Sep 23, 2023 at 9:51 PM Ben Bolker wrote: > > This is certainly worth discussing, but there's always a heavy > burden of back-compatibility; how much better would it be for NCOL and > NROW to both return zero, vs. the amount of old code that would be

Re: [Rd] Recent changes to as.complex(NA_real_)

Hi Martin, On 9/23/23 06:43, Martin Maechler wrote: >> Hervé Pagès >> on Fri, 22 Sep 2023 16:55:05 -0700 writes: > > The problem is that you have things that are > > **semantically** different but look exactly the same: > > > They look the same: > > >> x > >

Re: [Rd] NROW and NCOL on NULL

On 23/09/2023 3:41 p.m., Simone Giannerini wrote: I know it's documented and I know there are other ways to guard against this behaviour, once you know about this. The point is whether it might be worth it to make NCOL and NROW return the same value on NULL and make R more consistent/intuitive

Re: [Rd] NROW and NCOL on NULL

Às 20:41 de 23/09/2023, Simone Giannerini escreveu: I know it's documented and I know there are other ways to guard against this behaviour, once you know about this. The point is whether it might be worth it to make NCOL and NROW return the same value on NULL and make R more consistent/intuitive

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

On Wed, 20 Sep 2023 12:39:50 +0200 Martin Maechler wrote: > The problem is that some pdf *viewers*, > notably `evince` on Fedora Linux, for several years now, > do *not* show *some* of the UTF-8 glyphs because they do not use > the correct fonts One more problem that makes it nontrivial to use

Re: [Rd] NROW and NCOL on NULL

This is certainly worth discussing, but there's always a heavy burden of back-compatibility; how much better would it be for NCOL and NROW to both return zero, vs. the amount of old code that would be broken? Furthermore, the reason for this behaviour is justified as consistency with the

Re: [Rd] NROW and NCOL on NULL

I know it's documented and I know there are other ways to guard against this behaviour, once you know about this. The point is whether it might be worth it to make NCOL and NROW return the same value on NULL and make R more consistent/intuitive and possibly less error prone. Regards, Simone On

[Rd] Help requested: writing text to a raster in memory

I am in the process of updating the rgl package. One thing I'd like to do is to change text support in it when using OpenGL to display to be more like the way text is drawn in WebGL displays (i.e. the ones rglwidget() produces). Currently in R, rgl uses the FTGL library to draw text. That

Re: [Rd] NROW and NCOL on NULL

It's been documented for a long time that NCOL(NULL) is 1. What particular problems did you have in mind? There might be other ways to guard against them. Duncan Murdoch On 23/09/2023 1:43 p.m., Simone Giannerini wrote: Dear list, I do not know what would be the 'correct' answer to the

[Rd] NROW and NCOL on NULL

Dear list, I do not know what would be the 'correct' answer to the following but I think that they should return the same value to avoid potential problems and hard to debug errors. Regards, Simone --- > NCOL(NULL) [1] 1 > NROW(NULL) [1] 0 > sessionInfo()

Re: [Rd] Recent changes to as.complex(NA_real_)

It sounds like we need to add arguments (with sensible defaults) to complex(), Re(), Im(), is.na.complex() etc to allow the user to specify the desired behavior. -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On Sep 23, 2023, at 12:37 PM, Mikael Jagan wrote:

Re: [Rd] Recent changes to as.complex(NA_real_)

On 2023-09-23 9:43 am, Martin Maechler wrote: Hervé Pagès on Fri, 22 Sep 2023 16:55:05 -0700 writes: > The problem is that you have things that are > **semantically** different but look exactly the same: > They look the same: >> x > [1] NA >> y >

Re: [Rd] Recent changes to as.complex(NA_real_)

> Hervé Pagès > on Fri, 22 Sep 2023 16:55:05 -0700 writes: > The problem is that you have things that are > **semantically** different but look exactly the same: > They look the same: >> x > [1] NA >> y > [1] NA >> z > [1] NA >> is.na(x)

Re: [Rd] Recent changes to as.complex(NA_real_)

On 9/22/23 16:55, Hervé Pagès wrote: > The problem is that you have things that are **semantically** > different but look exactly the same: > > They look the same: > > > x > [1] NA > > y > [1] NA > > z > [1] NA > > > is.na(x) > [1] TRUE > > is.na(y) > [1] TRUE > > is.na(z) > [1] TRUE > > >

Re: [Rd] Recent changes to as.complex(NA_real_)

The problem is that you have things that are **semantically** different but look exactly the same: They look the same: > x [1] NA > y [1] NA > z [1] NA > is.na(x) [1] TRUE > is.na(y) [1] TRUE > is.na(z) [1] TRUE > str(x)  cplx NA > str(y)  num NA > str(z)  cplx NA but they are

Re: [Rd] Recent changes to as.complex(NA_real_)

Perhaps I shouldn't comment without having read the entire thread, but I will: I can envision situations where I might want, e.g., 2 from complex(r=2, i=NA_real_). Spencer Graves On 9/22/23 3:43 PM, Duncan Murdoch wrote: Since the result of is.na(x) is the same on each of

Re: [Rd] [External] On PRINTNAME() encoding, EncodeChar(), and being painted into a corner

Thanks for looking into this! On Mon, 18 Sep 2023, Ivan Krylov wrote: Hello R-devel, I have originally learned about this from the following GitHub issue: . In short, in various places of the R source code, symbol names are accessed

Re: [Rd] Recent changes to as.complex(NA_real_)

Since the result of is.na(x) is the same on each of those, I don't see a problem. As long as that is consistent, I don't see a problem. You shouldn't be using any other test for NA-ness. You should never be expecting identical() to treat different types as the same (e.g. identical(NA,

Re: [Rd] Recent changes to as.complex(NA_real_)

We could also question the value of having an infinite number of NA representations in the complex space. For example all these complex values are displayed the same way (as NA), are considered NAs by is.na(), but are not identical or semantically equivalent (from an Re() or Im() point of

Re: [Rd] Recent changes to as.complex(NA_real_)

On 2023-09-22 6:38 am, Martin Maechler wrote: Mikael Jagan on Thu, 21 Sep 2023 00:47:39 -0400 writes: > Revisiting this thread from April: > https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html > where the decision (not yet backported) was made for >

Re: [Rd] Recent changes to as.complex(NA_real_)

> Mikael Jagan > on Thu, 21 Sep 2023 00:47:39 -0400 writes: > Revisiting this thread from April: > https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html > where the decision (not yet backported) was made for > as.complex(NA_real_) to give NA_complex_

[Rd] Recent changes to as.complex(NA_real_)

Revisiting this thread from April: https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html where the decision (not yet backported) was made for as.complex(NA_real_) to give NA_complex_ instead of complex(r=NA_real_, i=0), to be consistent with help("as.complex") and as.complex(NA) and

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

Hi The problem is what "supports UNICODE" means. Graphics devices have a 'hasTextUTF8' boolean to indicate that ... /* Some devices can plot UTF-8 text directly without converting to the native encoding, e.g. windows(), quartz() If this flag is true, all text *not in the

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

> However, pdf() *does* support Unicode. When I run a simple Unicode example like: ``` f <- tempfile(fileext = ".pdf") pdf(f) # U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans, Arimo, etc. # However, it is not in the Latin-1 encoding grid::grid.text("\u2665") dev.off()

Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device

> Trevor Davis > on Thu, 31 Aug 2023 13:49:03 -0700 writes: > Hi, > It would be nice if `grDevices::dev.capabilities()` could also be used to > query whether the current graphics device supports Unicode. In such a case > I'd expect it to return `FALSE` if `pdf()`

Re: [Rd] Strange behaviour of do.call()

Le 19/09/2023 à 16:44, Duncan Murdoch a écrit : The knitr::kable() function does some internal setup, including determining the target format, and then calls an internal function using   do.call(paste("kable", format, sep = "_"), list(x = x,     caption = caption, escape = escape, ...)) I

Re: [Rd] Strange behaviour of do.call()

Sorry, it's a silly thinko. I misspelled the vline argument. Thanks Ivan for the gentle nudge! Duncan Murdoch On 19/09/2023 10:44 a.m., Duncan Murdoch wrote: The knitr::kable() function does some internal setup, including determining the target format, and then calls an internal function

[Rd] Strange behaviour of do.call()

The knitr::kable() function does some internal setup, including determining the target format, and then calls an internal function using do.call(paste("kable", format, sep = "_"), list(x = x, caption = caption, escape = escape, ...)) I was interested in setting the `vlign` argument

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