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 > > [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 semantically different e.g. > > >> Re(x) > > [1] NA > >> Re(y) > > [1] -0.5 # surprise! > > >> Im(x) # surprise! > > [1] 2 > >> Im(z) > > [1] NA > > > so any expression involving Re() or Im() will produce > > different results on input that look the same on the > > surface. > > > You can address this either by normalizing the internal > > representation of complex NA to always be complex(r=NaN, > > i=NA_real_), like for NA_complex_, or by allowing the > > infinite variations that are currently allowed and at the > > same time making sure that both Re() and Im() always > > return NA_real_ on a complex NA. > > > My point is that the behavior of complex NA should be > > predictable. Right now it's not. Once it's predictable > > (with Re() and Im() both returning NA_real_ regardless of > > internal representation), then it no longer matters what > > kind of complex NA is returned by as.complex(NA_real_), > > because they are no onger distinguishable. > > > H. > > > On 9/22/23 13:43, Duncan Murdoch wrote: > >> 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, NA_real_) is FALSE, as it > >> should be). If you are using a different test, that's > >> user error. > >> > >> Duncan Murdoch > >> > >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: > >>> 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 view): > >>> > >>> NA_real_ + 0i > >>> > >>> complex(r=NA_real_, i=Inf) > >>> > >>> complex(r=2, i=NA_real_) > >>> > >>> complex(r=NaN, i=NA_real_) > >>> > >>> In other words, using a single representation for > >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would > >>> avoid a lot of unnecessary complications and surprises. > >>> > >>> Once you do that, whether as.complex(NA_real_) should > >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_, > >>> i=NA_real_) becomes a moot point. > >>> > >>> Best, > >>> > >>> H. > > Thank you, Hervé. > Your proposition is yet another one, > to declare that all complex NA's should be treated as identical > (almost/fully?) everywhere. > > This would be a possibility, but I think a drastic one. > > I think there are too many cases, where I want to keep the > information of the real part independent of the values of the > imaginary part (e.g. think of the Riemann hypothesis), and > typically vice versa. Use NaN for that, not NA. > > With your proposal, for a (potentially large) vector of complex numbers, > after >Re(z) <- 1/2 > > I could no longer rely on Re(z) == 1/2, > because it would be wrong for those z where (the imaginary part/ the number) > was NA/NaN. My proposal is to do this only if the Re and/or Im parts are NAs, not if they are NaNs. BTW the difference between how NAs and NaNs are treated in complex vectors is another issue that adds to the confusion: > complex(r=NA, i=2) [1] NA > complex(r=NaN, i=2) [1] NaN+2i Not displaying the real + imaginary parts in the NA case kind of suggests that somehow they are gone i.e. that Re(z) and Im(z) are both NA. Note that my proposal is not to change the display but to change Re() and Im() to make them consistent with the display. In your Re(z) <- 1/2 example (which seems to be theoretical only because I don't see `Re<-` in base R), any NA in 'z' would be replaced with complex(r=NaN, i=1/2), so you could rely on Re(z) == 1/2. > Also, in a similar case, a > >Im(z) <- NA > > would have to "destroy" all real parts Re(z); > not really typically in memory, but effectively for the user, Re(z) > would be all NA/NaN. Yes, setting a
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 and possibly less error prone. If you don't list any examples of problems, then the only possible conclusion is that there aren't any except obscure ones, so the answer is clearly that it is not worth it to make this change. Duncan Murdoch Regards, Simone On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: 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 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() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] User defined RNG and code registration.
On Sat, Sep 23, 2023 at 7:30 PM Ivan Krylov wrote: > You're right! Looking at the code, if R_useDynamicSymbols(dll, FALSE) > has been called for a DLL, the branch that calls dlsym() or > GetProcAddress() to find symbols from that library by their shared > object symbol names gets completely disabled; only the registered > function names known to R matter at this point. Thanks Ivan for the investigations! That explains my experiences. > It sounds unsatisfying, but if you register your user_unif_rand > function with the right name and any of the ABIs supported by R, it > sounds like it should work as long as you never call it using the > .Call/.C/.Fortran ABI it's registered for. That is indeed unsatisfying, but looks like the best workaround for now. Ralf __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
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 and possibly less error prone. Regards, Simone On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: 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 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() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 Hello, The way I think of this behavior that made it intuitive is to think that in R matrices are column-major, therefore if length(NULL) == 0 then NULL can be seen as a matrix with one column and zero rows, no data. Here are other examples for which that reasoning works: m <- matrix(integer(0L)) NCOL(m) NROW(m) x <- integer(0L) NCOL(x) NROW(x) Not very convincing? Maybe with time... Hope this helps, Rui Barradas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] User defined RNG and code registration.
On Sat, Sep 23, 2023 at 10:00 AM Duncan Murdoch wrote: > I don't know the answer here, but section 6.16 of WRE suggests that you > could explicitly make your functions visible even if they default to > invisible. Thanks Duncan. Unfortunately at least in my tests the visibility settings did not alter whether R could find these routines. Ralf __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
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 Unicode with pdf() is
the graphics device not knowing some of the font metrics:
x <- '\u410\u411\u412'
pdf()
plot(1:10, main = x)
# Warning messages:
# 1: In title(...) : font width unknown for character 0xb0
# 2: In title(...) : font width unknown for character 0xe4
# 3: In title(...) : font width unknown for character 0xfc
# 4: In title(...) : font width unknown for character 0x7f
dev.off()
In the resulting PDF file, the three letters are visible, at least in
Evince 3.38.2, but they are all positioned in the same space.
I understand that this is strictly speaking not pdf()'s fault
(grDevices contains the font metrics for all standard Adobe fonts and a
few more), but I'm not sure what to do as a user. Should I call
pdfFonts(...), declaring a font with all symbols I need? Where does one
even get Type-1 Cyrillic Helvetica (or any other font) with separate
font metrics files for use with pdf()?
Actually, the wrong number of sometimes random character codes reminds
me of stack garbage. In src/library/grDevices/src/devPS.c, function
static double PostScriptStringWidth, there's this bit of code:
if(!strIsASCII((char *) str) &&
/*
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
(face % 5) != 0) {
R_CheckStack2(strlen((char *)str)+1);
char buff[strlen((char *)str)+1];
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
}
Later the characters in str1 are iterated over in order to calculate
the total width of the string. I didn't notice this myself until I saw
in the debugger that after a few iterations of the loop, the contents
of str1 are completely different from the result of mbcsToSbcs((char
*)str, buff, encoding, enc), and went to investigate. Only after the
debugger told me that there's no variable called "buff" I realised that
the VLA pointed to by str1 no longer exists.
--- src/library/grDevices/src/devPS.c (revision 85214)
+++ src/library/grDevices/src/devPS.c (working copy)
@@ -721,6 +721,8 @@
unsigned char p1, p2;
int status;
+/* May be about to allocate */
+void *alloc = vmaxget();
if(!metrics && (face % 5) != 0) {
/* This is the CID font case, and should only happen for
non-symbol fonts. So we assume monospaced with multipliers.
@@ -755,9 +757,8 @@
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
- (face % 5) != 0) {
- R_CheckStack2(strlen((char *)str)+1);
- char buff[strlen((char *)str)+1];
+ (face % 5) != 0 && metrics) {
+ char *buff = R_alloc(strlen((char *)str)+1, 1);
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
@@ -792,6 +793,7 @@
}
}
}
+vmaxset(alloc);
return 0.001 * sum;
}
After this patch, I'm consistently getting the right character codes in
the warnings, but I still don't know how to set up the font metrics.
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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 behaviour of as.matrix() and cbind() for zero-length vectors, from ?NCOL: ## as.matrix() produces 1-column matrices from 0-length vectors, ## and so does cbind() : (of course you could argue that this behaviour should be changed as well ...) On 2023-09-23 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 and possibly less error prone. Regards, Simone On Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: 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 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() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] A simple question regarding examples
В Thu, 21 Sep 2023 22:11:37 +
Hanyu Song пишет:
> Therefore, I am very surprised that the example below runs overtime,
> since all it has to do is to run
> reticulate::py_module_available('ctef'). If even this part is running
> overtime, I am not quite sure how to deal with it.
Can you show the precise message given to you by the check?
Are you able to reproduce the problem if you run R CMD check (for
example) in a virtual machine without a working Python installation?
It would explain the situation if the process was stuck asking the user
for (e.g.) permission to install miniconda, but these prompts are all
guarded by tests for interactive() and therefore shouldn't be happening.
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
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 Sat, Sep 23, 2023 at 7:50 PM Duncan Murdoch wrote: > > 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 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() > > R version 4.3.1 RC (2023-06-08 r84523 ucrt) > > Platform: x86_64-w64-mingw32/x64 (64-bit) > > Running under: Windows 11 x64 (build 22621) > > > > Matrix products: default > > > > > > locale: > > [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 > > [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C > > [5] LC_TIME=Italian_Italy.utf8 > > > > time zone: Europe/Rome > > tzcode source: internal > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > loaded via a namespace (and not attached): > > [1] compiler_4.3.1 > > > -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] User defined RNG and code registration.
В Sat, 23 Sep 2023 08:42:25 + Ralf Stubner пишет: > ?Random.user describes a way to hook a user- defined > RNG into R. However, it looks like these two things are not > compatible, i.e. `user_unif_rand` et al. are not found, if dynamic > symbols are not allowed. You're right! Looking at the code, if R_useDynamicSymbols(dll, FALSE) has been called for a DLL, the branch that calls dlsym() or GetProcAddress() to find symbols from that library by their shared object symbol names gets completely disabled; only the registered function names known to R matter at this point. > Or can one register these routines somehow even though they are not > following one of the standard calling conventions? It sounds unsatisfying, but if you register your user_unif_rand function with the right name and any of the ABIs supported by R, it sounds like it should work as long as you never call it using the .Call/.C/.Fortran ABI it's registered for. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[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 library is unsupported these days, and uses the old fixed pipeline in OpenGL. In WebGL, text is displayed by "shaders", programs that run on the GPU. Javascript code prepares bitmap images of the text to display, then the shader transfers parts of that bitmap to the output display. I'd like to duplicate the WebGL process in the C++ code running the OpenGL display in R. The first step in this is to render a character vector full of text into an in-memory raster, taking account of font, cex, etc. (I want one raster for the whole vector, with a recording of locations from which the shader should get each component of it.) It looks to me as though I could do this using the ragg::agg_capture device in R code, but I'd prefer to do it all in C++ code because I may need to make changes to the raster at times when it's not safe to call back to R, e.g. if some user interaction requires the axis labels to be recomputed and redrawn. Does anyone with experience doing this kind of thing know of examples I can follow, or have advice on how to proceed? Or want to volunteer to help with this? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 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() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 11 x64 (build 22621) Matrix products: default locale: [1] LC_COLLATE=Italian_Italy.utf8 LC_CTYPE=Italian_Italy.utf8 [3] LC_MONETARY=Italian_Italy.utf8 LC_NUMERIC=C [5] LC_TIME=Italian_Italy.utf8 time zone: Europe/Rome tzcode source: internal attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.3.1 -- ___ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 https://simonegiannerini.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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: > > > > 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 >> > [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 semantically different e.g. >> >> Re(x) >> > [1] NA >> >> Re(y) >> > [1] -0.5 # surprise! >> >> Im(x) # surprise! >> > [1] 2 >> >> Im(z) >> > [1] NA >> > so any expression involving Re() or Im() will produce >> > different results on input that look the same on the >> > surface. >> > You can address this either by normalizing the internal >> > representation of complex NA to always be complex(r=NaN, >> > i=NA_real_), like for NA_complex_, or by allowing the >> > infinite variations that are currently allowed and at the >> > same time making sure that both Re() and Im() always >> > return NA_real_ on a complex NA. >> > My point is that the behavior of complex NA should be >> > predictable. Right now it's not. Once it's predictable >> > (with Re() and Im() both returning NA_real_ regardless of >> > internal representation), then it no longer matters what >> > kind of complex NA is returned by as.complex(NA_real_), >> > because they are no onger distinguishable. >> > H. >> > On 9/22/23 13:43, Duncan Murdoch wrote: >> >> 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, NA_real_) is FALSE, as it >> >> should be). If you are using a different test, that's >> >> user error. >> >> >> >> Duncan Murdoch >> >> >> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: >> >>> 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 view): >> >>> >> >>> NA_real_ + 0i >> >>> >> >>> complex(r=NA_real_, i=Inf) >> >>> >> >>> complex(r=2, i=NA_real_) >> >>> >> >>> complex(r=NaN, i=NA_real_) >> >>> >> >>> In other words, using a single representation for >> >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would >> >>> avoid a lot of unnecessary complications and surprises. >> >>> >> >>> Once you do that, whether as.complex(NA_real_) should >> >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_, >> >>> i=NA_real_) becomes a moot point. >> >>> >> >>> Best, >> >>> >> >>> H. >> Thank you, Hervé. >> Your proposition is yet another one, >> to declare that all complex NA's should be treated as identical >> (almost/fully?) everywhere. >> This would be a possibility, but I think a drastic one. >> I think there are too many cases, where I want to keep the >> information of the real part independent of the values of the >> imaginary part (e.g. think of the Riemann hypothesis), and >> typically vice versa. >> With your proposal, for a (potentially large) vector of complex numbers, >> after >> Re(z) <- 1/2 >> I could no longer rely on Re(z) == 1/2, >> because it would be wrong for those z where (the imaginary part/ the number) >> was NA/NaN. >> Also, in a similar case, a >> Im(z) <- NA >> would have to "destroy" all real parts Re(z); >> not really typically in memory, but effectively for the user, Re(z) >> would be all NA/NaN. >> And I think there are quite a few other situations >> where looking at Re() and Im() separately makes a lot of sense. > > Indeed, and there is no way to "tell" BLAS and LAPACK to treat both the real > and > imaginary parts as NA_REAL when either is NA_REAL. Hence the only reliable > way > to implement such a proposal would be to post-process the result of any > computation returning a complex type, testing for NA_REAL and setting both > parts > to NA_REAL in that case. My expectation is that such
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 > [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 semantically different e.g. >> Re(x) > [1] NA >> Re(y) > [1] -0.5 # surprise! >> Im(x) # surprise! > [1] 2 >> Im(z) > [1] NA > so any expression involving Re() or Im() will produce > different results on input that look the same on the > surface. > You can address this either by normalizing the internal > representation of complex NA to always be complex(r=NaN, > i=NA_real_), like for NA_complex_, or by allowing the > infinite variations that are currently allowed and at the > same time making sure that both Re() and Im() always > return NA_real_ on a complex NA. > My point is that the behavior of complex NA should be > predictable. Right now it's not. Once it's predictable > (with Re() and Im() both returning NA_real_ regardless of > internal representation), then it no longer matters what > kind of complex NA is returned by as.complex(NA_real_), > because they are no onger distinguishable. > H. > On 9/22/23 13:43, Duncan Murdoch wrote: >> 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, NA_real_) is FALSE, as it >> should be). If you are using a different test, that's >> user error. >> >> Duncan Murdoch >> >> On 22/09/2023 2:41 p.m., Hervé Pagès wrote: >>> 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 view): >>> >>> NA_real_ + 0i >>> >>> complex(r=NA_real_, i=Inf) >>> >>> complex(r=2, i=NA_real_) >>> >>> complex(r=NaN, i=NA_real_) >>> >>> In other words, using a single representation for >>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would >>> avoid a lot of unnecessary complications and surprises. >>> >>> Once you do that, whether as.complex(NA_real_) should >>> return complex(r=NA_real_, i=0) or complex(r=NA_real_, >>> i=NA_real_) becomes a moot point. >>> >>> Best, >>> >>> H. Thank you, Hervé. Your proposition is yet another one, to declare that all complex NA's should be treated as identical (almost/fully?) everywhere. This would be a possibility, but I think a drastic one. I think there are too many cases, where I want to keep the information of the real part independent of the values of the imaginary part (e.g. think of the Riemann hypothesis), and typically vice versa. With your proposal, for a (potentially large) vector of complex numbers, after Re(z) <- 1/2 I could no longer rely on Re(z) == 1/2, because it would be wrong for those z where (the imaginary part/ the number) was NA/NaN. Also, in a similar case, a Im(z) <- NA would have to "destroy" all real parts Re(z); not really typically in memory, but effectively for the user, Re(z) would be all NA/NaN. And I think there are quite a few other situations where looking at Re() and Im() separately makes a lot of sense. Indeed, and there is no way to "tell" BLAS and LAPACK to treat both the real and imaginary parts as NA_REAL when either is NA_REAL. Hence the only reliable way to implement such a proposal would be to post-process the result of any computation returning a complex type, testing for NA_REAL and setting both parts to NA_REAL in that case. My expectation is that such testing would drastically slow down basic arithmetic and algebraic operations ... Mikael Spencer also made a remark in this direction. All in all I'd be very reluctant to move in this direction; but yes, I'm just one person ... let's continue musing and considering ! Martin >>> On 9/22/23 03:38, Martin Maechler wrote: > Mikael Jagan on Thu, 21 Sep 2023 00:47:39 > -0400 writes: > Revisiting this thread from April:
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)
> [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 semantically different e.g.
>> Re(x)
> [1] NA
>> Re(y)
> [1] -0.5 # surprise!
>> Im(x) # surprise!
> [1] 2
>> Im(z)
> [1] NA
> so any expression involving Re() or Im() will produce
> different results on input that look the same on the
> surface.
> You can address this either by normalizing the internal
> representation of complex NA to always be complex(r=NaN,
> i=NA_real_), like for NA_complex_, or by allowing the
> infinite variations that are currently allowed and at the
> same time making sure that both Re() and Im() always
> return NA_real_ on a complex NA.
> My point is that the behavior of complex NA should be
> predictable. Right now it's not. Once it's predictable
> (with Re() and Im() both returning NA_real_ regardless of
> internal representation), then it no longer matters what
> kind of complex NA is returned by as.complex(NA_real_),
> because they are no onger distinguishable.
> H.
> On 9/22/23 13:43, Duncan Murdoch wrote:
>> 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, NA_real_) is FALSE, as it
>> should be). If you are using a different test, that's
>> user error.
>>
>> Duncan Murdoch
>>
>> On 22/09/2023 2:41 p.m., Hervé Pagès wrote:
>>> 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 view):
>>>
>>> NA_real_ + 0i
>>>
>>> complex(r=NA_real_, i=Inf)
>>>
>>> complex(r=2, i=NA_real_)
>>>
>>> complex(r=NaN, i=NA_real_)
>>>
>>> In other words, using a single representation for
>>> complex NA (i.e. complex(r=NA_real_, i=NA_real_)) would
>>> avoid a lot of unnecessary complications and surprises.
>>>
>>> Once you do that, whether as.complex(NA_real_) should
>>> return complex(r=NA_real_, i=0) or complex(r=NA_real_,
>>> i=NA_real_) becomes a moot point.
>>>
>>> Best,
>>>
>>> H.
Thank you, Hervé.
Your proposition is yet another one,
to declare that all complex NA's should be treated as identical
(almost/fully?) everywhere.
This would be a possibility, but I think a drastic one.
I think there are too many cases, where I want to keep the
information of the real part independent of the values of the
imaginary part (e.g. think of the Riemann hypothesis), and
typically vice versa.
With your proposal, for a (potentially large) vector of complex numbers,
after
Re(z) <- 1/2
I could no longer rely on Re(z) == 1/2,
because it would be wrong for those z where (the imaginary part/ the number)
was NA/NaN.
Also, in a similar case, a
Im(z) <- NA
would have to "destroy" all real parts Re(z);
not really typically in memory, but effectively for the user, Re(z)
would be all NA/NaN.
And I think there are quite a few other situations
where looking at Re() and Im() separately makes a lot of sense.
Spencer also made a remark in this direction.
All in all I'd be very reluctant to move in this direction;
but yes, I'm just one person ... let's continue musing and
considering !
Martin
>>> On 9/22/23 03:38, 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 > 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 as.complex(NA_integer_).
> Was any consideration given to the alternative?
> That is, to changing as.complex(NA) and
as.complex(NA_integer_) to > give
complex(r=NA_real_, i=0), consistent with >
as.complex(NA_real_),
Re: [R-pkg-devel] User defined RNG and code registration.
On 23/09/2023 4:42 a.m., Ralf Stubner wrote: Hi everybody, Section 5.4 of WRE suggests to use `R_useDynamicSymbols(dll, FALSE);` when registering C/C++ routines in R packages, and Rcpp does so automatically. ?Random.user describes a way to hook a user- defined RNG into R. However, it looks like these two things are not compatible, i.e. `user_unif_rand` et al. are not found, if dynamic symbols are not allowed. Or can one register these routines somehow even though they are not following one of the standard calling conventions? I don't know the answer here, but section 6.16 of WRE suggests that you could explicitly make your functions visible even if they default to invisible. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] .OnLoad v .OnAttach
On 22/09/2023 8:35 p.m., Jonathan Godfrey wrote: Hello all, An issue has been raised for my BrailleR package. https://github.com/ajrgodfrey/BrailleR/issues/97#issuecomment-1732136521 I do make use of an .OnLoad() function for various tasks, including creation of a folder to put stuff in. The user gets to choose if this is temporary or fixed if the session is interactive. (all in zzz.R What risks do I face if any of this .OnLoad() are moved to .OnAttach()? If you move code from .onLoad() to .onAttach(), it won't be executed if the user never calls library(BrailleR) or require(BrailleR). (This is a little simplified; there are other ways to attach a package, but they are rarely used. More details on loading vs attaching below.) If some setup is required by functions in your package even if they are called from other packages, it belongs in .onLoad(). A less convenient approach is for those functions to check whether the setup has happened every time you call them, and execute it if not. Here are the details of the differences: Loading makes the exported functions in the package available to other packages that import them, or call them using BrailleR::fn syntax. The latter is also possible for users, and also triggers loading. Once a package is loaded it normally stays loaded for the whole session, so .onLoad() will only be called once. Attaching puts your package on the search list so that exported functions are available to the user without the prefix. It will always be preceded by loading. A user triggers attaching by making calls to library() or require(). If another package "Depends" on BrailleR, then loading that package will cause BrailleR to be attached. The guidelines recommend against this, so most packages will use "Imports" instead. That triggers loading but not attaching. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] User defined RNG and code registration.
Hi everybody, Section 5.4 of WRE suggests to use `R_useDynamicSymbols(dll, FALSE);` when registering C/C++ routines in R packages, and Rcpp does so automatically. ?Random.user describes a way to hook a user- defined RNG into R. However, it looks like these two things are not compatible, i.e. `user_unif_rand` et al. are not found, if dynamic symbols are not allowed. Or can one register these routines somehow even though they are not following one of the standard calling conventions? Thanks Ralf __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] tinyfiledialogs - The bindings are ready, but I need help to make of package of it
Thanks to everybody for the help and input. I happens that Paul was already working on preparing a tinyfiledialogs package for R ! As he seems to know what is doing much more than I do, I will let him go ahead with the .Call version he is preparing and will provide assistance when needed. thanks again. guillaume On 9/22/23 10:55, Paul Smith wrote: > Hi Guillaume > > As Ivan says there is a fair bit to packaging but not to much when you > get used to it. > > Since your email I've put a mostly untested package wrapping > tingfiledialogs via Rcpp on github > > https://github.com/waternumbers/tinyfiledialogR > > It is far from fully tested but might help. > > cheers > > Paul > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
