similar to: complex tangent (PR#7781)

With 'z' of length 8 below, or of length 12 previously, one may try sapply(rev(z), match, table = rev(z)) match(rev(z), rev(z)) I found that the two results were different in R devel r70604. A shorter one: > z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) > sapply(z, match, table = z) [1] 1 1 2 > match(z, z) [1] 1 1 3 An explanation of the behavior: With normal

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.

On 4/3/23 14:07, Michael Milton wrote: > Hi all, > > There seems to have been a breaking change in the R trunk caused by a fix > to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that > relates to the layout of the Rcomplex typedef. Previously it was a struct, > but now it's a union by default >

Hello, I am trying to call the BLAS Level1 function zdotc from R via a .C call like this: #include "R.h" #include "R_ext/BLAS.h" void testzdotc() { Rcomplex zx[3], zy[3], ret_val; zx[0].r = 1.0; zx[0].i = 0.0; zx[1].r = 2.0; zx[0].i = 0.0; zx[2].r = 3.0; zx[0].i = 0.0; zy[0].r = 1.0; zy[0].i = 0.0; zy[1].r = 2.0; zy[0].i = 0.0; zy[2].r = 3.0;

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,

On 4/3/23 15:50, Michael Milton wrote: > Okay, but I'm afraid this will only mean something to Rust users. The > reason being that we encountered this issue in extendr: a Rust > extension library for R. The specific compiler errors we encounter > happen because bindgen (the Rust code generation library) read the > changed R header files, and generated a new type definition

Hi Tomas, Thanks for this explanation. As you can probably tell I'm not much of a C person, so I didn't realise this change would be invisible to C users. I suppose R's stability contract only applies to C, and therefore changes that break other languages such as Rust are out of scope. You are right that this error is confused by bindgen's inability to handle anonymous types, but

This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I

o `Rcomplex' is preferred to `complex' (a future reserved word in C) for R complex objects passed to C. I'm a bit confused here. Is "complex" or "Rcomplex" the future reserved word in C (I thought "complex" already was, but I'm not a C programmer) and is this because R storage modes should or should not have names corresponding to C reserved

I don't think an auto-generated name (along the lines of u or u2) for the anonymous structs would be helpful here. You can see that bindgen is already generating a placeholder name ("__bindgen_anon_1"). A meaningful name might be nice instead, but I get the impression that isn't an option here since that would break the C API. Can I ask, would it make sense for us to hard code

The configure script runs fine, but when I compile todays alpha version of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT from Sept. 4th I get the following output: ======================================================== [...] gcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include

Full_Name: Christian Marquardt Version: 2.2.1 OS: Linux Submission from: (NULL) (84.167.229.240) Hello, I believe this is a bug in the configuration / installation: When configuring R-2.2.1 using the Intel v9 Fortran compiler as default Fortran compiler and g++ as C++ compiler on a Suse 9.3 Linux, the configuration script finds that the C and Fortran idea of double comples disagree. I have

Full_Name: Tom Short Version: 2.4.0 OS: Windows XP Submission from: (NULL) (68.236.159.227) It looks like there's a bug in acosh with complex number in windows: > acosh(2) [1] 1.316958 > acosh(2+0i) [1] 0+NaNi This happens for me on Windows XP with the following versions: R version 2.2.0, 2005-10-06, i386-pc-mingw32 R version 2.4.0 (2006-10-03) i386-pc-mingw32 It works fine with

Hi all, There seems to have been a breaking change in the R trunk caused by a fix to bug 18430 <https://bugs.r-project.org/show_bug.cgi?id=18430> that relates to the layout of the Rcomplex typedef. Previously it was a struct, but now it's a union by default

Hi the following gave me a shock: > atan(2) [1] 1.107149 > atan(2+0i) [1] -0.4636476+0i > or, perhaps more of a gotcha: > atan(1.0001+0i) [1] -0.7853482+0i > atan(0.9999+0i) [1] 0.7853482+0i > evidently atan()'s branch cuts aren't where I thought they were. Where do I look for documentation on this? -- Robin Hankin Uncertainty Analyst National

The following behaviour (in R 0.62.3) is disturbing: > (0+0i)^2 [1] NaN+NaNi Is it deliberate?? Laimonis Kavalieris -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

The following behaviour (in R 0.62.3) is disturbing: > (0+0i)^2 [1] NaN+NaNi Is it deliberate?? Laimonis Kavalieris -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

I want to integrate the function (sin^7*x)*(cos^8*x)dx. I do not have values to integrate between. I just want R to give me the integral of the function. For example R takes the derivative of the function by d1=D(expression(x^2*(cosh*(x^3))), "x"). Is there a similar function available in R to find the integral? Thanks, Kim

Hi, I'm currently in the process of writing an R-installation SOP for my company. As part of that process I'm using the recommendations from the 'R Installation and Administration' document, section 3.2, "Testing an installation". This is done on an XP machine, using the latest binary of 2.11.0. The binary is downloaded and then installed from the installer. I then

If you set the "digits17" control option in deparse, you get a lot of unnecessary space in the representation of complex numbers. > deparse(0 + 0i) [1] "0+0i" > deparse(0 + 0i, control = "digits17") [1] "0 + 0i" As far as I can tell, the logic for this comes from this piece of /src/main/deparse.c: if (TYPEOF(vector) == CPLXSXP